6、产生乱码的两个原因
解码与实际编码，不一致导致的乱码，可修复。
在传输过程中，由于编码不一致，导致部分字节丢失，造成的乱码，不可修复。
1）编码和解码不一致导致的乱码
2）传输过程中，丢失字节导致的乱码。
7、对实际情况的分析(什么都不设置，系统默认是如何呢？)
1）MySQL系统参数如下
根据上图可以知道：
我们使用图中的这个命令，可以查看系统所有的字符集的设置。从图中可以清楚的看到，客户端的字符集默认是gbk，连接器的字符集默认是gbk，返回值的字符集是gbk，mysql服务器的字符集默认是latin1。
上述设置，是不是和图2(如下所示)中的情况，非常相似。唯一不同的就是系统默认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去牛津字典中查"中国”，你觉得你得到的结果是正常显示，还是乱码呢？
2）set names gbk的含义
当客户端、连接器、返回值的字符集相同，并且都是gbk的时候，我们可以采取如下的简写方式： set names gbk; 这就话其实包含了三层意思： set character_set_client=gbk; set character_set_connection=gbk; set character_set_results=gbk;
