MySQL乱码问题深层分析（2）

MySQL 4.1.x开始支持以下这些事情

l 使用多种字符集(Character Set)来存储字符

l 使用多种校对规则(Collation)来比较字符串

l 在同一台服务器、同一个数据库或甚至在同一个表中使用不同字符集或校对规则来混合字符串

l 允许定义任何级别的字符集和校对规则

MySQL 4.1及以上版本的字符集支持(Character Set Support)有两个方面：字符集(Character Set)和校对规则(Collation)。 字符集和校对规则有4个级别的默认设置：服务器(server)，数据库(database)，数据表(table)和连接(connection)。

MySQL 中是根据下面几个变量确定服务器端和客户端用的什么字符集：

character_set_client　　　　 客户端字符集

character_set_connection　　 客户端与服务器端连接采用的字符集

character_set_results　　　　　SELECT查询返回数据的字符集

character_set_database　　　　数据库采用的字符集

MySQL的字符集处理是这样的：

1、发送请求。

1)客户端发送请求到服务器端。

2)服务器端会把请求的数据从客户端字符集(character_set_client)转成服务器连接字符集(character_set_connection)。

3)然後服务器会检测存储区域(table，column)的字符集，然后把数据从连接字符集(character_set_connection)转为存储区域(table，column)的字符集，然後再存储或者查询。

2、返回请求。

1)服务器将存储区域(table，column)的字符集转换成服务器连接字符集(character_set_connection)。

2)将服务器连接字符集(character_set_connection)转换成结果字符集(character_set_results)，再发送到客户端。

例如，我建立一个字符集为 gbk 的数据库(服务器端)。(MySQL 4.1 开始，在建立数据库时要指定它的字符集和校对规则，不指定就用默认的字符集和校对规则。)

连接数据库的程序(客户端)使用 gb2312 字符集(如 windows 命令行下使用 MySQL ，或者 PHP 连接MySQL )，那么在执行 insert 命令时，insert 的字符串将做一个 gb2312 到 gbk 的转换。而 select 时，数据库中保存的数据会先经过 gbk 到 gb2312 的转换之后再给你(结果集)。

好，那么为什么升级3.23(或4.0)到4.1时会乱码?举个例子说明。

例如3.23的数据库中保存的是gbk编码的数据。升级之前我将这些数据导出保存到文件里，这个文件的编码当然也是gbk的(因为3.23不支持多语言，不会对数据进行转换，也就是前面说的“原封不动地保存，原封不动地读出”)。

然后我在4.1中建立一个数据库，字符集为A;客户端字符集为B。将刚才的gbk数据导入。

1)A=gbk，B=gbk

导入数据时数据不会被转换;读出时需要set names gbk(set name命令下面将讲解)。

2)A=latin1，B=gbk

导入数据会进行gbk->latin1的转换，可能会丢失数据，产生乱码。

3)A=gbk，B=latin1

导入数据会进行latin1->gbk转换，可能会产生乱码。

4)A=latin1，B=latin1

导入数据时不会进行转换;读出时不需要set names gbk 。

大家可以看到，上面1)、4)才是正确的做法，即让A和B使用同样的字符集才不会乱码。