MySQL字符集乱码简单讲解

MySQL字符集乱码简单讲解

闻名遐迩的MySQL乱码问题（转）

2009-06-07 11:22

一、概述

　　公司新购了一批PC，准备把几个性能较优的PC升级为数据库服务器，替换老旧的机器。公司有套POS终端软件，后台数据存储是 MySQL 3.23 版。我准备硬件升级的同时升级数据库软件。但是升级过程中遇到闻名的 MySQL 的乱码问题。经过查找资料，加上自己的摸索和经验，终于完美地解决这个问题。

　　MySQL 的乱码问题(不仅仅包括中文乱码，也包括其它语言的乱码，以下称之为乱码问题)只存在于4.1及其以上版本。4.1之前的 MySQL 不支持多语言，所以它会将你给它的数据“原封不动”地保存，再“原封不动”地读出来。从字节的角度来看，数据在这一过程中不会产生任何变化，因此不会有乱 码。

　　4.1及以后的版本开始支持多语言，这个所谓的多语言，就是在输入输出时 MySQL 会替你做编码转换。而这个转换规则就是由客户端编码和服务器端编码来决定的。

　　编码转换的规则就是，在输入数据时将编码由“客户端编码”转换为“服务器端编码”，输出时将数据由“服务器端编码”转换为“客户端编码”。　

二、乱码产生原因

　　MySQL 字符编码是版本4.1引入的，支持多国语言，而且一些特性已经超过了其它大多数数据库管理系统。正因为这一特性才导致 MySQL 的乱码问题。

　　字符集是一套符号和编码。校对规则是在字符集内用于比较字符的一套规则。让我们使用一个假想字符集的例子来区别清楚。

　　假设我们有一个字母表使用了四个字母：‘A’、‘B’、‘a’、‘b’。我们为每个字母赋予一个数值：‘A’=0，‘B’= 1，‘a’= 2，‘b’= 3。字母‘A’是一个符号，数字0是‘A’的编码，这四个字母和它们的编码组合在一起是一个字符集。

　　假设我们希望比较两个字符串的值(在if……else语句中我们经常做值的比较)：‘A’和‘B’。比较的最简单的方法是查找编码：‘A’为 0，‘B’为1。因为0 小于1，我们可以说‘A’小于‘B’。我们做的仅仅是在我们的字符集上应用了一个校对规则。校对规则是一套规则(在这种情况下仅仅是一套规则)：“对编码 进行比较。”我们称这种全部可能的规则中的最简单的校对规则为一个binary(二元)校对规则。

　　但是，如果我们希望小写字母和大写字母是等价的，应该怎样?那么，我们将至少有两个规则：(1)把小写字母‘a’和‘b’视为与‘A’和‘B’等价;(2)然后比较编码。我们称这是一个大小写不敏感的校对规则。比二元校对规则复杂一些。

　　在实际生活中，大多数字符集有许多字符：不仅仅是‘A’和‘B’，而是整个字母表，有时候有许多种字母表，或者一个东方的(比如中文、日文、韩 文、藏文、泰文等等)使用上千个字符的书写系统，还有许多特殊符号和标点符号。并且在实际生活中，大多数校对规则有许多个规则：不仅仅是大小写不敏感，还 包括重音符不敏感(“重音符” 是附属于一个字母的符号，象德语的‘?’符号)和多字节映射(例如，作为规则‘?’=‘OE’就是两个德语校对规则的一种)。

