10分钟学会理解和解决MySQL乱码问题(1)(2)

造成MySQL乱码的原因

1. 存入和取出时对应环节的编码不一致

这个会造成乱码是显而易见的。我们把存入阶段的三次编解码使用的字符集编号为C1,C2,C3(图一从左到右);取出时的三个字符集依次编号为C1’,C2’,C3’(从左到右)。那么存入的时候bash C1用的是UTF-8编码，取出的时候,C1'我们却使用了windows终端(默认是GBK编码)，那么结果几乎一定是乱码。又或者存入MySQL的时候set names utf8(C2)，而取出的时候却使用了set names gbk(C2')，那么结果也必然是乱码

2. 单个流程中三步的编码不一致

即上面任意一幅图中的同方向的三步中，只要两步或者两部以上的编码有不一致就有可能出现编解码错误。如果差异的两个字符集之间无法进行无损编码转换(下文会详细介绍)，那么就一定会出现乱码。例如：我们的shell是UTF8编码，MySQL的character-set-client配置成了GBK，而表结构却又是charset=utf8，那么毫无疑问的一定会出现乱码。

这里我们就简单演示下这种情况

master [localhost] {msandbox} (test) > create table charset_test_utf8 (id int primary key auto_increment, char_col varchar(50)) charset = utf8; 
 
Query OK, 0 rows affected (0.04 sec) 
 
master [localhost] {msandbox} (test) > set names gbk; 
 
Query OK, 0 rows affected (0.00 sec) 
 
master [localhost] {msandbox} (test) > insert into charset_test_utf8 (char_col) values ('中文'); 
 
Query OK, 1 row affected, 1 warning (0.01 sec) 
 
master [localhost] {msandbox} (test) > show warnings; 
 
+---------+------+---------------------------------------------------------------------------+ 
 
| Level | Code | Message | 
 
+---------+------+---------------------------------------------------------------------------+ 
 
| Warning | 1366 | Incorrect string value: '\xAD\xE6\x96\x87' for column 'char_col' at row 1 | 
 
+---------+------+---------------------------------------------------------------------------+ 
 
1 row in set (0.00 sec) 
 
master [localhost] {msandbox} (test) > select id,hex(char_col),char_col from charset_test_utf8; 
 
+----+----------------+----------+ 
 
| id | hex(char_col) | char_col | 
 
+----+----------------+----------+ 
 
| 1 | E6B6933FE69E83 | ???? | 
 
+----+----------------+----------+ 
 
1 row in set (0.01 sec) 

关于MySQL的编/解码

既然系统之间是按照二进制流进行传输的，那直接把这串二进制流直接存入表文件就好啦。为什么在存储之前还要进行两次编解码的操作呢?

• Client to Server的编解码的原因是MySQL需要对传来的二进制流做语法和词法解析。如果不做编码解析和校验，我们甚至没法知道传来的一串二进制流是insert还是update。
• File to Engine的编解码是为知道二进制流内的分词情况。举个简单的例子：我们想要从表里取出某个字段的前两个字符，执行了一句形如select left(col,2) from table的语句，存储引擎从文件读入该column的值是E4B8ADE69687。那么这个时候如果我们按照GBK把这个值分割成E4B8,ADE6,9687三个字，并那么返回客户端的值就应该是E4B8ADE6;如果按照UTF8分割成E4B8AD,E69687，那么就应该返回E4B8ADE69687两个字。可见，如果在从数据文件读入数据后，不进行编解码的话在存储引擎内部是无法进行字符级别的操作的。