1.1.2 模拟密码本B

密码本B的字符坐标规则：假设一个字符的密文由三部分组成，顺序分别是"表格左上角的字符串"+"表格最左边的坐标"+"表格最上方的坐标"，举例"87E5"是"囧"，"87F8"是"國"，如下第一个密码表，这些密文也是16进制的格式，下同

1.1.3 密文的加密规则

即我们可能还需要对我们拿到的密文进行再一次的加密，比如”囧”的密文是” "56E7”按照开头假设的密文规则，这是16进制的数，那我们还需要把这个16进制的56E7通过一定的规则，再次加密，针对这两个密码本的加密规则假设如下：

密码本A密文再次加密规则：

比如56E7这个密文再次加密，他转换成10进制是22247，22247在”2048-65535”的范围内，那他的加密格式就是1110xxxx10xxxxxx10xxxxxx，暂且称它为466格式，如何加密呢？如下：

• 先把56E7转换成二进制为：0101011011100111
• 按照1110xxxx 10xxxxxx 10xxxxxx的格式，对56E7转换成的二进制0101011011100111进行拆分：

首先，0101011011100111--------按照4 6 6的格式拆分后--------->0101 011011 100111

然后，对0101 011011 100111按照466格式进行转换------->11100101 10011011 10100111

把转换后的111001011001101110100111转换为16进制就是e59ba7，e59ba7就是56E7再次加密的最终密文，这样就由原来的"56E7"是"囧"变成" E59BA7"是"囧"，甚至可以根据这个加密方式，生成一个新的密码本C

密码本B的再次加密规则：

密码本B的16进制密文不再进行二次加密，直接使用获得的16进制密文，例如56E7不会与密码本A一样再次加密，直接使用56E7

第二节 漫画情景

1.2.1 情景故事

模拟一个虚构的场景，场景里的元素是：

• 远在外地的小明
• 与小明同部门的小丽
• 安全部门的同学
• 与小明同部门的小红
• 一个信息安全非常严格的公司
• 加密的档案管理

今天，小明需要将一个很重要的数据，告诉公司的小丽把这个数据存到小明自己的档案里：

、

小明发现，他获取到的数据是“闃块噷”,而不是3天前存储的”阿里”，如果小明意识到自己的错误，把小红寄给他的数据先转换成密码本B的密文，再用转换的密文对照密码本A查找呢？

第二章 Mysql的乱码

如果上面的场景，放到数据库里，会一样吗？拿mysql作为例子，测试一下,数据从客户端发送到server并存入表中成为数据然后查询该数据的过程，mysql中控制这个过程的编码的参数主要是character_set_client，character_set_connection，character_set_results，表字符集以及程序字符集等，可以看下文档。

第一节      mysql的情景对应

字符集：
unicode  gbk
字符编码规则：
utf8：只针对unicode，相当于第一章情景中的二次加密
gbk：不对gbk再编码

参数与情景对应:
程序字符集：小明加密数据时使用的密码本A
character_set_client:小明在寄信时，写错了数据加密方式，写的是密码本B，而不是A
character_set_connection:安全规则，需要转换的加密格式
character_set_results:寄信时需要使用的加密格式
表或者库字符集:小明的档案的加密格式
Server端处理:小丽/小红

第二节      mysql测试

2.2.1 第一次测试

参数设置：
程序字符集:utf8
character_set_client:utf8
character_set_connection:utf8
character_set_results:utf8
表或者库字符集:utf8
Server端处理:mysql program 

测试结果：无乱码

2.2.2 第二次测试

参数设置：
程序字符集:utf8
character_set_client:gbk
character_set_connection:utf8
character_set_results:utf8
表或者库字符集:utf8
Server端处理:mysql program 

测试结果：只设置set character_set_client=gbk后，查询乱码

2.2.3 乱码猜猜猜

结合第一章的场景，为什么乱码呢？

2.2.3.1 第一步处理

程序将"阿里"以utf8编码进行转换发送(unicode转utf8与情景中的规则一致)，但是不小心在session中设置了character_set_client=gbk，character_set_connection =utf8，character_set_results=utf8，类似如下现象：

形状：阿里

Utf8方式下的16进制编码值：E998BF E9878C

二进制：11101001 10011000 10111111 11101001 10000111 10001100(utf8将2个汉字转换后6个字节)

2.2.3.2 第二步处理

到达server端，server通过character_set_client=gbk知道客户端发过来的数据是gbk编码的（实际是utf8编码的，客户端不小心写错了），那server端就按照gbk来解码了，解码后如下：

二进制：11101001 10011000 10111111 11101001 10000111 10001100(程序端的两个汉字经过utf8转换后的二进制数据，一共6字节，但是server端不知道，因为server通过character_set_client=gbk得知，这不是utf8，这是gbk的，我要按照gbk来解码)

gbk转换后的16进制编码值：E998 BFE9 878C(通过这个编码，查找gbk的码表，获取他的形状为：闃块噷)

2.2.3.3 第三步处理

Servre还需要检查character_set_connection参数，发现character_set_connection=utf8，而之前是gbk，那就需要将gbk的这三个字节转换为utf8，怎么转换呢？按照第一章的情景，先转unicode(密码本A)，再将得到的unicode再次编码为utf8：

“闃块噷“三个字符的unicode编码是 95c3 5757 5677

转换成二进制：10010101 11000011 01010111 01010111 01010110 01110111(这三个汉字是6个字节)

通过unicode，再转换为utf8的实现方式，实现方式如下：

首先转换95c3( 1001010111000011)，他的范围在第三行（3字节）

1001 010111 000011,根据第三行的格式，从低位往高位的顺序，按照格式分成4 6 6 的格式

按照格式填充，填充后：11101001 10010111 10000011,填充后转换成16进制是e99783，则”闃”在utf8中就是”e99783”，同样，”块”在utf8中就是” e59d97”,” 噷”在utf8中就是” e599b7”, 于是转换后的结果就是：

编码：E99783 E59D97  E599B7

二进制：111010011001011110000011111001011001110110010111111010000000000000000000

2.2.3.4 第四步处理

server端处理好之后，继续向下走，准备存储数据了，检查了存储的表是utf8的，不需要转换了，直接存储

编码：E99783 E59D97  E599B7

二进制：111010011001011110000011111001011001110110010111111010000000000000000000

2.2.3.5 查询返回

程序插入完成后，想查询下之前插入的数据，于是客户端在当前session下执行了select操作，server端收到请求后，去表里找数据，找到了之前写入的数据

111010011001011110000011111001011001110110010111111010000000000000000000

server检查character_set_results=utf8,与表的字符编码是一致的，那就不需要转换了，直接把111010011001011110000011111001011001110110010111111010000000000000000000给程序了，程序收到后，就解码111010011001011110000011111001011001110110010111111010000000000000000000，因为程序本身也是utf8的，不需要转换，于是按照utf8来解码数据，111010011001011110000011111001011001110110010111111010000000000000000000的16进制是E99783E59D97E599B7(符号是闃块噷，乱码了)