原文https://7byte.github.io/2017/07/09/protobuf-encoding/
英文原文：https://developers.google.com/protocol-buffers/docs/encoding
本文描述了protocol buffer 消息的二进制格式。当你在你的应用中使用protocol buffer 时无需了解这些细节。但是，要想理解不同的protocol buffer 格式对最终编码生成的消息大小有何影响，了解这些将非常有帮助。
一个简单消息
假设你有如下简单的消息定义：
message Test1 {
required int32 a = 1;
}
在应用中，创建一个名为Test1的消息并且对a赋值150。然后将这个消息序列化到一个输出流。如果查看编码出的消息内容，你将看到如下的三个字节：
08 96 01
只有几个数值——这些东西代表什么？且看下文……
Base 128 Varints
在理解上面的简单消息是如何编码之前，你需要先了解什么是Varints。Varints是使用一个或多个字节对整型数字序列化的方法。数值越小，序列化后所占的字节数越少。
除了最后一个字节，Varints中的每个字节设置了最高有效位（msb）用来标示后续的字节也是该数字的一部分。一个以补码表示的数字按7位一组的方式分成若干组，每组存储在字节的低7位，低位数字在前面（即小端序）。
例如，数字1只有一个字节，所以不需要设置msb：
0000 0001
数字300要稍微复杂一些：
1010 1100 0000 0010
你怎么知道这是300？首先，去掉每个字节中的msb，因为msb的作用只是告诉我们是否到达了数字的末尾（正如你所看到的，第一个字节设置了msb，表示后续字节也是varint的一部分）：
1010 1100 0000 0010
→ 010 1100 000 0010
反转两组7位数值，因为varints将数字的低位放在前面。然后把两组数值拼接起来：
000 0010 010 1100
→ 000 0010 ++ 010 1100
→ 100101100
→ 256 + 32 + 8 + 4 = 300
消息结构
正如你所知道的，protocol buffer消息是一系列键值对。一个二进制消息使用字段的编号作为键——字段的名字和声明类型只有在解码结束后参考消息类型定义（比如.proto文件）才能确定。
编码消息时，所有的键和值被拼接在一起写入字节流。解码消息时，分析器需要能够跳过无法识别的字段。这样的话，就可以在消息中加入新的字段时无须破坏旧程序，即使旧程序不知道这些新字段。为了这个目的，每个键值对的“key”实际上是由两个值组成——.proto文件中字段的编号和一个wire type，wire type提供了“value”的长度信息。
可用的wire type如下：
| 类型 | 含义 | 用途 |
|---|---|---|
| 0 | Varint | int32, int64, uint32, uint64, sint32, sint64, bool, enum |
| 1 | 64-bit | fixed64, sfixed64, double |
| 2 | Length-delimited | string, bytes, embedded messages, packed repeated fields |
| 3 | Start group | groups (deprecated) |
| 4 | End group | groups (deprecated) |
| 5 | 32-bit | fixed32, sfixed32, float |
消息流里的每个键是一个varint值：(field_number << 3) | wire_type，也就是说数字的低3位用来记录wire type。
再次回到我们的简单示例，你现在知道了字节流的第一个数字永远是一个varint类型的键值，即示例中的08，也就是（去掉msb后）：
000 1000
取最后3位可得wire type（0），然后右移3位可得字段编号（1）。现在你知道了tag是1，并且字段的值是varint类型。用上一节中学到的varint解码相关知识，你将会看到后面两个字节存储了150这个数字。
96 01 = 1001 0110 0000 0001
→ 000 0001 ++ 001 0110 (drop the msb and reverse the groups of 7 bits)
→ 10010110
→ 2 + 4 + 16 + 128 = 150
其它值类型
有符号整型
正如你在上一节里看到的，protocol buffer中所有wire type为0的类型都被编码成varint。然而，有符号int类型（sint32和sint64）和“标准”int类型（int32和int64）这两者在处理负数编码时有很重要的区别。如果你使用int32或者int64作为一个负数的类型，varint编码后的结果永远有10字节之长，实际上就像是在处理一个非常大的无符号整型。如果你使用有符号int类型（sint32或sint64），varint将使用更高效的ZigZag（之字形）编码。
ZigZag编码将有符号整数映射到无符号整数，这样，具有较小绝对值的数字（例如-1）也具有较小的varint编码值。它以“之字形”来回处理正负整数，所以-1被编码成1，1被编码成2，-2被编码成3，以此类推，如下表所示：
| 有符号原始数字 | 编码为 |
|---|---|
| 0 | 0 |
| -1 | 1 |
| 1 | 2 |
| -2 | 3 |
| 2147483647 | 4294967294 |
| -2147483648 | 4294967295 |
换句话说，对每个sint32类型的n值以如下方式编码：
(n << 1) ^ (n >> 31)
对64位：
(n << 1) ^ (n >> 63)
注意，第二个位移操作——(n >> 31)——是一个算数位移。也就是说，位移的结果要么所有位全是0（如果n是正数），要么全是1（如果n是负数）。
当解析到sint32或是sint64时，对应的值被解码为原始的、有符号形式。
非varint数字
非varint数字类型比较简单——double和fixed64使用wire type 1来告诉解析器有一块64位大小的数据，同理，float和fixed32使用wire type 5来告诉解析器有一块32位大小的数据。两种类型中的数值均以小端字节序编码。
字符串
wire type 2（长度分隔）表示值为一个包含长度信息、携带指定个数字节的varint。
message Test2 {
required string b = 2;
}
对b赋值“testing”将会得到：
12 07 74 65 73 74 69 6e 67
红色的字节（74 65 73 74 69 6e 67）是“testing”的UTF8编码。这里的键是0x12→ tag = 2, type = 2。表示长度的varint值为7，你瞧，我们看到在它后面有七个字节——我们的字符串。
嵌套消息
这里有一个message定义，它以嵌套了我们的示例消息：
message Test3 {
required Test1 c = 3;
}
同样对Test1中的a赋值为150，编码后：
1a 03 08 96 01
可以看到，最后三个字节与第一个例子中的完全相同（08 96 01）。在它们前面是数字3——嵌套消息与字符串（wire type = 2）的处理方式完全相同。
可选和repeated元素
如果一个proto2消息定义了repeated元素（没有设置[packed]=true），那么编码后的消息会有0个或多个拥有相同tag编号的键值对。这些重复值不必连续，它们可能和其它的字段交错在一起。在解析时，元素相对于彼此的顺序保持不变，但是相对于其它字段的顺序信息会丢失。在proto3中，repeated字段使用packed 编码，你可以阅读下面的内容。
对proto3中的任何一个non-repeated字段，或是proto2中的optional字段，编码后的消息可能有，也可能没有这个tag编号字段的键值对。
通常来说，编码的消息永远不会有一个non-repeated字段的多个示例。然而，真碰到这种情况时我们期望解析器也能够正常处理。对数字类型和字符串，如果同一个字段出现多次，解析器将接受它所看到的最后哪个值。对于嵌套消息字段，解析器会合并同一个字段的的多个实例，就像使用Message::MergeFrom方法——所有的歧义字段都会用后一个实例中的字段替换，歧义嵌套消息被合并，并且repeated字段会拼接起来。这些规则的效果就是，解析两个消息的串联，与你分别解析这两条消息然后合并的结果完全相同。即：
MyMessage message;
message.ParseFromString(str1 + str2);
等于：
MyMessage message, message2;
message.ParseFromString(str1);
message2.ParseFromString(str2);
message.MergeFrom(message2);
这个特性有时候很有用，因为它允许你在完全不知道两个消息的类型时合并它们。
Packed repeated字段
2.1.0版本中引入了packed repeated字段，在proto2中它被声明成带有[packed=true]选项的repeated字段。在proto3中，repeated字段默认会按packed处理。这些功能与repeated字段很类似，但是有不一样的编码规则。编码生成的消息中不会出现包含零元素的packed repeated字段。否则，所有的元素都被打包成一个wire type为2（长度分隔）的键值对。每个元素都按正常的、相同的方式编码，除了前面没有tag。
例如，想象你有这样一个消息类型：
message Test4 {
repeated int32 d = 4 [packed=true];
}
现在，假设你构造了一个Test4，给repeated字段d设值3、270和86942。然后，编码的形式将是：
22 // tag (field number 4, wire type 2)
06 // payload size (6 bytes)
03 // first element (varint 3)
8E 02 // second element (varint 270)
9E A7 05 // third element (varint 86942)
只有原始数字类型的repeated字段（使用varint、32-bit、或者64-bit类型）才能声明为“packed”。
请注意，尽管通常没有理由将多个键值对编码成一个packed repeated字段，但编码器必须做好接受多个键值对的准备。在这种情况下，所有载荷（payloads）应该拼接到一起。每一对都必须包含完整的元素。
Protocol buffer解析器必须能够解析以packed方式编译而成的repeated字段，就好像它们没有被打包一样，反之亦然。这样就能允许以向前和向后兼容的方式向现有字段添加[packed=true]。
字段顺序
虽然可以在.proto中以任意顺序使用字段号，但当消息被序列化时，已知字段应该按字段号顺序写入，正如所提供的C++、Java和Python序列化代码。这使得解析代码可以使用依赖于字段号的优化。但是，protocol buffer解析器必须能够以任意顺序解析字段，因为并非所有消息都是通过简单地序列化一个对象来创建的——例如，通过简单地拼接两个消息来合并它们有时候是很有用的。
如果一个消息具有未知字段，当前的Java和C++实现会在顺序排列已知字段之后按任意顺序写入未知字段。当前的Python实现不处理未知字段。
版权说明
除另有说明外，本页面的内容是根据知识共享署名3.0许可证授权的，代码示例根据Apache 2.0许可证授权。有关详细信息，请参阅我们的网站政策。Java是甲骨文和/或其子公司的注册商标。