转载

专治MySQL乱码问题

作者：spermwhale0

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

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数据读取和写入的流程可以用下图表示：

专治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-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，要怎样从表中查询关于小明的信息呢？

可以尝试直接登陆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中没有对应“小明”这两个字的编码，因此会报错。

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

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

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

这是因为用户终端的编码是UTF-8, 因此传入的“小明”的编码也是UTF-8，而表格中的数据是GBK编码，它们在内存中的储存形式不同。因此，即便MySQL都将它们当作Latin-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在读写的过程中会自动进行转换。

参数资料

记住，永远不要在 MySQL 中使用“utf8”
Mysql 修改字符集

学习资料分享

收集准备了 12 套 微服务、Spring Boot、Spring Cloud 核心技术资料，这是部分资料目录：

Spring Security 认证与授权
Spring Boot 项目实战（中小型互联网公司后台服务架构与运维架构）
Spring Boot 项目实战（企业权限管理项目））
Spring Cloud 微服务架构项目实战（分布式事务解决方案）
Spring Cloud + Spring Boot + Docker 全套视频教程
Spring Cloud 网站项目实战（房产销售）
Spring Cloud 微服务项目实战（大型电商架构系统）
单点登陆基础到实战
Spring Boot 项目实战（企业微信点餐系统）（初级实战）
Spring Cloud 互联网应用项目实战（天气预报系统）
Spring 源码深度解析 + 注解开发全套视频教程
Spring Boot 项目实战（理财产品系统）

目录截图：

专治MySQL乱码问题

公众号后台领取资料：

专治MySQL乱码问题

原文 https://segmentfault.com/a/1190000021964992

正文到此结束

所属分类： Spring

本文标签： UI 参数 IO mysql shell sql value Security 分布式事务 http 微服务 tab 网站 Docker src Spring cloud 认证产品 Select client 乱码源码互联网解析 Connection 分布式 root 理财管理企业 Spring Security spring 房产数据开发 Spring Boot 目录 https
版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
本文海报： 生成海报一生成海报二

其他链接

关于本站

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。

问题交流

专治MySQL乱码问题

MySQL编码过程

UTF-8、GBK和Latin-1

UTF-8、GBK和Latin-1是MySQL中最常见的三种编码形式。

错进错出

举个例子

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

参数资料

学习资料分享

目录截图：

公众号后台领取资料：

热门推荐

相关文章

说给你听

本文目录

随机标签

书籍教程

近期评论

网站信息

其他链接

关于本站

问题交流