关于传输格式的验证

之所以写这边博文，是为了验证之前写的博客里的规则，是否是对的。没有亲自实践过的东西总是感觉不靠谱。就自己试了下。

1. utf-8字符集验证

   举个例子,我用fidder发一个测试数据，先把字符集设为utf-8

    POST  http://127.0.0.1:11000/BloomFilter-Api/check

    User-Agent: Fiddler
    Host: 127.0.0.1:11000
    Content-type: application/json;charset=utf8
    Content-Length: 21

    body
    {"text","羽亦"}

下图是fidder发送的六十进制数据集

①英文及符号的验证。
我们可以看到发送的时候，前面是POST，我们去验证下，看看和上图中的16进制是否一致

先查出他们的unicode码

再按照之前博文写的匹配规则，得到他们的utf-8格式的二进制，及十六进制
上面的unicode码符合转化规则中的一个字节的规则。 0xxxxxxx格式
则他们的utf-8形式分别为：

U+0050 = 0050（16） = 1010000（2）
U+004F = 004F （16） = 1001111（2）
U+0053 = 0053（16） = 1010011（2）
U+0054 = 0054（16） = 1010100（2）

所以POST的的utf-8格式的16进制，则是 50,4F,53,54,查出来后和上上图中的一比对，发现是一致的。

②中文的验证。

发送数据的时候，里面有“羽亦”两个字。我们验证下这个

经过查询得知：
羽的unicode编码是7FBD,亦的unicode编码是4EA6

按照之前写的博文里面的规则转化utf-8编码
他们两个符合三个字节的规则，也就是 1110XXXX 10XXXXXX 10XXXXXX（可填16位unicode码）

先分别求出 羽，亦 的二进制编码
7FBD（羽）

0111 1111 1011 1101（2）

11100111 10111110 10111101 （utf-8）
E7 BE BD （16）

4EA6（亦）

0100 1110 1010 0110 （2）

11100100 10111010 10100110 （utf-8）
E4 BA A6 （16）

则这两个字转化为utf-8的16进制编码应该为 E7,BE,BD,E4,BA,A6.从发送的图中。发送后面确实有这样的编码。说明这个规则是对的。

2.gbk编码验证

fidder测试数据

POST  http://127.0.0.1:11000/BloomFilter-Api/check

User-Agent: Fiddler
Host: 127.0.0.1:11000
Content-type: application/json;charset=gbk
Content-Length: 21

body
{"text","羽亦"}

这是fidder发送的十六进制数据集

还是一样，我们做下验证

①英文及字符

他们gbk16进制编码分别为50,4F,53,54,和上图发送时的十六进制数据，前几个是一致的。说明死ok的。

②中文的验证

羽的gbk十六进制编码为D3F0，亦的gbk十六进制编码为D2E0。

然后去上面的发送数据找下，发下确实有D3，F2，D2，E2.

3.结论

传输格式设置为不同字符集，则就按照相应的字符集编码规转化后则发送数据。

包括为什么gbk，gb2312为黑色呢么还一直在用，这个问题都可以理解了。

从上面的发送数据中可以看出，同样的数据utf-8数据集要比gbk的长，理由呢，也显而易见，因为utf-8编码是一种可变长的编码方式。assicc码他们两个相同，但是中文的话，gbk中一个中文始终是两个字节。而在utf-8中一个汉字就是2~4个字节。

至于unicode，utf-16，大家有兴趣可以自己去看下，和这个类似。