我目前正在开展一个小型项目尝试用JavaScript解码协议缓冲流，我发现一些非常奇怪的数据与编码规范不匹配（{{3 }}）。
我无法访问.proto文件，因此我无法仔细检查并查看字段的外观，因此我只是编码编码规范并希望它能正常工作。 / p>
以下是一个似乎正确编码的对象示例（请注意，二进制数据已转换为十进制数，并且出于安全原因，两个字符串中的所有字符都已更改为＆＃39; x＆＃39;字符）：
8 6 18 15 88 88 88 88 88 88 88 88 88 88 88 88 88 88 88 26 3 88 88 88
根据规范，这应该通过以下方式解析：
8 - field number 1, wire type 0
6 - first and last byte of varint, value 6
18 - field number 2, wire type 2
15 - string length of 15 characters
88 - x (times 15)
26 - field number 3, wire type 2
3 - string length of 3 characters
88 - x (times 3)
所以这最终会解析为以下数据：
field 1: 6
field 2: xxxxxxxxxxxxxxx
field 3: xxx
现在这是一个没有正确解析的对象：
8 56 58 18 12 88 88 88 88 88 88 88 88 88 88 88 88 26 7 88 88 88 88 88 88 88
通过我的解析器运行，我得到以下内容：
8 - field number 1, wire type 0
56 - first and last byte of varint, value 56
58 - field number 7, wire type 2
18 - string length of 18 characters
at this point the next 18 characters are parsed as "byte" data, which is clearly not correct
我的问题/混淆是在第二条消息的前4个字节周围：
8 56 58 18
看起来似乎有一个2字节的varint，56和58，但56的高位显然没有设置，所以在尝试解析varint时它会在那里结束。
有谁知道为什么这个额外的字节似乎正在悄悄进入，以及我应该如何应对它？ protobuf编码规范似乎并没有表明任何看起来相似的东西。
更新
我还没有设法解决这个问题，但我发现我可以通过protoc命令运行相同的二进制数据，该命令吐出一个有效的对象，因此它显然是有效的。当我有机会看到他们是如何做的时候，我可能会调查他们的代码