protobuf 自定义 option 扩展编号如何注册到官方全局 registry 避免与其他项目冲突【免费下载链接】protobufProtocol Buffers - Googles data interchange format项目地址: https://gitcode.com/GitHub_Trending/pr/protobuf你要为自己的 protoc 插件或代码生成器定义 custom option例如extend google.protobuf.FileOptions { ... }但扩展编号是全局的如果两个第三方项目各自定义了同编号的 option且同一个编译单元同时使用了这两份 proto编号就会撞车。protobuf 仓库在 docs/options.md 中维护了一份全局扩展 registry其目标正如文档开头所述——让同时使用多个带自定义扩展的第三方项目的开发者be confident that there wont be collisions in extension numbers确信扩展编号不会冲突。本文说明如何判断自己是否需要走官方注册、如何核对当前分配情况、按文档给出的路径提交注册以及拿到编号后如何在.proto中声明和使用该 option。适用前提你要定义的是扩展google.protobuf.*Options消息的 custom option。如果你只是把 option 限定在单一应用、组织内部使用或实验性质就不需要注册官方编号见下一节的编号选择规则。何时需要官方编号50000–99999 与全局 registry 两条路src/google/protobuf/descriptor.proto 中 Options 章节的注释Extension numbers for custom options may be chosen as follows给出了文档明确的编号选择规则仅在一个应用或组织内部使用或属于实验性 option使用 50000 到 99999 的字段编号。文档同时写明It is up to you to ensure that you do not use the same number for multiple options——这个区间的去重责任在你自己不需要也不走全局 registry。要公开发布、且会被多个独立实体使用的 option需要向官方保留reserve扩展编号。descriptor.proto 注释给出的路径是发邮件到protobuf-global-extension-registrygoogle.com只需提供项目名称如 Objective-C plugin和项目网站如有不需要解释你打算如何使用它。注释还说明通常一个扩展编号就够了如果一个插件要暴露多个 option可以把它们放进一个子消息sub-message从而用一个编号承载多个 option。仓库内的真实测试 proto csharp/protos/unittest_custom_options_proto3.proto 使用的就是私有区间编号例如uint64 file_opt1 7736974;、int32 message_opt1 7739036;都落在 50000–99999 范围内。如果你的 option 只给内部构建系统用选一个 50000–99999 的编号即可结束下面各节面向需要公开编号的场景。如何核对 registry 当前的分配情况全局 registry 就是 docs/options.md 这份 Markdown 文件正文的 Existing Registered Extensions 一节是已分配编号的完整清单。每个条目包含三部分项目名称项目网站分配到的扩展编号单个编号如1000或连续区间如1026 - 1030、1048-1056。清单中的既有分配示例摘自该文件C# port of protocol buffers 占用 1000Nanopb 占用 1010grpc-gateway 占用 1022Buf 先后占用 1157-1166 与 1200-1239 两个区间。按当前文件内容清单末尾的分配是 Flyte 的 1364-1373 区间即截至该文件最后一次更新时已分配的最大编号段。判断某个编号是否可用就是直接查这份清单里有没有对应条目。提交注册前建议核对一遍最新文件内容因为 registry 是持续追加的文档。注册路径文档给出的三种方式仓库中有两处文档描述了注册途径各写如下你可以任选其一路径一提交 PR 直接添加条目来自 docs/options.md 开头If you need an extension number for your custom option ... please send us a pull request to add an entry to this doc即向 protobuf 仓库发起 PR在docs/options.md的 Existing Registered Extensions 一节按现有格式追加你的条目项目名称、网站、编号。路径二创建 Issue同样来自 docs/options.md 开头... or create an issue with info about your project (name and website) so we can add an entry for youIssue 中需要提供的项目信息是两项项目名称和项目网站。由维护者代为添加条目。路径三邮件申请来自 src/google/protobuf/descriptor.proto 的注释发邮件到protobuf-global-extension-registrygoogle.com提供项目名称和项目网站即可注释明确说theres no need to explain how you intend to use them。三条路径的提交材料一致项目名称 网站 你申请的编号或请维护者分配。如果申请的编号与清单已有条目重叠以清单现状为准调整申请。拿到编号后如何声明并使用 custom option声明方式是在导入google/protobuf/descriptor.proto的.proto文件中用extend扩展对应的*Options消息。仓库测试 proto 中的真实写法proto3 语法见 csharp/protos/unittest_custom_options_proto3.protosyntax proto3; import google/protobuf/descriptor.proto; // 仓库测试文件中的真实示例7736974 属于 50000-99999 私有编号区间 extend google.protobuf.FileOptions { uint64 file_opt1 7736974; } // 在文件级使用该自定义 option option (file_opt1) 9876543210;把私有编号替换为 registry 分配给你的编号即可声明结构不变。可选的目标消息按你的作用位置选择同一测试文件中覆盖到的有FileOptions、MessageOptions、FieldOptions、OneofOptions、EnumOptions、EnumValueOptions、ServiceOptions、MethodOptions。如果一个插件有多个 option按 descriptor.proto 注释的做法把多个字段放进一个子消息只用一个分配编号// 示例字段名与类型按你的插件实际需要替换 // registry-assigned-number 是注册时获得的编号首次使用前替换 message MyPluginOptions { bool enable_x 1; string y_config 2; } extend google.protobuf.FileOptions { MyPluginOptions my_plugin registry-assigned-number; }验证与边界成功条件注册结果落到 docs/options.md 的 Existing Registered Extensions 清单中——PR 流程的目标就是add an entry to this docIssue 流程则是维护者add an entry for you。条目出现在该清单说明编号已被官方记录其他项目后续分配时会避开你。可用性核对方式registry 文档自身承担核对职能——任何想避免冲突的开发者都以查这份清单为手段这也是文档开头声明的 registry 用途。边界一全局 registry 只解决跨项目的公开编号这一件事。50000–99999 区间的编号由使用方自行保证不重复文档没有为该区间提供任何中心化核对机制。边界二注册途径在两份文档中表述不同——docs/options.md写的是 PR 或 Issuedescriptor.proto注释写的是邮件。三者均出自仓库内文档本文按原文分别列出未做合并建议以提交时仓库内docs/options.md的最新指引为准。【免费下载链接】protobufProtocol Buffers - Googles data interchange format项目地址: https://gitcode.com/GitHub_Trending/pr/protobuf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考