protocol-buffers - 如何使用字节在 protobuf 中存储信息

标签 protocol-buffers

我试图理解这里的 Protocol Buffer 是示例,我无法理解的是如何在后续消息中使用字节。我不知道这个号码是多少 1 2 3 用于。

message Point {
  required int32 x = 1;
  required int32 y = 2;
  optional string label = 3;
}

message Line {
  required Point start = 1;
  required Point end = 2;
  optional string label = 3;
}

message Polyline {
  repeated Point point = 1;
  optional string label = 2;
}

我在 google protobuf 中阅读了以下段落,但无法理解这里所说的内容,任何人都可以帮助我理解如何使用字节来存储信息。

每个元素上的“= 1”、“= 2”标记标识该字段在二进制编码中使用的唯一“标签”。标签编号 1-15 比更高的数字需要少一个字节来编码,因此作为一种优化,您可以决定将这些标签用于常用或重复的元素,而将标签 16 和更高的标签留给不常用的可选元素。

最佳答案

protobuf 消息的一般形式是它是以下形式的对序列:

  • 字段标题
  • 有效载荷

对于您的问题,我们基本上可以忘记有效载荷——这不是与 1/2/3 和 <=16 限制相关的位——所有这些都在字段标题中。字段头是一个“varint”编码的整数; “varint”使用最高有效位作为可选的连续位,因此小值(<=127,假设无符号且不是之字形)需要一个字节进行编码 - 较大的值需要多个字节。或者换句话说,在需要设置连续位之前,您可以使用 7 个有用的位,至少需要 2 个字节。

但是!字段头本身由两部分组成:

  • 线型
  • 字段编号/“标签”

wire-type 是前 3 位,表示 payload 的基本格式 - "length-delimited", "64-bit", "32-bit", "varint", "start-group", “末端组”。这意味着在我们拥有的 7 个有用位中,只剩下 4 个; 4 位足以对 <= 16 的数字进行编码。就是为什么建议对最常见的元素使用字段编号 <= 16(作为优化)的原因。

在你的问题中,1/2/3 是字段编号;在编码时将其左移 3 位并与有效载荷的线型组成;然后这个组合值是 varint 编码的。

关于protocol-buffers - 如何使用字节在 protobuf 中存储信息,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18677025/

相关文章:

c# - 是否可以使用 Protocol Buffers C# (ProtoBuf-net) 序列化复杂对象

encoding - 需要从 urllib2 中找到相当于 openurl() 的请求

c++ - 关于 Protocol Buffer 事件的设计问题

java - 处理 Buffer 内多条消息的异常 [JAVA-Mina]

python-3.x - 在Docker文件中设置mysql-connector-python

protocol-buffers - 通过 AWS SQS 传输 ProtoBuf-net 消息时无效的二进制字符

protocol-buffers - Protobuf-net .proto文件生成用于继承

python - 从文件描述符集中提取 Protobuf 自定义选项?

c# - 谷歌的 Protocol Buffer 从 C# 到 Java - 协议(protocol)消息标记的线路类型无效

java - 将 ProtocolBuffer 消息的重复字段提供给自定义列表适配器