这个抓包案例的字符变化图解：
附：mysql字符编码操作技巧
【查看字符集设置】
| mysql> show variables like '%char%'; +--------------------------+-----------------------------------------------------+ | Variable_name | 说明 | +--------------------------+-----------------------------------------------------+ | character_set_client | 客户端字符集 | | character_set_connection | 当前连接字符集 | | character_set_database | 数据库字符集 | | character_set_filesystem | 文件系统字符集，不要修改，使用binary即可 | | character_set_results | 返回结果集字符集 | | character_set_server | 服务器默认字符集，当数据库、表、列没有设置时， | | | 默认使用此字符集 | | character_set_system | 固定为utf8 | +--------------------------+-----------------------------------------------------+ |
【修改字符集设置】
服务器的配置在服务器建立的时候就由DBA设置好了，不推荐后续再改
通过SET NAMES utf8命令同时设置character_set_client/character_set_connection/character_set_results的字符集
建议所有配置都设置成utf8
【问题答案】
思考一下1：为什么客户端和连接都设置了latin1，但最终发送的是正确的utf8编码呢？
客户端设置了latin1，而我的语句是从notepad++中写好的，是utf8格式的；
中文utf8是3个字节，而latin1是按照单个字节解析的，虽然进行了转换，但不会导致二进制内容的变化，但实际上mysql客户端认为我输入了3个latin1字符；
如果客户端设置的编码是2个字节的gbk，这时转换就会发生乱码，utf8的3个字节会被转换为1个gbk字符（可能是乱码，也可能不是乱码）加上一个西欧字符（小于128就是英文，大于128就是其它西欧文）
思考一下2：为什么接收到的还是正确的utf8编码？
这是因为mysql服务器从将数据从“列”的编码（utf8）转换为latin1了，而列存储的数据并不是真正的utf8的中文“你”对应的"0xe4 0xbd 0xa0"，
而是后面抓包看到的“c3a4 c2bd c2a0”（6个字节），mysql服务器将utf8的c3a4转换为latin1的0xe4，c2bd转换为0xbd, c2a0转换为0xa0
思考一下3：为什么latin1显示了正确的utf8字符？
因为mysql客户端收到了mysql服务器转换后的"0xe4 0xbd 0xa0"，并把这个数据当做latin1的3个字符处理，然后抛给终端（我的是SecureCRT），
SecureCRT又把这三个latin1当做uft8处理，结果中文的“你”就显示出来了。
