Protocol Buffers编码详解，例子，图解

Protocol Buffers 编码详解，例子，图解

本文不是让你掌握protobuf的使用，而是以超级细致的例子的方式分析protobuf的编码设计。通过此文你可以了解protobuf的数据压缩能力来自什么地方，版本兼容如何做到的，其Key-Value编码的设计思路。如果你详细了解此文，你应该就能具备自己造一套编解码轮子的能力（至少基本思路）。

测试的例子

阅读图片时请对比前面的例子和表格。每个字段的名称都是包含了tag的。

message S2 {  optional int32 s2_1 = 1;  optional string s2_2 = 2 ; } enum E1  {  E1_1 = 1;  E1_3 = 3;  E1_5 = 5; } message  S3 {  optional int32 s3_1 = 1;   //设置为0x88  optional int32 s3_2 = 2;   //设置为0x8888  optional uint32 s3_3 = 3;  //设置为0xE8E8E8  optional uint32 s3_4 = 4;  //设置为0xE8E8E8E8  optional int64 s3_5 = 5;   //设置为0x8888  optional int64 s3_6 = 6;   //设置为0xE8E8E8E8  optional uint64 s3_7 = 7;  //设置为0xE8E8E8E8  optional uint64 s3_8 = 8;  //设置为0xE8E8E8E8E8E8E8E8  optional sint32 s3_9 = 9;  //设置为0x8888  optional sint32 s3_10 = 10;   //设置为-0x8888  optional sint64 s3_64 = 64;   //注意这个tag id  设置为0xE8E8E8E8  optional sint64 s3_65 = 65;   //注意这个tag id  设置为-0xE8E8E8E8  optional E1 s3_11 = 11;    //设置为E1_5  optional bool s3_12 = 12;  //设置为true  optional float s3_13 = 13; //设置 float，设置为88.888  optional fixed32 s3_14 = 14;  //设置为 0x8888  optional sfixed32 s3_15 = 15; //设置为 -0x8888  optional double s3_16 = 16;   //设置 double，设置为8888.8888  optional fixed64 s3_17 = 17;  //设置为 0x8888888888  optional sfixed64 s3_18 = 18; //设置为 -0x8888888888  optional string s3_19 = 19;   //设置为 "I love you,C++!"  optional bytes s3_20 = 20; //设置为 "I hate you,C++!"  repeated int32 s3_21 = 21; //设置为3, 270, and 86942, 用google文档的例子  repeated int32 s3_22 = 22 [packed = true]; //设置为3, 270, and 86942  repeated string s3_23 = 23;   //设置为"love","hate","C++"  optional S2 s3_24 = 24;    //设置为 0x1,"love"  repeated S2 s3_25 = 25;    //设置为 0x16,"love"  and 0x16,"hate"  repeated fixed32 s3_26 = 26;  //设置为1，2，3  optional int32 s3_27 = 27; //不设置 } 

编码的的数据表格如下，后面的剖析都会依赖这个表格进行。

编码剖析

整体编码

message中的fields按照tag顺序进行编码，而 每个fields的采用key+value的方式保存编码数据 。如果一个optional，或者repeated的fields没有被设置，那么他在编码的数据中完全不存在。相应的字段在解码的时候回设置为默认值。如果一个required的标识的fields没有被设置，那么在IsInitialized()检查会失败。编码的顺序和元数据.proto文件内fields的定义数据无关，而是根据tag的从小到大的顺序进行的编码。

key-value的设计保证了protobuf的版本兼容。高<->低，和低<->高都可以适配。（如果高版本编码增加了required 字段，低版本数据解码后会认为IsInitialized() 失败，所以慎用required ）

protobuf的整体数据都是变长的，而且有一定的自描述能力，所以其设计的核心点就是能识别出每一个key，value，(length)。

编码时对类型的再归类

先要说明，protobuf编码对自己的类型进行了再归类，其归类类型就是WireType

编码的key

KEY = VARINT（fields_tag<<3|WireType）

fields_tag就是元数据描述.proto文件里面的tag。

WireType他们就是这个field类型对应的WireType的枚举值。见前面定义表中定义。

生产的数据再用VARINT（后面介绍）进行编码。

当类型VARINT整数数组 （比如repeated int32 ），如果不加packed=true修饰时，key=VARINT（fields_tag<<3|WriteType ：0），视WireType为VARINT ，如果加上packed=true修饰时，仍然KEY = VARINT（fields_tag<<3|WireType:2）,视类型为LENGTH_DELIMITED。

用字段s3_17的key举例：

VARINTS 类型

Base 128 bits VARINS

前面说过变长编码的最大挑战是要找到每个字段边界。所以就必须能用方法能在编码的数据里面找到这个数值。

用连续字节的msb（most significant bit）为1，表示后续的字节仍然是这个数字。当首msb为0，表示结束。这个方法在UTF编码里面也常用。

例子，红色的bit都是表示连续，蓝色bit表示结束。

源： 0x8888 1000 1000 1000 1000

编： 0x029188 0 000 0010 1 001 0001 1 000 1000

源：0xE8E8E8 1110 1000 1110 1000 1110 1000

编：0x07A3D1E8 0 000 0111 1 010 0011 1 101 0001 1 110 1000

KEY，LENGTH的编码也是用VARINTS

s3_2的字段例子

s3_3的走低am的；ozone

ZigZag 有符号编码

VARINS大部分时候都可以压缩数值，但如果数值很大时，反而会增加一些消耗，比如int64极限0xFFFFFFFFFFFFFFFF下需要10个字节，所以一看就有一个弱点， VARINS如果直接使用对于有符号数值不利。

所以google对此增加sint32，sint64类型，其会先采用ZigZag编码，然后再VARINS ，不说废话了，直接上google的表格示例：

算法（ L 我看了示例也没有想到能这样写）

(n << 1) ^ (n >> 31)

(n << 1) ^ (n >> 63)

4字节和8字节的固定长度编码

double，float, 这些都是IEEE规定好的格式。大家反而都老实了。

fixed32，sfixed32，fixed64，fixed64，适合存放大数字数字。编码后变成网络序。

下图是展示repeated fixed32的编码，可以看到其实就是key重复出现。

变长LENGTH_DELIMITED

string,bytes

string的编码还是key+value，只是value里面多了一个长度。

string的要求是UTF8的编码的。所以如果不是这个编码最好用bytes。

string的编码带入没有'/0'

下图是repeated string

repeated VARINTS packed

repeated 的VARINTS 有带packed=true 时也是变长，带packed=true的描述会压缩更多，但和普通repeated模式不太一样。

下面的例子是带有packed的字段s3_22的例子

下面是不带packe=true的例子。

内嵌类，

内嵌类，中间潜入类S2的例子，s3_24｛1，"love"｝,内嵌类里面的编码方式和外部一样，只是内嵌类的tag使用其自己的tag。

下面的例子是repeated S2 s3_25｛22，"love"｝，{22,"hate"｝

Protobuf的解码

编码和解码函数SerializeToArray，ParseFromArray，得到编码size要调用函数ByteSize。如果要逃避required的IsInitialized()检查检查，可以用SerializePartialToArray， ParsePartialFromArray一类函数。当然后果自负。

proto的解码就是找到key，根据key找到tag（代码里面叫fieldnumber），然后根据tag进行解码，因为编码是KV的，编码本事有一定的防错性。

比较有意思的是google在代码里面会有预测下一个tag解码处理。应该是为了加速处理（不进入for循环）。

对比先驱们ASN.1,CDR等

其实拿protobuf和XML这类编码比完全是不公平的较量，简直就是欺负小P孩。真正应该拿来对比到时当年这些真正的编码工具，比如电信中的ASN.1和CORBA中的CDR等。这些编码先驱对数据的读取操作往往是完全依靠生产的代码（大部分没有kv设计）。

我自己觉得最大改变来自当年的编解码工具在编码的时候，只着眼于双方（比如异构系统）的数据值表示不一致时，将异构的数据编译成数据流的问题，而protobuf在之上还解决了分布系统中重要的麻烦，版本兼容的问题。

其实性能方面，这些先驱和Protobuf应该都在伯仲之间。

protobuf的数据类型支持其实并不丰富。但这样也在多语言支持上轻松了很多。（想想给lua支持一个char，short）,在编码处理上也有很多化烦为简的设计。

protobuf的字段更新，版本兼容

KeyValue的编码+可选项默认值方法保证了protobuf在版本兼容上有先天优势。

关于字段更新，和版本兼容，google给出的建议：

【参考】https://developers.google.com/protocol-buffers/docs/proto ,

• 不要试图改变 tag 。
• 如果要新增一个 field ，请使用 optional 和 repeated ，不要使用 required 。（高版本出现一个 required ，你当低编码 ó 高解码怎么办。）
• 如果一个不需要的字段可以保留，避免其 tag 被勿用造成冲突，可以加入明显的前缀 OBSOLETE_ 标识。
• int32, uint32, int64, uint64, and bool 是兼容的，他们都是使用 VARINTS(v) 进行编码的。
• sint32,sint64 是兼容的他们都是使用 VARINTS(Zigzag(v)) 进行编码的。
• 如果 bytes 是 UTF-8 的编码，那么和 string 兼容
• fixed32,sfixed32 兼容， fixed64 和 sfixed64 兼容。
• optional 兼容 repeated. （原文不够准确，应该是如果没有加 pack=true 修饰），为什么可以兼容？前面白画那么多图了。

使用protobuf的建议

可以不使用requested，只是用optional+default 默认值， requested只是将你需要做的检查交给了protobuf。代价是版本兼容的麻烦。不如不用。

版本兼容宝典：字段只新增，不删除，字段描述不用requested，任何时候tag不要变动，类型变化要慎重只有兼容才可以（但还是慎重把！），optional到repeated的变换也可以（只要没用pack=true）。

tag是要占空间的，如果tag>16时，KEY的编码就会占用2个字节了。所以tag的定义尽量不要跳动。

如果要出现负数，不要使用int32，int64，而应该使用sint32，sint64。

string真要UTF8的，有检查的。

repeated的VARINTS类型，可以增加packed=true减小占用空间，但有低版本不兼容的风险。

对于repeated字段的使用，protobuf是有提前（预分配）分配空间的，扩展基本就是乘以2，对同一个message，如果已经分配好空间了，Clear并不回收这一空间。所以尽量使用一个控制点编解码比较好。

.proto生成的message对应的结构很重，在游戏开发中不合适直接使用。需要你自己的数据和message的结构之间转换。（这个我很不爽）

Protobuf的伟大和挑战

多语言支持是protobuf的重大加分项。其实这点社区贡献良多。

KV的设计+可选和默认值，保证版本兼容。而且支持很天然，就我所知在其出来之前，没有一个编码工具把这个事情解决舒服了。

完善的文档体系和开源的方式让其获得了大量拥戴，以及大量社区的支持。

我不爽protobuf的地方：

• 不能和代码直接交互使用，我更希望其能生成我代码直接可以用的 struct ，另外部分是对这个 struct 的编码函数。
• request 描述既然看起来那么多余，直接废弃把。而可选可以直接通过默认值比较判定。
• repeated 是动态分配的。如果不重复使用，其实性能不高。我总觉得 Flatbuffers 的 benchmark 占了这个便宜好像更多。
• VARINTS 的编码有压缩，但我总觉得为了那几个字节牺牲性能，不值得。如果字段少，减少不了几个字节。如果字段多，也未见得多有效。我是做游戏开发的， Who Care 那几个字节？其实 google 更怪，他一搞文本处理的， Care 几个整数干嘛？
• 好多代码呀，好大的库呀。
• 反射的设计，反正你还是要写不少代码的。
• 序列化为啥不直接用 Json ，而要搞个类似 Json ？

google的还有一个新的为游戏开发准备的编码方式Flatbuffers，人家还在不断进步。

参考文档

《google的protobuf文档》https://developers.google.com/protocol-buffers/docs/overview

《google的protobuf编码解释》https://developers.google.com/protocol-buffers/docs/encoding

《Flatbuffer的bechmark》http://google.github.io/flatbuffers/md__benchmarks.html

《protobuf详解》 http://www.cnblogs.com/cobbliu/archive/2013/03/02/2940074.html 非常详细的一篇文章，唯一感觉没有说清的地方是可变长度的字段。

ferguszhang(张峰祯)的protobuf介绍图片。

【本文作者是雁渡寒潭，本着自由的精神，你可以在无盈利的情况完整转载此文档，转载时请附上BLOG链接:http://www.cnblogs.com/fullsail/，否则每字一元，每图一百不讲价。对Baidu文库和360doc加价一倍】