Linux.中国 - 开源社区

 找回密码
 骑士注册

QQ登录

微博登录


理解和解决 MySQL 乱码问题

2015-3-12 14:41    评论: 18 收藏: 2 分享: 41    

关于错进错出

在MySQL中最常见的乱码问题的起因就是把错进错出神话。所谓的错进错出就是,客户端(web或shell)的字符编码和最终表的字符编码格式不同,但是只要保证存和取两次的字符集编码一致就仍然能够获得没有乱码的输出的这种现象。但是,错进错出并不是对于任意两种字符集编码的组合都是有效的。我们假设客户端的编码是C,MySQL表的字符集编码是S。那么为了能够错进错出,需要满足以下两个条件:

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三个字符集完全一致就可以保证一定不会有乱码出现了。而对于已经出现乱码,或者已经遭受有损转码的数据,如何修复相对来说就会有些困难。下一节我们详细介绍具体方法。

查看其它分页:

发表评论


最新评论

我也要发表评论

湖南刘凯威 2015-3-15 14:03  新浪微博网友评论
[作揖]
回复
果果酱0o 2015-3-14 23:03  新浪微博网友评论
@我的印象笔记
回复
lyhabc 2015-3-13 15:01
收藏了
9 回复
周明智 2015-3-13 11:03  新浪微博网友评论
乱码应该是初学者必踩的坑吧
回复
nihaoxiongfei 2015-3-13 07:33  新浪微博网友评论
mark
6 回复
glson 2015-3-13 03:03  新浪微博网友评论
//@Linux中国:[赞]//@_小噗: 全文精华,也跟我N年的经验一样:“只要做到‘三位一体’,即客户端,MySQL character-set-client,table charset三个字符集完全一致就可以保证一定不会有乱码出现了。”
回复
cannshui 2015-3-12 23:03  新浪微博网友评论
MA
回复
宋万伟_song 2015-3-12 22:33  新浪微博网友评论
收藏之
回复
尉海立 2015-3-12 21:33  新浪微博网友评论
乱码真的很恼火,读了MySql的参考文档才搞定
回复
戊辰人王路 2015-3-12 19:33  新浪微博网友评论
马克
回复
ZetaZ 2015-3-12 18:33  新浪微博网友评论
……
回复
HuangBowei 2015-3-12 18:03  新浪微博网友评论
Repost
回复
超凡临时工 2015-3-12 18:03  新浪微博网友评论
//@Linux中国:[赞]//@_小噗: 全文精华,也跟我N年的经验一样:“只要做到‘三位一体’,即客户端,MySQL character-set-client,table charset三个字符集完全一致就可以保证一定不会有乱码出现了。”
回复
约瑟夫-双子座 2015-3-12 16:33  新浪微博网友评论
//@Linux中国:[赞]//@_小噗: 全文精华,也跟我N年的经验一样:“只要做到‘三位一体’,即客户端,MySQL character-set-client,table charset三个字符集完全一致就可以保证一定不会有乱码出现了。”
回复
我心飛揚Since2010 2015-3-12 15:47  新浪微博网友评论
Repost
回复
做个有bigger的男子 2015-3-12 15:33  新浪微博网友评论
@一只会说话的猪仔
回复
Linux中国 2015-3-12 15:33  新浪微博网友评论
[赞]//@_小噗: 全文精华,也跟我N年的经验一样:“只要做到‘三位一体’,即客户端,MySQL character-set-client,table charset三个字符集完全一致就可以保证一定不会有乱码出现了。”
回复
_小噗 2015-3-12 15:03  新浪微博网友评论
全文精华,也跟我N年的经验一样:“只要做到‘三位一体’,即客户端,MySQL character-set-client,table charset三个字符集完全一致就可以保证一定不会有乱码出现了。”
回复

热点评论

lyhabc 2015-3-13 15:01
收藏了
9
nihaoxiongfei 2015-3-13 07:33
mark
6
返回顶部

分享到微信朋友圈

打开微信,点击底部的“发现”,
使用“扫一扫”将网页分享至朋友圈。