微信蓝牙协议二：1800 or 18914E结尾和Varint压缩算法

一、概述

使用不同设备抓取空中数据时发现，虽然APP下发数据相同，但有些设备返回的微信数据结尾是1800，有些设备结尾却是18914E。而使用上又没有影响。1800我们已经填充过，但18914E是怎么出来的呢？

二、18914E由来

经过上一章的梳理，可以知道无论1800还是18914E，都是第三部分的不同形式。在第三部分组包时可以看出，对于RecvDataPush命令来说，key-value中，key的值是0x18固定不变，只是根据EmDeviceDataType的三个枚举值导致value变化。

不难看出18914E对应的是：

EDDT_wxDeviceHtmlChatView = 10001; // 微信客户端设备 html5 会话界面数据

10001转换成十六进制是0x2711，与18914E对不上。
到这里就需要关注重点关注《Protocol buffer》中提到的Varint算法。

显然enum是需要使用Varint算法的。同样第二部分的value，也就是数据长度06，也是采用了Varint算法。只是因为6小于128，所以没有体现出来。
当要传输的应用数据不是6个字节的33008001a223，而是大于127字节时，就需要用到这种算法。此时如果直接将06替换成字节数如0x80(128字节)就会导致错误。如果不熟悉协议细节，对于蓝牙设备端查找问题会比较麻烦。

三、Varint算法

简单的理解，采用Varint算法，分为三步：

1. 将数据从最低位（LSB）开始，按照7bit分割成若干个字节：
   byten byte2 byte1 byte0
2. 将分好的字节按照逆序排列：
   byte0 byte1 byte2 byten
3. byten的最高位bit7填充0，其余字节的bit7均填充1即可。

示例1：

第一步：value值为6： 二进制表示110
第二步：不到7bit，只有一个byte0
第三步：byte0的bit7填充0，结果是：0000 0110 ，仍然是0x06

示例2：

value值为10001： 二进制表示10 0111 0001 0001
第一步：从lsb开始按照7bit分割：1001110 0010001
第二步：逆序排列为：0010001 1001110 
第三步：分割成两个字节，所以第一个字节bit7补1，第二个字节bit7补0。
结果是：10010001  01001110，结果是0x91 0x4E

更多Varint算法内容可以参考以下两个链接：

1. varint压缩算法详解_渔道的博客
2. Varint数据压缩算法_milanac007的专栏