十二.Protobuf3编码

本文档描述了协议缓冲消息的二进制格式。在应用程序中使用Protocol Buffer不需要理解这一点，但是了解不同的Protocol Buffer格式如何影响编码消息的大小会非常有用。

一条简单的信息

假设您有以下非常简单的消息定义:

message Test1 {
  optional int32 a = 1;
}

在应用程序中，您创建一个Test1消息，并将设置为150。然后将消息序列化为输出流。如果您能够检查编码的消息，您会看到三个字节:

08 96 01

到目前为止，数字如此之小——但这意味着什么呢？继续阅读...

Base 128 Varints

要理解您的简单Protocol Buffer编码，您首先需要理解varints。Varints是一种使用一个或多个字节序列化整数的方法。较小的数字占用较小的字节数。

变量中的每个字节，除了最后一个字节，都设置了最高有效位( msb )，这表明还会有更多的字节。每个字节的低7位用于存储7位组中数字的二进制补码表示，最低有效组优先。

例如，这里是数字1——它是一个字节，所以msb没有设置:

0000 0001

这里是300，这有点复杂:

1010 1100 0000 0010

你怎么知道这是300？首先从每个字节中删除msb，因为这只是为了告诉我们是否已经到达数字的末尾(如您所见，它设置在第一个字节中，因为varint中有一个以上的字节) :

 1010 1100 0000 0010
→ 010 1100  000 0010

颠倒两组7位，因为正如您所记得的，变量首先存储具有最低有效组的数字。然后将它们连接起来，得到最终值:

000 0010  010 1100
→  000 0010 ++ 010 1100
→  100101100
→  256 + 32 + 8 + 4 = 300

消息结构

如您所知，协议缓冲消息是一系列键值对。消息的二进制版本仅使用字段的编号作为密钥—每个字段的名称和声明类型只能在解码端通过引用消息类型的定义(即.proto文件)来确定。

当消息被编码时，密钥和值被连接成字节流。当消息被解码时，解析器需要能够跳过它不能识别的字段。这样，新字段可以添加到邮件中，而不会破坏不知道它们的旧程序。为此，线格式消息中每一对的“键”实际上是两个值—来自.proto文件的字段号，加上一个线类型，该线类型提供刚好足够的信息来找到以下值的长度。在大多数语言实现中，这个键被称为标签。

可用的消息类型如下:

类型	意义	用于
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 (已废弃)
4	End group	groups (已废弃)
5	32-bit	fixed32, sfixed32, float

流式消息中的每个密钥都与值(字段编号< < 3) | wire_type )不同，换句话说，数字的最后三位存储了wire类型。

现在让我们再看一遍我们的简单例子。您现在知道了，数据流中的第一个数字总是一个不同的varint 键，这里是08，或者(去掉msb ) :

000 1000

您取最后三位得到wire类型(0)，然后右移三位得到字段号(1)。现在你知道字段号是1，下面的值是一个varint。使用上一节中不同的解码知识，您可以看到接下来的两个字节存储了值150。

96 01 = 1001 0110  0000 0001
       → 000 0001  ++  001 0110 (丢弃msb并反转7位组)
       → 10010110
       → 128 + 16 + 4 + 2 = 150

更多值类型

有符号整数

正如您在上一节中看到的，所有与类型0相关联的Protocol Buffer类型都被编码为varints。然而，在编码负数时，有符号int类型( sint32和sint64 )和“标准”int类型( int32和int64 )之间有一个重要的区别。如果使用int32或int64作为负数的类型，得到的varints总是10字节长:实际上，它被视为一个非常大的无符号整数。如果您使用其中一种有符号类型，结果varints将使用ZigZag编码，这种编码效率更高。

ZigZag编码将有符号整数映射到无符号整数，因此绝对值小的数字(例如，-1)也有一个小的可变编码值。它这样做的方式是通过正整数和负整数来回“zig-zags”，因此-1编码为1，1编码为2，-2编码为3，依此类推，如下表所示:

原始值	编码为
0	0
-1	1
1	2
-2	3
2147483647	4294967294
-2147483648	4294967295

换句话说，每个值n使用:

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

对于 sint32,

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

对于64位版本。

请注意，第二个移位(n >> 31)部分是算术移位。换句话说，移位的结果要么是一个全为零位的数字(如果n为正)，要么是全一位的数字(如果n为负)。

当sint32或sint64被解析时，其值被解码回原始的签名版本。

非varint数字

非varint数字类型很简单:double和固定64位具有类型1，这告诉解析器期望固定的64位数据块；类似地，float和固定32位具有类型5，这告诉它期望32位。在这两种情况下，这些值都以小字节顺序存储。

字符串

类型为2 (长度分隔)意味着该值是一个可变的编码长度，后跟指定的数据字节数。

message Test2 {
  optional string b = 2;
}

将b的值设置为“testing”:

12 07 74 65 73 74 69 6e 67

