这次我们来说一下在Mysql中的编码问题：
我们知道应用于计算机的最早的字符集是ASCII，它所组成的编码是ASCII编码；由于对于其他国家来说它所容纳的字符个数比较少，后来就出现了ANSI字符集，它的编码就是本地编码，由于各个国家的本地编码不相同，导致互相不兼容，最后就出现了Unicode字符集，它规定全世界通用一张码表，用4个字节来编号，但是我们常用的字符集中在前65535个编号里，用两个字节就够了，那么我们就可以简化编码，比如：
unicode用0000 0000 0000 0000 0000 0000 000 0041表示A
而我们可以用0000 0041来表示A
把高位浪费的0值，按照一定的规则舍弃掉，这样形成的编码方式是UTF方式，而最著名的就是UTF-8编码方式。
简单的形容Unicode与UTF-8 的关系：就像是原文件--->压缩文件 的关系。UTF-8是一种变长的编码方式，它编码时所占的字节如下图所示：
而GBK则是中国汉字的一套编码方式
那么乱码是如何形成的？
主要有两点
- 解码时与实际编码不一致（可修复）
- 传输过程中，编码不一致，导致字节丢失（不可修复）
连接器的特性： 连接客户端与服务器
客户端的字符先发给连接器，连接器选择一种编码将其转换，临时存储，然后再次转换成服务器需要的编码，并存储在服务器里。
要想不乱码，需要指定客户端的编码，让连接器不理解错误，这样就不会存入错误数据，往回取的时候，我们还要告诉连接器，如果你从服务器返回，应该返回什么格式的编码。
一共是三个参数，客户端的发送的编码，连接器使用的编码，获取的返回数据的编码。
举个例子：
当前的请况是，客户端GBK，服务器最终存UTF8
我明确的告诉服务器：我的客户端是GBK的：
Set character_set_client=gbk;
再告诉连接器，使用UTF8：
Set character_set_connection=utf8;
再告诉，如果返回值，请返回GBK的结果：
Set character_set_results=gbk;
如果我偏要对方给我返回的数据是UTF8：
Set character_set_results=utf8;
我们可以看到出现了乱码，但是这些乱码都是可以修复的
再来看另一种情况：
我先声明客户端，连接器，服务器都是gbk格式：
我们插入一条数据，然后显示它：
可以看出没有乱码；
我们再把连接器的编码改成latin1：
Set character_set_client=latin1;
然后我们插入数据：
然后我们再显示它：
可以看到出现了乱码，而且这种乱码是不可修复的，latin1小，gbk大，就像大鱼过小鱼网，丢了块肉。
因此要想不乱码，必须使服务器>=连接器>=客户端
如果3者都是gbk，那么就可以简写成set names gbk;
我们打开记事本，先输入一个“联通”，然后把它保存起来并关闭：
然后我们再次打开它
我们会发现它变成了乱码。
其实这是因为记事本在打开的时候，它也不知道你用的是什么编码，它是靠分析编码的特点来推测的，如果字节比较少，就容易推测错。
推荐链接：https://www.bilibili.com/video/av19538278/?p=41