参考mysql编码问题——charset=utf8你真的弄明白了吗？
详细介绍客户端字符集、联接器connection、MySQL server字符集的设置。
1 明确问题
1.1 什么是字符集
所有数据在计算机底层都是以二进制形式保存。
将字符比如汉字转换为二进制的过程，称为编码。
将二进制转换为字符的过程，称为解码。
编码和解码时采用的规则，就是字符集。
(1)美国常用字符集：ASCII
使用7位二进制进行编码。
总共128个字符，不支持中文。
(2)欧洲常用字符集：ISO-8895-1
使用8位二进制进行编码。
总共256个字符，不支持中文。
(3)中国简体字字符集：GBK
(4)中国繁体字字符集：Big5
(5)包含世界上所有语言和字符的字符集是Unicode万国码
常见是：utf-8
可放emoji表情符号的utf8mb4
utf-16
utf-32
开发人员一般使用utf8mb4字符集
但Windows系统在中国默认字符集是GBK
乱码原因：编码和解码所使用字符集不一致
所谓容量，这里指用几个字节表示一个字符，显然用的字节越多，编码空间越大，能表示更多不同的字符，也即容量越大。
1.2 查看数据库默认字符集
mysql> show character set;查看数据库支持的所有的字符集。
mysql> status;查看系统当前状态，里面可以看到部分字符集设置。
mysql> show variables like '%char%';查看系统字符集设置，包括所有的字符集设置
(1)查看数据库支持的所有的字符集。
(2)查看系统当前状态，里面可以看到部分字符集设置
(3)查看系统字符集设置，包括所有的字符集设置
1.3 当前电脑使用的字符集
打开电脑黑窗口(CMD)，接着在空白边框点击鼠标右键，然后选择属性，并查看"选项"这一栏。可以看到CMD中输入文字使用的字符编码是GBK。
1.4 建表语句引出的问题
create database mytest;
use mytest;
(1)建表时指定charset=utf8
create table student1(
sid int primary key auto_increment,
sname varchar(20) not null,
age int
)charset=utf8;
insert into student1(sname,age) values ("songjiang",40);
insert into student1(sname,age) values ("林冲",32);
select * from student1;
当建表时指定charset=utf8的时候，此时可以插入中文，并且不乱码。
(2)建表时不指定charset=utf8
create table student2(
sid int primary key auto_increment,
sname varchar(20) not null,
age int
);
insert into student2(sname,age) values ("songjiang",40);
insert into student2(sname,age) values ("林冲",32);
select * from student2;
当我们建表不指定 charset=utf8，此时插入中文，会报错。ERROR 1366 (HY000): Incorrect string value: ‘\xC1\xD6\xB3\xE5’ for column ‘sname’ at row 1。
1.5 定位问题
建表时我们指定charset=utf8。
客户端client输入的字符，都是采用GBK编码的。
mysql服务器存储的字符又是UTF8编码的。
那么，我们向数据库中插入数据，从数据库中查找数据，返回到界面中，要想保证字符不乱码，肯定是经过了"编码转换过程的"。
究竟是什么东西完成了这个编码的转换过程的？
通过上图我们可以看到有一个东西，叫做"connection"，中文名叫做"连接器"。"连接器"就是那个问题的答案。也就是说：这个转换过程依赖的就是这个connection。
2 连接器
2.1 连接器的作用与工作流程
一、连接器的作用
连接客户端与服务端，进行字符集的转换。
连接器有这种自动转换的功能。
二、连接器的工作流程
(1)客户端的字符先发给连接器，连接器选择一种编码将其转换，进行临时存储。
转换之后的编码，与连接器的编码格式一致。
(2)接着，连接器再次转换成服务器需要的编码，并最终存储在服务器中。
(3)然后，服务器返回的结果，再次先通过连接器，连接器将其转化为与客户端一致的字符集，就可以在客户端正常显示了。
2.2 连接器的字符集是UTF8
在CMD窗口中输入的字符，采用的字符集是GBK，也就是说客户端(client)的字符集是GBK。而写入到数据库中数据采用什么格式写入，我们在建表的时候已经指明了"charset=utf8"，也就是说，mysql服务器(server)的字符集是UTF8。
假如说连接器的字符集是UTF8，这个写入数据库的过程是怎么进行的呢?
(1)首先，在客户端输入的字符，使用的字符集是GBK。
当经过连接器的时候，连接器会进行"字符集的自动转换"，将原来的以GBK进行编码字符转换为以UTF8格式的编码字符，临时存储在连接器中。
(2)接着，连接器发现mysql服务器使用的字符集，与自身字符集完全一致，都是UTF8。于是，直接发给mysql服务器，进行最终的存储。
当我们从mysql服务器查数据的时候，返回过程又是怎么进行的呢？
(1)首先 ，mysql服务器会将结果以UTF8编码格式进行返回，通过连接器的时候，连接器发现mysql服务器的字符集，与自身字符集一致，于是顺利通过连接器。
(2)当连接器准备将结果发送给客户端的时候，发现客户端要求返回的字符集是GBK。因此，连接器会进行"字符集的自动转换"，将以UTF8编码的结果()转换为以GBK编码的结果，进行显示，并最终发送给客户端，显示在CMD窗口中。
2.3 连接器的字符集是GBK
假如说连接器(connection)的字符集是GBK，这个过程又该是怎么进行的呢？
(1)首先，在客户端输入的字符，使用的字符集是GBK。当经过连接器的时候，连接器发现客户端发送过来的字符的字符集，与自身字符集相同，因此顺利通过了连接器。
(2)接着，当字符通过连接器发送给mysql服务器进行存储的时候，发现mysql服务器的字符集是UTF8，与自身的字符集GBK并不一致。因此，连接器此时又会进行"字符集的自动转换"，将以GBK进行编码的字符转换为以UTF8格式的编码，转换完成以后，再次发送给mysql服务器，进行最终的存储。
当我们从mysql服务器查数据的时候，返回过程又是怎么进行的呢？
(1)首先 ，mysql服务器会将结果以UTF8编码格式进行返回，通过连接器的时候，连接器发现mysql服务器的字符集，与自身的字符集并不一致，于是连接器会进行"字符集的自动转换"，将以UTF8进行编码的结果转换为以GBK格式的编码。
(2)接着连接器又将转换后的结果，准备发送给客户端，此时发现客户端的字符集，与自身的字符集一致。因此直接发送给客户端，成功在CMD窗口中显示。
3 代码演示过程
set character_set_client=gbk;设置客户端的字符集
set character_set_connection=utf8;设置连接器的字符集
set character_set_results=gbk;设置返回结果的字符集
要想不乱码，需要指定客户端的编码，让连接器不理解错误,这样就不会存入错误数据。
往回取数据的时候，还要告诉连接器，如果你从服务器返回，你应该给我转成什么格式。
因此，一共需要设置3个参数：
1、客户端发送的编码；
2、连接器使用的编码；
3、返回数据的编码；
3.1 连接器字符集UTF8
一、当前的情况是：客户端是GBK，服务器最终存储的是UTF8。
(1)因此，你就要明确告诉服务器，我的客户端是GBK的。
set character_set_client=gbk;
(2)再告诉连接器，使用UTF8。
set character_set_connection=utf8;
(3)再告诉，如果你返回值给我看的话，也请返回GBK。
set character_set_results=gbk;
insert into student1(sname,age) values ("武松",32);
二、我的客户端是GBK，但是我偏要骗对方是UTF8。
set character_set_client=utf8;
insert into student1(sname,age) values ("西门庆",32);
报错如下
ERROR 1366 (HY000): Incorrect string value: '\xCE\xF7\xC3\xC5\xC7\xEC'
for column 'sname' at row 1
此时，"西门庆"对应的GBK的内码，转换成UTF8，压根就出错，不允许插入。
三、我偏要对方返回给我的数据是UTF8。
set character_set_client=gbk;
set character_set_results=utf8;
3.2 连接器字符集GBK
一、client、connection、server字符集设置的都是GBK，不会导致乱码。
如果三者都是GBK，可以简写成如下形式：set names gbk;
声明客户端是GBK；
set character_set_client=gbk;
声明连接器是GBK；
set character_set_connection=gbk;
声明返回值是GBK；
set character_set_results=gbk;
插入中文数据
insert into student1(sname,age) values ("西门庆",32);
二、现在，我偏偏声明连接器的字符集是latin1。
set character_set_connection=latin1;
插入中文数据
insert into student1(sname,age) values ("潘金莲",32);
3.3 产生乱码的两个原因
(1)解码与实际编码，不一致导致的乱码，可修复。
(2)在传输过程中，由于编码不一致，导致部分字节丢失，造成的乱码，不可修复。
4 系统默认情况
我们使用图中的这个命令，可以查看系统所有的字符集的设置。
从图中可以清楚的看到，客户端的字符集默认是gbk，连接器的字符集默认是gbk，返回值的字符集是gbk，mysql服务器的字符集默认是latin1。
上述设置，是不是和图二中的情况，非常相似。唯一不同的就是系统默认mysql服务器的字符集是latin1，而图二中mysql服务器的字符集是utf8。
系统为什么将mysql服务器默认使用latin1字符集？
为什么要这么设置呢？因为latin1不支持中文，当我们插入中文的时候，当客户端发送过去的字符，通过连接器，最后发送给mysql服务器的时候，连接器发现mysql服务器采用的字符级是latin1，字符集由gbk转化为latin1，就相当于大鱼过小渔网一样，一定会掉肉，而对于字符集来说就会丢失字节。丢失字节后存入的值，肯定也就是错误的，不正确的。
由于mysql的检测是很严格的，既然你存入的时候都会丢失字节，那么存入的值肯定也是错误的，因此，我索性就不让你插入。“这就是我们不设置mysql服务器字符集，想要插入中文，提示1366错误的原因。”"ERROR 1366 (HY000): Incorrect string value: ‘\xD5\xC5\xC8\xFD’ ““for column ‘sname’ at row 1”
当我们使用"charset=utf8"命令，将mysql服务器的字符集设置为utf8后，由于utf8是支持中文的，utf8是变长字符集，它能够支持全世界所有国家的语言。因此，当你输入一个以gbk格式编码的中文，在utf8中肯定是也有自己的一套编码格式，显示同样的文字(只不过此时是以utf8编码的)。
最后用一个不那么恰当的比喻，来说明字符集编码。
拿一本新华字典(汉语字典)，再拿一本牛津字典(英语字典)。此时，我们要查找一个同一个词"中国”，在汉语字典中，"中国"采用的编码是zhongguo，但是在牛津字典中，“中国"采用的编码是china，你非要拿着zhongguo去牛津字典中查"中国”，你觉得你得到的结果是正常显示，还是乱码呢？