MySQL字符集问题

遇到了这么个问题，数据库表的字符集是utf8，但客户端程序在建立连接时设置了：set names latin1。

查询数据库中的中文字符“尊”的列，返回的是”尚“。

“尊”和“尚”被错误的认为是相等的。

要解释上边的怪现象需要先明确以下几个概念：

MySQL Charset（字符集）

MySQL Collate（校对集）

character_set_client

character_set_connection

character_set_results

需要知道这三个函数

hex()

unhex()

convert()

这几个概念网上的资料很多，在这里就不废话了。

需要特别说明下，character_set_client是客户端传输数据到服务器端使用的字符集。

character_set_connection是服务器端在处理文本时默认使用的字符集。这个character_set_connection因为名字用了connection，比较容易产生误解，我一开始就误解成了客户端和服务器端建立连接使用的字符集。


假设set names utf8，此时character_set_connection的值将被设置为utf8.

执行 select‘尊’;

相当于 select (_utf8 ‘尊’)

(在这里我们使用一个比较特殊的符号“_utf8”，它叫做“引介词”，可参考资料)


单独的一个select并不能说明问题，我们对字符串进行一下比较，执行以下SQL：

select * from test where name=’尊’

假设列test.name的字符集是utf8，此时字符串’尊’的字符集也是utf8，将直接进行比较，不需要进行字符集转换。

此时的SQL相当于：

select * from test where name = (_utf8 ‘尊’)


如果set names gbk后再次运行以上SQL，此时test.name的字符集仍然是utf8，但‘尊’的字符集变成了gbk，等价SQL如下：

select * from test where name = (_gbk ‘尊’)

在进行字符串比较时会进行隐式的字符集转换。

关于字符集比较和隐式转换可参考资料（MySQL Manual - Collation of Expressions

）

理解了以上几个概念，我们解释下文章开头的怪现象。

由于设置了set names latin1，字符从客户端传到服务器端使用的是latin1字符集

由于数据库表中的字符集是utf8，在进行比较的时候会再次将latin1的字符隐式转换成utf8。

以上比较绕的整个过程可以简化为如下一条SQL：

select convert(_latin1’尊’ using utf8)

(将’尊’先转化为latin1编码，再转换为utf8编码)

前期存到数据库的汉字“尚”也是这样一个转换过程，使用如下SQL检验：

select convert(_latin1’尊’ using utf8) = convert(_latin1’尚’ using utf8);

返回结果为相等。

以上实验只是重现了相等的过程，并没有解释为什么会相等。

这牵扯latin1编码的问题。Latin1是单字节编码，不认识汉字，但将汉字转换成latin1编码的时候将保留原来的编码格式直接存储。如汉字“尊”和“尚”的编码为：

select hex(‘尊’) => E5B08A

select hex(‘尚’) => E5B09A

这两个汉字被编码为3个字节，这三个字节在latin1字符集里对应的字母是：å°Š和å°š

这两个字符串å°Š和å°š在UTF8的默认比较规则下相等。

查看’尊’被转换后成为的十六进制：

select hex(convert(_latin1’尊’ using utf8)) => C3A5C2B0C5A0

查看’尊’被转换后对应的字符：

select unhex(hex(convert(_latin1’尊’ using utf8))) => å°Š

OK，解释完毕。

总结如下：

不能瞎用latin1连接去查询或操作utf8编码的数据库数据。