　　(以上摘自MySQL 5.1 手册。更多内容可参见：http://dev.mysql.com/doc/refman/5.1/zh/charset.html)

　　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使用同样的字符集才不会乱码。

三、解决方案

　　了解了 MySQL 4.1.x 以上版本字符集处理的过程，我们就知道了怎么从原理上解决这个问题。

思路：让服务器端和客户端的字符集保持一致。

服务器端的编码是由字符集(Character Set)和校对规则(Collation)决定的。

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

　　character_set_client　　　　 客户端字符集

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

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

　　character_set_database　　　　数据库采用的字符集

　　也就是说，只要保证这几个变量采用一致的字符集，就不会出现乱码问题了。

　　查看系统的字符集用下面的命令：

1 mysql> SHOW VARIABLES LIKE 'character_set_%';

2 +--------------------------+-----------------------------------------+

3 | Variable_name | Value |

4 +--------------------------+-----------------------------------------+

5 | character_set_client | utf8 |

6 | character_set_connection | utf8 |

7 | character_set_database | utf8 |

8 | character_set_filesystem | binary |

9 | character_set_results | utf8 |

10 | character_set_server | utf8 |

11 | character_set_system | utf8 |

12 | character_sets_dir | E:\usr\MySQL Server 5.0\share\charsets\ |

13 +--------------------------+-----------------------------------------+

14 8 rows in set (0.00 sec)

15

可以看到，我的这几个变量都是一致的。但如果不一致呢?网上许多教程告诉你“你set names下就解决了”。

　　那么set names是什么呢? set names实际上就是同时设置了 character_set_client ，character_set_connection和 character_set_results 这三个系统变量。

　　例如在mysql命令行上输入 set names 'gbk' 命令等同于：

SET character_set_client = gbk;

SET character_set_connection = gbk;

SET character_set_results = gbk;

在mysql 5.07之后，可以用mysql_set_character_set(MYSQL *mysql, char *csname) API函数设置字符集，该函数用于为当前连接设置默认的字符集。字符串csname指定了1个有效的字符集名称。连接校对成为字符集的默认校对。该函数的工作方式与SET NAMES语句类似，但它还能设置mysql->charset的值，从而影响了由mysql_real_escape_string()设置的字符集。

很多情况下，这样设置了之后就能把乱码问题解决了。但是还是不能完全避免出现乱码的可能，为什么呢?

　　因为character_set_client ，character_set_connection 这两个变量仅用于保证与 character_set_database 编码的一致，而 character_set_results 则用于保证 SELECT 返回的结果与程序的编码一致。

　　例如，你的数据库(character_set_database)用的是 utf8 的字符集，那么你就要保证 character_set_client ，character_set_connection 也是utf8的字符集。

　　而你的程序也许采用的并不是utf8 ，比如你的程序用的是gbk ，那么你若把 character_set_results 也设置为 utf8 的话就会出现乱码问题。此时你应该把 character_set_results 设置为gbk。这样就能保证数据库返回的结果与你的程序的编码一致。

　　到此应该就可以解决绝大多数我们遇到的乱码问题了，另外还必须强调的是，有时候乱码的出现有可能是以上几种原因混合造成的。

　　总而言之，我们应当尽量的保证数据库中的数据是正确的，就是客户端到服务器端或者服务器端到客户端转换的过程中不要产生乱码，那么问题处理起来就相对简单了。

四、总结

　　为便于大家记忆，总结为以下四点：

　　1、要保证发送的数据与数据库的字符集一致，即 character_set_client，character_set_connection 与character_set_database 一致。

　　2、要保证数据库中存储的数据与数据库编码一致，即数据的编码与character_set_database一致。

　　3、要保证 SELECT 的返回与程序的编码一致，即 character_set_results 与程序(PHP、Java等)编码一致。

　　4、要保证程序编码与浏览器编码一致，即两者要一致。

--------------------------------------------------------------------------------------

//标题：MySQL字符集简单讲解（个人总结）

//测试环境：win32 MySQL 5.0.45

//原因：自己的MySQL出现乱码问题

MySQL自4.1版本推出之后为我们国人带来的乱码问题也随之风弥整个互联网。主要原因就是不同字符集编码不同而产生的。

[align=center][/align]

先说一下MySQl的配置中都有哪几种字符集：

MySQL 4.1的字符集支持(Character Set Support)有两个方面字符集(Character set)和排序方式(Collation)。对于字符集的支持细化到四个层次: 服务器(server)，数据库(database)，数据表(table)和连接(connection)。

我们可以用下面命令检查MySQL当前字符集信息：

show variables like “character_set_%”;

show variables like “collation_%”;

MySQL4.1或以上版本的系统预设的编码是UTF-8，而我们的中文编码为：GBK，GB2312，BIG5……所以当我们把中文被当做别的字符集转化为UTF-8的字符集，再存入数据库时就会出现部分文字代码丢失而产生乱码。这就是我们查询数据库得到这些数据显示到网页上的就是“？？？？”或乱码的原因。

解决办法吗？当然也很简单，网页上随便一搜就能搜到。

解决办法（1）就是在插入数据之前先设置一下MySQL的字符集，即：mysql_query(“set names gbk”) 或是将gbk改为gb2312 或是别的中文字符集。然后再执行插入操作。

《特》《别》《声》《明》

上面的办法在我电脑上测试成功。

但我多少感觉有些不舒服，每次查询前都要写mysql_query(‘set name gbk’);。这一点我挺不满意的。于是我又开始搜索，结果我找到了下面将要讲到的配置方法

解决办法（2）：配置my.ini文件。打开my.ini 找到 [mysql] 找到default-character-set 如果你的mysql是默认安装的话这里应该是：utf8。这时将它改为：gbk或是gb2312就行了。( 即不在查询前加入mysql_query(“set names gbk”) )

《又》《出》《问》《题》《了》

我照上面的方法改了不知多少次，从gbk改到gb2312又改到utf8始终没能成功。我想了想，既然网页传值不能成功那么在命提示符下是什么样子的呢。

于是我用命令提示符打开了MySQL。测试发现在命令提示符下操作MySQL一切正常。弄到这里我的头都大了。

我又重新配置了一下PHP环境，下载的最新AppServ 2.5.9。检查一下MySQL字符集，默认字符集是UTF8。

MySQL命令：（show variables like “character_set_%”;）

然后我在不执行（mysql_query(“set names gbk”)）时向数据库执行插入，查询操作，在网页上一切都显示正常。呵呵，真是怪了！

为什么中文字却能不加转换的插入到数据库中？

又为什么中文字能不加转换的从数据库中得到正确数据？

带着这两个问题我又打开命令提示符。执行查询操作，结果显示的全是乱码（当时我想的是：文字应该为GBK编码）。于是我又执行：set names gbk; 把这个数据库字符集改为GBK字符集。再执行查询结果显示的全部是问号。这到底是怎么回事，我真的不想再研究了。

我一气之下把my.ini文件的[mysql]栏的default-character-set 注释掉了。重启MySQL后，又执行了一下操作，结果真是大出意料呀，居然正常显示了。我兴奋的不的了。结果我又查询了一下当前mysql的字符集：呵呵居然是latin1。难道是这里在做怪？然后我用PHP插入数据，查询数据库（不执行 mysql_query(“set names gbk”)），结果照样显示正常。哈哈，问题终于找到了，原来真是这里在做怪！！！

我想看到这里大家已经应该明白了，下面我做一个小总结吧。

《最》《后》《总》《结》(只是个人见解，不负任何法律责任哦！)

（1） 在mysql5.0.45环境下，数据库把由PHP传递的数据默认为latin1 (ISO-8859-1) 字符集来处理。即把latin1转换为UTF-8，然后插入。

（2） 当PHP向MySQL数据库中插入数据前执行（mysql_query(“set names gbk”)）MySQL才会以PHP查询中指定的字符集（gbk）转换为UTF-8后插入。

（3） CMD模式下操作MySQL，和用PHP操作在字符集处理上是两种概念。CMD下操作MySQL，MySQL会把CMD下的数据默认为MySQL默认的字符集转换为UTF-8后处理。而处理PHP数据MySQL会默认为 latin1 数据做处理。

《《《----我最后的配置----》》》：

因为我只是在本地作测试，为了测试时少写一行mysql_query(“set names gbk”)。所以我把 my.ini 的 [ mysql ] 栏default-characte_set 改为 latin1。这样无论自己在本地测试或是CMD下操作MySQL都很方便。但是如果你用的是PHPMyAdmin的话，可能会显示乱码，解决办法就是安装一个支持字符集为 latin1的PHPMyAdmin。字符集和字符集校对都为 latin1 ，就能正常显示了。

《关》《于》《数》《据》《库》《备》《份》

因为mysql4.1之前采用的中文字符集为 gbk 或 gb2312。建议备份和恢复数据库前先执行 set name gbk ；命令即可解决乱码问题。

-----------------------------------------------------------------------------------------

基本概念

• 字符(Character)是指人类语言中最小的表义符号。例如’A'、’B'等；

• 给定一系列字符，对每个字符赋予一个数值，用数值来代表对应的字符，这一数值就是字符的编码(Encoding)。例如，我们给字符’A'赋予数值0，给字符’B'赋予数值1，则0就是字符’A'的编码；

• 给定一系列字符并赋予对应的编码后，所有这些字符和编码对组成的集合就是字符集(Character Set)。例如，给定字符列表为{’A',’B'}时，{’A'=>0, ‘B’=>1}就是一个字符集；

• 字符序(Collation)是指在同一字符集内字符之间的比较规则；

• 确定字符序后，才能在一个字符集上定义什么是等价的字符，以及字符之间的大小关系；

• 每个字符序唯一对应一种字符集，但一个字符集可以对应多种字符序，其中有一个是默认字符序(Default Collation)；

• MySQL中的字符序名称遵从命名惯例：以字符序对应的字符集名称开头；以_ci(表示大小写不敏感)、_cs(表示大小写敏感)或_bin(表示按编码值比较)结尾。例如：在字符序“utf8_general_ci”下，字符“a”和“A”是等价的；

MySQL字符集设置• 系统变量：

– character_set_server：默认的内部操作字符集

– character_set_client：客户端来源数据使用的字符集

– character_set_connection：连接层字符集

– character_set_results：查询结果字符集

– character_set_database：当前选中数据库的默认字符集

– character_set_system：系统元数据(字段名等)字符集

– 还有以collation_开头的同上面对应的变量，用来描述字符序。

• 用introducer指定文本字符串的字符集：

– 格式为：[_charset] ’string’ [COLLATE collation]

– 例如：

• SELECT _latin1 ’string’;

• SELECT _utf8 ‘你好’ COLLATE utf8_general_ci;

– 由introducer修饰的文本字符串在请求过程中不经过多余的转码，直接转换为内部字符集处理。

MySQL中的字符集转换过程1. MySQL Server收到请求时将请求数据从character_set_client转换为character_set_connection；

2. 进行内部操作前将请求数据从character_set_connection转换为内部操作字符集，其确定方法如下：

• 使用每个数据字段的CHARACTER SET设定值；

• 若上述值不存在，则使用对应数据表的DEFAULT CHARACTER SET设定值(MySQL扩展，非SQL标准)；

• 若上述值不存在，则使用对应数据库的DEFAULT CHARACTER SET设定值；

• 若上述值不存在，则使用character_set_server设定值。

3. 将操作结果从内部操作字符集转换为character_set_results。





1.jpg

常见问题解析• 向默认字符集为utf8的数据表插入utf8编码的数据前没有设置连接字符集，查询时设置连接字符集为utf8

– 插入时根据MySQL服务器的默认设置，character_set_client、character_set_connection和character_set_results均为latin1；

– 插入操作的数据将经过latin1=>latin1=>utf8的字符集转换过程，这一过程中每个插入的汉字都会从原始的3个字节变成6个字节保存；

– 查询时的结果将经过utf8=>utf8的字符集转换过程，将保存的6个字节原封不动返回，产生乱码……





2.jpg

• 向默认字符集为latin1的数据表插入utf8编码的数据前设置了连接字符集为utf8

– 插入时根据连接字符集设置，character_set_client、character_set_connection和character_set_results均为utf8；

– 插入数据将经过utf8=>utf8=>latin1的字符集转换，若原始数据中含有\u0000~\u00ff范围以外的Unicode字符，会因为无法在latin1字符集中表示而被转换为“?”(0×3F)符号，以后查询时不管连接字符集设置如何都无法恢复其内容了。





3.jpg

检测字符集问题的一些手段• SHOW CHARACTER SET;

• SHOW COLLATION;

• SHOW VARIABLES LIKE ‘character%’;

• SHOW VARIABLES LIKE ‘collation%’;

• SQL函数HEX、LENGTH、CHAR_LENGTH

• SQL函数CHARSET、COLLATION

使用MySQL字符集时的建议• 建立数据库/表和进行数据库操作时尽量显式指出使用的字符集，而不是依赖于MySQL的默认设置，否则MySQL升级时可能带来很大困扰；

• 数据库和连接字符集都使用latin1时虽然大部分情况下都可以解决乱码问题，但缺点是无法以字符为单位来进行SQL操作，一般情况下将数据库和连接字符集都置为utf8是较好的选择；

• 使用mysql C API时，初始化数据库句柄后马上用mysql_options设定MYSQL_SET_CHARSET_NAME属性为utf8，这样就不用显式地用 SET NAMES语句指定连接字符集，且用mysql_ping重连断开的长连接时也会把连接字符集重置为utf8；

• 对于mysql PHP API，一般页面级的PHP程序总运行时间较短，在连接到数据库以后显式用SET NAMES语句设置一次连接字符集即可；但当使用长连接时，请注意保持连接通畅并在断开重连后用SET NAMES语句显式重置连接字符集。

其他注意事项• my.cnf中的default_character_set设置只影响mysql命令连接服务器时的连接字符集，不会对使用libmysqlclient库的应用程序产生任何作用！

• 对字段进行的SQL函数操作通常都是以内部操作字符集进行的，不受连接字符集设置的影响。

• SQL语句中的裸字符串会受到连接字符集或introducer设置的影响，对于比较之类的操作可能产生完全不同的结果，需要小心

===================================================================================

MySQL的字符编码体系（一）——数据存储编码

安装MySQL好多次了，每次都会纠结于数据库的字符编码配置，所以我决定这一次彻底把它理清。

MySQL的字符编码结构比较细，它大方向分为两个部分：数据存储编码和数据传输编码。本篇讨论数据存储编码部分，数据传输编码在下一篇MySQL的字符编码体系（二）——数据传输编码中讨论。

编码层次

数据存储的字符编码配置是指定数据库中存储的数据默认采用什么字符编码。默认字符编码的设置分为四个层次：服务器级、数据库级、数据表级和列级。也就是说，可以为服务器设置一个默认字符编码，再为服务器中的每一个数据库设置不同的默认编码，再为同一个数据库中的每一个数据表设置不同的默认编码，再为同一个数据表中的每一个列设置不同的默认编码。



MySQL数据库服务器的逻辑结构

那这四个层次的编码设置到底如何起作用呢？如果新建数据库时没有指定字符编码，就默认设置为服务器的编码；如果新建数据表时没有指定任何编码，就默认设置为数据库的编码；如果向数据表添加新列或新建数据表时没有特别指定某些列的编码，那么这些列就默认设置为数据表的编码。注意这里四个层次的编码都是作为“默认”的存在，用户创建数据库、表或增加列时直接指定的编码是最优先的。

另一方面，直接改变这四个层次的编码并不会改变它们各自所有下层对象的当前编码。比如修改只Server级，那么所有已经存在的数据库的默认编码不变，数据表、表列以及每一行现有数据记录的字符编码都不变，但是如果新建一个数据库且不指定其默认编码，那它的默认编码就会被设置为Server的默认编码；同样即使修改了所有四个层次的编码，但是数据表中每一条现有记录的字符字段仍然是按原来的编码存储的，但是如果向数据表中新插入一条记录，数据库将根据数据表当前各列的默认编码来存储该条记录的各个字符字段。

设置方法

修改Server以下各级编码的SQL语句如下：

ALTER {DATABASE | SCHEMA} [db_name] [DEFAULT] CHARACTER SET [=] charset_name
ALTER TABLE dbl_name [DEFAULT] CHARACTER SET [=] charset_name
ALTER TABLE dbl_name MODIFY [COLUMN] col_name {CHAR[(length)] | TEXT} CHARACTER SET charset_name

注意上面第三条修改列字符编码，实际上是通过完全重新定义列属性的方式实现的，语法跟创建新数据表时指定列字段属性一样的。所以如果这里只是想修改列字符编码，那就必须完整地写上创建该列时使用的所有定义修饰。

修改Server默认编码可以通过运行时直接修改变量character_set_server实现，但这样是临时性的，客户端关闭重启后又会自动恢复。要想永久改变Server默认编码需要在my.ini或my.cnf配置文件的“[mysqld]”区域中设定该变量的值，然后重启服务器：

[mysqld]
character_set_server=charset_name

MySQL的字符编码体系（二）——数据传输编码

MySQL的字符编码体系可以分成两部分：一部分是关于数据库服务器本身存储数据表时如何管理字符数据的编码；另一部分是关于客户端与数据库服务器传输数据如何编码。上一篇MySQL的字符编码体系（一）——数据存储编码讨论了数据存储编码，本篇讨论数据传输编码。

MySQL的客户端可以分为两种：一种就是用C语言写的官方客户端——MySQL命令程序；一种就是平常程序员使用JDBC等connector API写成的客户端。这里只讨论第一种。

Windows客户端

MySQL命令程序在Windows和Linux系统中关于字符编码处理的部分并不等效，下图是Windows系统的客户端字符编码转换逻辑：



其中的三个character变量存在于服务器上，而charset_info存在于客户端。

当客户端启动连接到服务器时，客户端将根据配置参数设置charset_info为指定编码，同时通知服务器让服务器把三个character变量设置为相同编码。

数据传输流程

客户端从控制台标准输入读取一行命令文本，其编码为操作系统编码；客户端将命令从系统编码转码为客户端charset_info变量设定的编码；客户端将命令文本发送给服务器；服务器把收到的文本解码为character_set_client编码，这个编码通常与客户端charset_info一致；服务器把命令文本转码为character_set_connection；服务器执行命令，产生结果；将结果转码为character_set_results发送给客户端；客户端把收到的结果解码为charset_info编码，这个编码通常与character_set_results一致；客户端将结果转码为操作系统编码，输出到控制台标准输出。

由于在Windows平台上MySQL程序在读取控制台时使用了Unicode Console Read API，所以程序从控制台获取的原始字符串实际上是UTF16编码，所以这里的“操作系统编码”并不是Windows通常的GBK，而应该看做UTF16。

Linux客户端

下图是Linux系统中的MySQL客户端程序字符编码转换逻辑：

<img src="http://www.2cto.com/uploadfile/Collfiles/20140714/2014071409163739.png" alt="" http:="" www.2cto.com="" kf="" ware="" vc="" "="" target="_blank" class="keylink" style="border-width: 0px; padding: 0px 0px 4px; margin: 0px; list-style: none; width:
630px; height: 534.777px;">vcyoTXlTUUy/zbuntsuy6dGvzazSu7j2se21w7W9tcTItMrHwtLC66GjPGJyPgq/ydLU1eLR+cSjxOLJz8r2tcTH6b/2o7o8YnI+CrS0vajSu7j2se2jrMbk1tDWu7D8uqzSu7j2R0JL19a3+7Su19a2zrrNVVRGONfWt/u0rtfWts6ho0xpbnV41tDG9LavTXlTUUzBrL3Ttb3K/b7dv+K3/s7xxvejrL2rt/7O8cb3tcTI/bj2Y2hhcmFjdGVyseTBv7TTxKzIz7XEVVRGONDeuMTOqkdCS6Gjz/LK/b7dv+Ky5cjr1tDOxMr9vt2jrMGivLRzZWxlY3SjrL3hufvO3tLss6OjujwvcD4KPHA+PGltZyBzcmM9"http://www.2cto.com/uploadfile/Collfiles/20140714/2014071409163740.png"
alt="\">

但是使用Windows的MySQL客户端查询时，结果却是乱码：

乱码分析

结合前面的数据传输流程，就能知道问题出在什么地方：
客户端从终端读取了一行utf8编码（Linux默认）的命令文本，忽略charset_info变量，直接把文本发送给服务器；服务器因为事先的命令charset gbk把三个character变量都设置为了GBK，所以服务器认为收到的文本是GBK编码；接下来服务器会不经过任何转码将文本字符串直接存入数据表中，因为数据表第一个字段也是GBK。 到这里为止，数据表中存了一个UTF8字符串，而服务器却当它是GBK，在同一个Linux客户端查询时：

表中的字符串不经过任何转码直接发给客户端，因为character_set_results也是GBK；客户端收到查询结果后因为忽略charset_info而直接不经过转码输出到终端标准输出；终端得到的数据实际上是UTF8编码的，所以正常输出。 在Windows客户端查询时：

表中的字符串（UTF8）不经过任何转码直接发给客户端，因为character_set_results也是GBK；客户端收到查询结果后认为是charset_info编码（此时为GBK）；客户端把查询结果从charset_info转码为UTF16，然后调用Unicode Console Write API输出，看到乱码。

乱码“修复”

如果Windows客户端也想看到正确的结果，那就要故意错误地配置：
执行命令charset utf8，这会将charset_info和三个服务器character都设置为UTF8；执行命令set names gbk，这只会将三个服务器character设置为GBK；现在select，结果看上去不再乱码了。


参考：
mysql 查看字符串的编码值
mysql 类似oracle dump 函数