点击蓝色“架构文摘”关注我哟

加个“星标”，每天上午 09:25，干货推送！

作者：spermwhale0  

 简书：https://www.jianshu.com/p/94d6b75bdff9

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/[email protected]/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/[email protected]/5.7.24/share/mysql/charsets/

这样，character_set_client和character_set_results就被修改成了GBK。

UTF-8、GBK和Latin-1

UTF-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("啊");

假设终端编码的方式是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解码完成以后，数据还要存入目标表格中。

• 如果目标表格是Latin-1编码，解码完成的数据可以直接存入表中。

• 如果目标表格是UTF-8编码，解码完成的数据先转换为UTF-8编码，再存入表中。

• 如果目标表格是GBK编码，由于并不是每一个Latin-1编码的字符都能在GBK中找到对应的编码，所以在转码的过程中可能会报错。

因此，错进错出的另一个条件是目标表格必须是Latin-1或者UTF-8编码。

读取时，MySQL会将目标表格中的数据转化为character_set_results指定的编码。由于我们写入时使用的Latin-1，读取时也需要指定character_set_results为Latin-1。这样最终就实现了“错进错出”。

举个例子

假设有这样一张student表：

|name| age|
|----|----|
|小明|12|
|小红|10|

其中，name列编码为Latin-1，其储存的数据使用的编码为GBK。

也就是说向表里存入数据的人可能使用GBK的终端下执行了下列语句：

SET NAMES latin1;
INSERT INTO student VALUES ('小明', 12);

那么，如果我们现在使用的终端编码为UTF-8，要怎样从表中查询关于小明的信息呢？

1. 可以尝试直接登陆MySQL，输入以下语句：

SELECT * FROM student WHERE name = "小明";

但这样做得到了一个错误：

ERROR 1267 (HY000): Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='

MySQL默认用户终端使用的是UTF-8编码，与表格的编码 Latin-1 不一致，于是MySQL会首先尝试把查询语句转换为Latin-1。但是Latin-1中没有对应“小明”这两个字的编码，因此会报错。

1. 如果增加一条改变character_set_client的语句，会怎么样呢？

SET NAMES latin1;
SELECT * FROM students WHERE name = "小明";

这一次MySQL会认为用户的终端就是Latin-1编码，所以没有做转换操作。但最终查询到的结果却为空。

这是因为用户终端的编码是UTF-8, 因此传入的“小明”的编码也是UTF-8，而表格中的数据是GBK编码，它们在内存中的储存形式不同。因此，即便MySQL都将它们当作Latin-1处理，也不会认为它们相等。

1. 不直接登陆MySQL，而是在Shell中先将查询语句转化为GBK编码，再传入MySQL：

echo "
SET names latin1;
SELECT * FROM student WHERE name = '小明';"\
| iconv -f utf8 -t gbk\
| mysql -uroot -p123 -Dtest

其中iconv的作用是将标准输入转换为指定的编码格式（这里是GBK），再通过标准输出传递给MySQL。我们得到了：

name    age
С�� 12

能查询到结果，但名字部分是乱码。这是由于表格中储存的数据是GBK编码，而终端编码是UTF-8。所以还需要增加最后一步：将查询的结果转换为UTF-8。

echo "
SET names latin1;
SELECT * FROM student WHERE name = '小明';"\
| iconv -f utf8 -t gbk\
| mysql -uroot -p123 -Dtest\
| iconv -f gbk -t utf8

输出结果为：

name    age
小明  12

这样，我们终于得到了正确的信息。

如果表格本身就是GBK编码，而不是Latin-1，是否还需要这样的繁琐的步骤呢？

答案是不需要的。因为只要正确地设置了character_set_client和character_set_results，尽管表格的编码是GBK，MySQL在读写的过程中会自动进行转换。

推荐阅读：

• 如何使用 SpringBoot + Redis 优雅的解决接口幂等性问题
  

• 实时海量日志分析系统的架构设计、实现以及思考
  

• 分布式、服务化的企业级 ERP 系统架构设计方案

• 不懂 Zookeeper？没关系，看这篇就够了

• 架构师究竟比高级开发厉害在哪？

  如有收获，点个在看，诚挚感谢