MySQL乱码问题终极指南


mysql的字符集设置众多,从客户端到连接到结果集,从服务器到库到表到列,都可以设置字符集,灵活很强大,但就是很容易出问题,如果不了解其机制,很容易就出现乱码问题。
为了普度众生,让大家尽量在工作中少受或者不受乱码的骚扰、困扰,这里我结合之前其它同学在论坛的发帖,并结合自己的理解和实践,详细分析总结了一下,以飨各位看官。

关于字符集和乱码的基础知识这里就不详细说明了(请自行搜索),但有一个问题需要特别强调一下:乱码是怎么产生的
这个问题相信很多同学都是模棱两可,或者没有认真想过,反正理解就是”字符编码“不对导致乱码,但没有真正想过为什么”字符编码“会导致乱码。
答案其实很简单:“转换导致乱码”!
根据这个原则来判断,各种情况就很简单了:
1)数据传送过程中不会导致乱码
2)数据存储不会导致乱码
3)数据输入和输出(包括显示)可能导致乱码
4)数据接收和发送可能导致乱码

更详细的解释:转换导致乱码是指本来是A字符集的数据被当成了B字符集进行解析,而不是说正确的A字符集转换为B字符集。
例如:如下mysql字符处理机制流程图中,mysql客户端发送的实际上是2个gbk字符(4字节),但character_set_connection
设置了utf8,于是mysql服务器将收到的4字节gbk数据按照utf8解析,得到1个中文字符+1个字节,这时就产生乱码了;

如果character_set_connection 设置为gbk,mysql服务器收到数据后按照gbk解析,得到两个正确的中文,然后再转换为这两个中文对应的utf8编码,这就不会产生乱码。)

【mysql的字符处理机制】
详细的处理机制如下图:
 

我们模拟一下一条数据从插入到读取的处理流程,看看在整个流程中,字符集是如何辗转腾挪的。
【插入流程】
1. 客户端设定了自己的编码(character_set_client),接收用户的输入;
2. 客户端将用户的输入“转换”成连接的编码(character_set_connection) =====> 第一次转换
3. 客户端将转换后的数据发送给服务器;                               =====> 传输不会导致编码转换
4. 服务器收到客户端的数据,再判断数据列的字符集,进行字符转换       =====> 第二次转换
5. 服务器将数据存储(例如磁盘)                                     =====> 存储不会导致编码转换  

  • 1
  • 2
  • 3
  • 下一页

相关内容