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

时间  2019-12-07
标签 10分 学会 理解 解决 mysql 乱码 问题 栏目 MySQL 繁體版
原文   原文链接

在阅读本文以前，强烈建议对字符集编码概念还比较模糊的同窗 阅读下博主以前对相关概念的一篇科普：十分钟搞清字符集和字符编码php

本博客已经迁移至：

http://cenalulu.github.io/html

为了更好的体验，请经过此连接阅读：

http://cenalulu.github.io/mysql/mysql-mojibake/mysql

MySQL出现乱码的缘由

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

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

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

  • 在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编码的转换。github

  • 从文件读出二进制数据流
  • 用表字符集编码进行解码
  • 将数据转换为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')，那么结果也必然是乱码web

2. 单个流程中三步的编码不一致
即上面任意一幅图中的同方向的三步中，只要两步或者两部以上的编码有不一致就有可能出现编解码错误。若是差别的两个字符集之间没法进行无损编码转换（下文会详细介绍），那么就必定会出现乱码。例如：咱们的shell是UTF8编码，MySQL的character-set-client配置成了GBK，而表结构却又是charset=utf8，那么毫无疑问的必定会出现乱码。
这里咱们就简单演示下这种状况sql

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的编/解码

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

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

关于错进错出

在MySQL中最多见的乱码问题的原由就是把错进错出神话。所谓的错进错出就是，客户端(web或shell)的字符编码和最终表的字符编码格式不一样，可是只要保证存和取两次的字符集编码一致就仍然可以得到没有乱码的输出的这种现象。可是，错进错出并非对于任意两种字符集编码的组合都是有效的。咱们假设客户端的编码是C，MySQL表的字符集编码是S。那么为了可以错进错出，须要知足如下两个条件windows

MySQL接收请求时，从C编码后的二进制流在被S解码时可以无损
MySQL返回数据是，从S编码后的二进制流在被C解码时可以无损

编码无损转换

那么什么是有损转换，什么是无损转换呢？假设咱们要把用编码A表示的字符X，转化为编码B的表示形式，而编码B的字形集中并无X这个字符，那么此时咱们就称这个转换是有损的。那么，为何会出现两个编码所能表示字符集合的差别呢？若是你们看过博主以前的那篇 十分钟搞清字符集和字符编码，或者对字符编码有基础理解的话，就应该知道每一个字符集所支持的字符数量是有限的，而且各个字符集涵盖的文字之间存在差别。UTF8和GBK所能表示的字符数量范围以下

  • GBK单个字符编码后的取值范围是：8140 - FEFE 其中不包括**7E，总共字符数在27000左右
  • UTF8单个字符编码后，按照字节数的不一样，取值范围以下表：

charset

因为UTF-8编码能表示的字符数量远超GBK。那么咱们很容易就能找到一个从UTF8到GBK的有损编码转换。咱们用字符映射器（见下图）找出了一个明显就不在GBK编码表中的字符，尝试存入到GBK编码的表中。并再次取出查看有损转换的行为
字符信息具体是：ਅ GURMUKHI LETTER A Unicode: U+0A05, UTF-8: E0 A8 85
charset

在MySQL中存储的具体状况以下：

master [localhost] {msandbox} (test) > create table charset_test_gbk (id int primary key auto_increment, char_col varchar(50)) charset = gbk;
Query OK, 0 rows affected (0.00 sec)

master [localhost] {msandbox} (test) > set names utf8;
Query OK, 0 rows affected (0.00 sec)

