10分钟学会理解和解决MySQL乱码问题

　　MySQL出现乱码的缘由

　　要了解为何会出现乱码，咱们就先要理解：从客户端发起请求，到MySQL存储数据，再到下次从表取回客户端的过程当中，哪些环节会有编码/解码的行为。为了更好的解释这个过程，博主制做了两张流程图，分别对应存入和取出两个阶段。

　　存入MySQL经历的编码转换过程

　　mysqlflow

　　上图中有3次编码/解码的过程（红色箭头）。三个红色箭头分别对应：客户端编码，MySQL Server解码，Client编码向表编码的转换。其中Terminal能够是一个Bash，一个web页面又或者是一个APP。本文中咱们假定Bash是咱们的Terminal，即用户端的输入和展现界面。图中每个框格对应的行为以下：

　　在terminal中使用输入法输入

　　terminal根据字符编码转换成二进制流

　　二进制流经过MySQL客户端传输到MySQL Server

　　Server经过character-set-client解码

　　判断character-set-client和目标表的charset是否一致

　　若是不一致则进行一次从client-charset到table-charset的一次字符编码转换

　　将转换后的字符编码二进制流存入文件中

　　从MySQL表中取出数据经历的编码转换过程

　　mysqlflow

　　上图有3次编码/解码的过程（红色箭头）。上图中三个红色箭头分别对应：客户端解码展现，MySQL Server根据character-set-client编码，表编码向character-set-client编码的转换。

　　从文件读出二进制数据流

　　用表字符集编码进行解码

　　将数据转换为character-set-client的编码

　　使用character-set-client编码为二进制流

　　Server经过网络传输到远端client

　　client经过bash配置的字符编码展现查询结果

　　形成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，那么毫无疑问的必定会出现乱码。

　　这里咱们就简单演示下这种状况

　　view sourceprint?

　　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两个字。可见，若是在从数据文件读入数据后，不进行编解码的话在存储引擎内部是没法进行字符级别的操做的。

http://www.fnb.hk/blog/space.php?uid=34121&do=blog&id=315468