专治 MySQL 乱码，再也不想看到乱码了 _MySQL

MySQL编码过程
MySQL出现乱码的原因有很多，一般与character_set参数有关。我们先来看看有哪些参数：
SHOW VARIABLES LIKE "character%";
Variable_name Value
character_set_client utf8
character_set_connection utf8
character_set_database utf8
character_set_filesystem binary
character_set_results utf8
character_set_server utf8
character_set_system utf8
character_sets_dir /usr/local/Cellar/mysql@5.7/5.7.24/share/mysql/charsets/
其中，最主要的是character_set_client和character_set_results 。这两个参数分别有什么用呢？
在客户端将一条命令输入MySQL时，MySQL只知道这条命令是0101的字节流，并不知道具体采用的是什么编码。第一个参数character_set_client就告诉了MySQL，这条命令是UTF-8编码，于是MySQL会使用UTF-8解码字节流。当MySQL成功解码以后，会将命令内容转化为目标表格的编码。
表格的编码可以通过以下命令查看：
SHOW FULL COLUMNS FROM student;
假设MySQL的character_set_client设置为UTF-8，表格的编码为GBK 。如果在UTF-8的终端中输入：INSERT INTO student VALUES ('小明', 12)，MySQL首先会用UTF-8解码这条命令，再将“小明”两个字转换为对应的GBK编码，最后存入表中。
另外一个参数character_set_results是指查询结果输出的编码。如果表格的编码是GBK，character_set_results设置为UTF-8，那么在表格中查询的内容会首先转换为UTF-8编码，再输出到终端。
MySQL数据读取和写入的流程可以用下图表示：

文章插图

从图中可以看出，当存入表格的解码/编码过程和读取表格的解码/编码过程对应不上时，就会出现乱码。
如果要改变character_set_client和character_set_results，可以方便地执行一条命令：
SET names gbk;
Variable_name Value
character_set_client gbk
character_set_connection gbk
character_set_database utf8
character_set_filesystem binary
character_set_results gbk
character_set_server utf8
character_set_system utf8
character_sets_dir /usr/local/Cellar/mysql@5.7/5.7.24/share/mysql/charsets/
这样，character_set_client和character_set_results就被修改成了GBK 。
UTF-8、GBK和Latin-1UTF-8、GBK和Latin-1是MySQL中最常见的三种编码形式。

它们都向下兼容ASCII 。同一串使用ASCII编码的字符，转化为UTF-8、GBK和Latin-1以后的结果是一样的。因此，假设客户端传入了SET NAMES latin1这条指令，不论character_set_client设置为UTF-8、GBK还是Latin-1，都可以正常解码并执行。
Latin-1是单字节编码，其编码范围是0x00-0xFF 。也就是说任意的8位二进制字节都可以对应于Latin-1中的字符。
UTF-8的表示范围远大于GBK 。所有Latin-1字符都能转换为UTF-8字符，但不一定能转换为GBK字符。

以上几点为MySQL“错进错出”提供了条件。所谓的错进错出，是指客户端的字符编码和最终表的字符编码格式不同，但是只要保证存和取两次的字符集编码一致就仍然能够获得没有乱码的输出的这种现象。
错进错出我们先来考虑这样一条命令：
INSERT INTO table VALUE("啊");
【专治 MySQL 乱码，再也不想看到乱码了】假设终端编码的方式是GBK，“啊”的二进制表示方式就是10110000 10100001 。MySQL拿到这个命令以后，通过character_set_client指定的编码方式进行解码。

如果character_set_client是GBK，MySQL会认为这是一个“啊”字符；
如果character_set_client是Latin-1，MySQL会将它看作两个单独的Latin-1字符(10110000) (10100001)，最后解码得到°¡ 。
如果character_set_client是UTF-8，由于10110000 10100001 并不是一个有效的UTF-8编码，所以要么报错，要么会替换为一个错误标识? 。此时如果直接存入表中，就不能实现“错进错出”了。

因此，错进错出的一个必要条件是将character_set_client设置为Latin-1，如果设置为GBK或者UTF-8就无法保证能正确解码。
以上是解码的过程，当使用Latin-1解码完成以后，数据还要存入目标表格中。