红色部分是“testing”的UTF8。这里的键是0x12 →字段号= 2，类型= 2。值的长度变化是7，我们发现后面有7个字节：我们的字符串。

嵌入消息

下面是一个消息定义，其中嵌入了我们示例类型的消息，Test1 :

message Test3 {
  optional Test1 c = 3;
}

这是编码版本，Test1的字段设置为150 :

 1a 03 08 96 01

如您所见，最后三个字节与我们的第一个示例( 08 96 01 )完全相同，前面是数字3：嵌入消息与字符串的处理方式完全相同(wire type = 2)。

可选和重复元素

如果proto2消息定义有重复的元素(除了[packed=true]选项)，则编码的消息具有零个或多个具有相同字段编号的键值对。这些重复值不必连续出现；它们可以与其他字段交错。在解析时，元素相对于彼此的顺序会保留下来，尽管相对于其他字段的顺序会丢失。在proto3中，重复字段使用打包编码，您可以在下面阅读。

对于proto3中的任何非重复字段或proto2中的可选字段，编码消息可能具有也可能不具有与该字段编号的键值对。

通常，一个编码的消息绝不会有一个以上的不重复字段实例。然而，解析器会处理这种情况。对于数字类型和字符串，如果同一个字段出现多次，解析器将接受它看到的最后一个值。对于嵌入的消息字段，解析器合并同一个字段的多个实例，就像使用Message::MergeFrom方法一样：也就是说，后一个实例中的所有单个标量字段替换前一个实例中的字段，单个嵌入的消息被合并，重复的字段被连接。这些规则的效果是，解析两个编码消息的连接会产生完全相同的结果，就像您分别解析了这两个消息并合并了结果对象一样:

MyMessage message;
message.ParseFromString(str1 + str2);

相当于：

MyMessage message, message2;
message.ParseFromString(str1);
message2.ParseFromString(str2);
message.MergeFrom(message2);

这个属性有时很有用，因为它允许您合并两个消息，即使您不知道它们的类型。

打包重复字段

2.1.0版引入了打包的重复字段，在proto2中，这些字段被声明为类似于重复字段，但带有特殊的[packed=true]选项。在proto3中，默认情况下，标量数值类型的重复字段被打包。这些功能像重复的字段，但编码不同。编码消息中不会出现包含零个元素的打包重复字段。否则，字段的所有元素都被打包成一个具有类型2 (长度分隔)的键值对。每个元素都以正常方式编码，除了前面没有键。

例如，假设您有消息类型:

message Test4 {
  repeated int32 d = 4 [packed=true];
}

现在假设您构建了一个Test4，为重复的字段d提供值3、270和86942。然后，编码的形式将是：

22        // key (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)

只有原始数字类型(使用变量、32位或64位类型的类型)的重复字段才能声明为"packed"。

请注意，虽然通常没有理由为一个打包的重复字段编码多个键值对，但编码器必须准备好接受多个键值对。在这种情况下，有效载荷应该连接在一起。每对必须包含整数个元素。

Protocol Buffer解析器必须能够解析像未打包一样打包的重复字段，反之亦然。这允许以向前和向后兼容的方式将[打包=真]添加到现有字段中。

字段排序

字段编号可以在.proto 文件中以任何顺序使用。选择的顺序对消息的序列化方式没有影响。

当消息被序列化时，对于如何写入其已知或未知字段没有保证顺序。序列化顺序是一个实现细节，任何特定实现的细节都可能在将来发生变化。因此，Protocol Buffer解析器必须能够以任何顺序解析字段。

含义

不要假设序列化消息的字节输出是稳定的。尤其是对于具有表示其他序列化Protocol Buffer消息的可传递字节字段的消息。

默认情况下，对同一Protocol Buffer消息实例重复调用序列化方法可能不会返回相同的字节输出；即默认串行化不是确定性的。

--确定性序列化只保证特定二进制文件的相同字节输出。字节输出可能在二进制文件的不同版本之间发生变化。

对于Protocol Buffer消息实例foo，以下检查可能会失败。

 foo.SerializeAsString() == foo.SerializeAsString()
  Hash(foo.SerializeAsString()) == Hash(foo.SerializeAsString())
  CRC(foo.SerializeAsString()) == CRC(foo.SerializeAsString())
  FingerPrint(foo.SerializeAsString()) == FingerPrint(foo.SerializeAsString())

这里有几个示例场景，其中逻辑等价的协议缓冲消息foo和bar可以序列化为不同的字节输出。

-bar由旧服务器序列化，旧服务器将某些字段视为未知字段。

-bar由用不同编程语言实现的服务器序列化，并以不同的顺序序列化字段。

-bar有一个以非确定性方式序列化的字段。

-bar有一个存储Protocol Buffer消息序列化字节输出的字段，该消息以不同方式序列化。

-bar由新的服务器序列化，由于实现的变化，该服务器以不同的顺序序列化字段。

-foo和bar都是单个消息的串联，但顺序不同。