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使用同样的字符集才不会乱码。
三、解决方案
了解了 MySQL 4.1.x 以上版本字符集处理的过程，我们就知道了怎么从原理上解决这个问题。
思路：让服务器端和客户端的字符集保持一致。
服务器端的编码是由字符集(Character Set)和校对规则(Collation)决定的。
上面提到，MySQL 中是根据下面几个变量确定服务器端和客户端用的什么字符集：
文章来源于领测软件测试网 https://www.ltesting.net/