master [localhost] {msandbox} (test) > insert into charset_test_gbk (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: '\xE0\xA8\x85' 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,char_length(char_col) from charset_test_gbk;
+----+---------------+----------+-----------------------+
| id | hex(char_col) | char_col | char_length(char_col) |
+----+---------------+----------+-----------------------+
|  1 | 3F            | ?        |                     1 |
+----+---------------+----------+-----------------------+
1 row in set (0.00 sec)

出错的部分是在编解码的第3步时发生的。具体见下图
flow2

可见MySQL内部若是没法找到一个UTF8字符所对应的GBK字符时，就会转换成一个错误mark（这里是问号）。而每一个字符集在程序实现的时候内部都约定了当出现这种状况时的行为和转换规则。例如：UTF8中没法找到对应字符时，若是不抛错那么就将该字符替换成�(U+FFFD)

那么是否是任何两种字符集编码之间的转换都是有损的呢？并不是这样，转换是否有损取决于如下几点：

  • 被转换的字符是否同时在两个字符集中
  • 目标字符集是否可以对不支持字符，保留其原有表达形式

关于第一点，刚才已经经过实验来解释过了。这里来解释下形成有损转换的第二个因素。从刚才的例子咱们能够看到因为GBK在处理本身没法表示的字符时的行为是：用错误标识替代，即0x3F。而有些字符集（例如latin1）在遇到本身没法表示的字符时，会保留原字符集的编码数据，并跳过忽略该字符进而处理后面的数据。若是目标字符集具备这样的特性，那么就可以实现这节最开始提到的错进错出的效果。
咱们来看下面这个例子

master [localhost] {msandbox} (test) > create table charset_test (id int primary key auto_increment, char_col varchar(50)) charset = latin1;
Query OK, 0 rows affected (0.03 sec)

master [localhost] {msandbox} (test) > set names latin1;
Query OK, 0 rows affected (0.00 sec)

master [localhost] {msandbox} (test) > insert into charset_test (char_col) values ('中文');
Query OK, 1 row affected (0.01 sec)

master [localhost] {msandbox} (test) > select id,hex(char_col),char_col from charset_test;
+----+---------------+----------+
| id | hex(char_col) | char_col |
+----+---------------+----------+
|  2 | E4B8ADE69687  | 中文     |
+----+---------------+----------+
2 rows in set (0.00 sec)

具体流程图以下。可见在被MySQL Server接收到之后实际上已经发生了编码不一致的状况。可是因为Latin1字符集对于本身表述范围外的字符不会作任何处理，而是保留原值。这样的行为也使得错进错出成为了可能。
flow4

如何避免乱码

理解了上面的内容，要避免乱码就显得很容易了。只要作到“三位一体”，即客户端，MySQL character-set-client，table charset三个字符集彻底一致就能够保证必定不会有乱码出现了。而对于已经出现乱码，或者已经遭受有损转码的数据，如何修复相对来讲就会有些困难。下一节咱们详细介绍具体方法。

如何修复已经编码损坏的数据

在介绍正确方法前，咱们先科普一下那些网上流传的所谓的“正确方法”可能会形成的严重后果。

错误方法一

不管从语法仍是字面意思来看：ALTER TABLE ... CHARSET=xxx 无疑是最像包治乱码的良药了！而事实上，他对于你已经损坏的数据一点帮助也没有，甚至连已经该表已经建立列的默认字符集都没法改变。咱们看下面这个例子

master [localhost] {msandbox} (test) > show create table charset_test;
+--------------+--------------------------------+
| Table        | Create Table                   |
+--------------+--------------------------------+
| charset_test | CREATE TABLE `charset_test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `char_col` varchar(50) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=latin1 |
+--------------+--------------------------------+
1 row in set (0.00 sec)

master [localhost] {msandbox} (test) > alter table charset_test charset=gbk;
Query OK, 0 rows affected (0.03 sec)
Records: 0  Duplicates: 0  Warnings: 0

master [localhost] {msandbox} (test) > show create table charset_test;
+--------------+--------------------------------+
| Table        | Create Table                   |
+--------------+--------------------------------+
| charset_test | CREATE TABLE `charset_test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `char_col` varchar(50) CHARACTER SET latin1 DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=gbk |
+--------------+--------------------------------+
1 row in set (0.00 sec)

可见该语法牢牢修改了表的默认字符集，即只对之后建立的列的默认字符集产生影响，而对已经存在的列和数据没有变化。

错误方法二

ALTER TABLE … CONVERT TO CHARACTER SET …的相较于方法一来讲杀伤力更大，由于从 官方文档的解释 他的做用就是用于对一个表的数据进行编码转换。下面是文档的一小段摘录：

To change the table default character set and all character columns (CHAR, VARCHAR, TEXT) to a new character set, use a statement like this:
ALTER TABLE tbl_name
CONVERT TO CHARACTER SET charset_name [COLLATE collation_name];

而实际上，这句语法只适用于当前并无乱码，而且不是经过错进错出的方法保存的表。{: style="color: red"}。而对于已经由于错进错出而产生编码错误的表，则会带来更糟的结果。咱们用一个实际例子来解释下，这句SQL实际作了什么和他会形成的结果。假设咱们有一张编码是latin1的表，且以前经过错进错出存入了UTF-8的数据，可是由于经过terminal仍然可以正常显示。即上文错进错出章节中举例的状况。一段时间使用后咱们发现了这个错误，并打算把表的字符集编码改为UTF-8而且不影响原有数据的正常显示。这种状况下使用alter table convert to character set会有这样的后果：

master [localhost] {msandbox} (test) > create table charset_test_latin1 (id int primary key auto_increment, char_col varchar(50)) charset = latin1;
Query OK, 0 rows affected (0.01 sec)

master [localhost] {msandbox} (test) > set names latin1;
Query OK, 0 rows affected (0.00 sec)

master [localhost] {msandbox} (test) > insert into charset_test_latin1 (char_col) values ('这是中文');
Query OK, 1 row affected (0.01 sec)

master [localhost] {msandbox} (test) > select id,hex(char_col),char_col,char_length(char_col) from charset_test_latin1;
+----+--------------------------+--------------+-----------------------+
| id | hex(char_col)            | char_col     | char_length(char_col) |
+----+--------------------------+--------------+-----------------------+
|  1 | E8BF99E698AFE4B8ADE69687 | 这是中文     |                    12 |
+----+--------------------------+--------------+-----------------------+
1 row in set (0.01 sec)

master [localhost] {msandbox} (test) > alter table charset_test_latin1 convert to character set utf8;
Query OK, 1 row affected (0.04 sec)
Records: 1  Duplicates: 0  Warnings: 0

master [localhost] {msandbox} (test) > set names utf8;
Query OK, 0 rows affected (0.00 sec)

master [localhost] {msandbox} (test) > select id,hex(char_col),char_col,char_length(char_col) from charset_test_latin1;
+----+--------------------------------------------------------+-----------------------------+-----------------------+
| id | hex(char_col)                                          | char_col                    | char_length(char_col) |
+----+--------------------------------------------------------+-----------------------------+-----------------------+
|  1 | C3A8C2BFE284A2C3A6CB9CC2AFC3A4C2B8C2ADC3A6E28093E280A1 | 这是中文                |                    12 |
+----+--------------------------------------------------------+-----------------------------+-----------------------+
1 row in set (0.00 sec)

从这个例子咱们能够看出，对于已经错进错出的数据表，这个命令不但没有起到“拨乱反正”的效果，还会完全将数据糟蹋，连数据的二进制编码都改变了。

正确的方法一 Dump & Reload

这个方法比较笨，但也比较好操做和理解。简单的说分为如下三步：

  1. 经过错进错出的方法，导出到文件
  2. 用正确的字符集修改新表
  3. 将以前导出的文件导回到新表中

仍是用上面那个例子举例，咱们用UTF-8将数据“错进”到latin1编码的表中。如今须要将表编码修改成UTF-8可使用如下命令

shell> mysqldump -u root -p -d --skip-set-charset --default-character-set=utf8 test charset_test_latin1 > data.sql
#确保导出的文件用文本编辑器在UTF-8编码下查看没有乱码
shell> mysql -uroot -p -e 'create table charset_test_latin1 (id int primary key auto_increment, char_col varchar(50)) charset = utf8' test
shell> mysql -uroot -p  --default-character-set=utf8 test < data.sql

正确的方法二 Convert to Binary & Convert Back

这种方法比较取巧，用的是将二进制数据做为中间数据的作法来实现的。因为，MySQL再将有编码意义的数据流，转换为无编码意义的二进制数据的时候并不作实际的数据转换。而从二进制数据准换为带编码的数据时，又会用目标编码作一次编码转换校验。经过这两个特性就至关于在MySQL内部模拟了一次“错出”，将乱码“拨乱反正”了。

仍是用上面那个例子举例，咱们用UTF-8将数据“错进”到latin1编码的表中。如今须要将表编码修改成UTF-8可使用如下命令

mysql> ALTER TABLE charset_test_latin1 MODIFY COLUMN char_col VARBINARY(50);
mysql> ALTER TABLE charset_test_latin1 MODIFY COLUMN char_col varchar(50) character set utf8;

Reference

  1. http://www.psce.com/blog/2015/03/03/mysql-character-encoding-part-2/
  2. http://www.qqxiuzi.cn/zh/hanzi-gbk-bianma.php
  3. http://zh.wikipedia.org/wiki/%E6%B1%89%E5%AD%97%E5%86%85%E7%A0%81%E6%89%A9%E5%B1%95%E8%A7%84%E8%8C%83
  4. http://www.qqxiuzi.cn/zh/hanzi-gbk-bianma.php
  5. http://blog.csdn.net/ws84643557/article/details/6905167
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程