Protocol buffers protobufs的全局唯一选项字段号

protobuf文档（）中对自定义选项作了如下说明：

最后一件事：因为自定义选项是扩展，所以它们必须是 指定的字段编号与任何其他字段或扩展名相同。在 在上面的示例中，我们使用的字段编号范围为50000-99999。 此范围保留供个人内部使用 组织，因此您可以免费使用此范围内的数字 内部应用程序。如果要在公共场合使用自定义选项 然而，重要的是要确保 您的字段编号是全局唯一的。获得全局唯一性 字段编号，请向发送请求 protobuf全局扩展-registry@google.com. 只需提供您的 项目名称（如Object-C插件）和您的项目网站（如有） 可用）。通常你只需要一个分机号码

---

为什么公共应用程序的选项字段编号必须是全局唯一的？碰撞以何种方式成为问题？

基本上，因为您不知道所获得的数据是否正确

protobuf二进制导线格式仅存储字段号和有效载荷（对于复杂类型，它本身就是字段号和子有效载荷）。没有名称数据。所以：当您存储和检索扩展字段时，您所说的只是“fetchfield{fieldnumber}，将其解释为{type}”。如果两个不同的系统使用相同的字段号扩展了相同的数据，那么您就无法知道所获取的数据是否实际是该格式的

通常这不是问题，因为在相同的数据上很少发生这样的冲突；但是定制选项是不同的！我是一名图书馆作家；我可能希望通过扩展（比如）

MessageOptions

，添加一个我的模式解析工具能够识别的自定义选项

MessageOptions

是

DescriptorProto

的扩展点，也就是说：这就是

option（foo）=“bar”进入
消息内部

为此，我需要为
foo
分配一个数字。我任意选择
5000
（
MessageOptions
定义
extensions 1000到最大值；
，这样就可以了）。一切都很好。我的工具工作正常

我不知道，另一位图书馆的作者选择了做类似的事情，也使用了5000。一旦模式被编译（通过
protoc
或类似方式），我就只有数字了。如果我要从字段5000中获取数据，我不知道是得到我的扩展名，还是另一个扩展名。意思消失了。好的，一推，我还可以检查
文件描述符协议
上的
依赖项
列表，但是。。。那是偶然的

我不知道字段
5000
中的值
1
是否为：

option (.mystuff.someext) = 1;

vs

vs

如果这些扩展都有编号5000，则它们在导线上的显示方式相同

option (.anotherlib.whatever) = -1; // stored as sint32

option (.yetanother.library.option) = true;