摘要

  • RFC 9996 为二进制 Protobuf 和 ProtoJSON 注册了正式媒体类型，但注册对象是序列化后的对象，不是 .proto 文件，也不是具体消息类型。
  • 媒体类型中的 version 参数描述 wire encoding 版本，不能代替 Proto2、Proto3、Edition、schema 修订或业务契约版本。
  • 企业必须在媒体标签之外保存可验证的 schema 绑定，并把“解码成功”与“语义正确、策略允许、运行状态已接受”分开审计。

消息总线上的一个设备指令被标为 application/protobuf。入口网关认可这个标签，解码库也顺利返回对象。值班人员看到的所有基础指标都是绿色：HTTP 没有报错，反序列化没有异常，字段类型似乎也合理。

问题出在更早的一次部署。生产端写入的是 DevicePolicyUpdate，消费端却装载了另一个团队维护的 DeviceStateUpdate descriptor。两套定义恰好复用了若干相同字段号，wire type 也能对上。于是本应表示“策略有效期”的整数，被解释成“设备状态码”；一个新增的限制字段被旧 schema 当成 unknown field 跳过。系统不是没能理解，而是成功地理解错了。

这正是 RFC 9996 最值得管理层读懂的边界。该 RFC 于 2026 年 7 月以 Informational 文档发布，为 Protocol Buffers 登记了两种媒体类型。它补齐了外层协调，却没有把 schema 权威塞进这个标签。

两个正式名称，只负责序列化层

application/protobuf 指向二进制 wire representation；application/protobuf+json 指向 JSON 映射。IANA 的二进制登记项与 JSON 登记项给生产者、代理、存储系统和客户端一个共同称呼，不必再依赖 application/x-protobuf、application/x-protobuffer 或 application/x-protobuf+json 等旧别名。

登记范围有意保持克制。RFC 9996 针对的是 serialized object，不是接口定义文件，也不是一个发布 .proto 的公共仓库。二进制类型默认使用 binary encoding；+json 形式使用 JSON，并要求 UTF-8。可选的 version 参数表示 Protobuf 的 wire encoding 版本，缺省值为 1。客户端遇到自身不支持的 wire 版本，必须拒绝。

这些事实很重要。RFC 6838所建立的媒体类型注册机制，本来就是为公开、稳定、可组合的格式识别服务。一个 API 网关据此区分 Protobuf 与普通字节流，一个对象库据此记录资产类型，一个客户端据此选择候选解码器，都是合理用途。

但注册项没有 magic number、标准文件扩展名或 fragment identifier，也不会凭空提供机密性、完整性、发送者认证、压缩和资源耗尽防护。标签说的是“应该采用哪一族表示规则”，而不是“谁创建了这条消息”或“这条消息属于哪一个业务动作”。

最容易混淆的是 version

在资产清单里，团队常写下一个看似完整的字段：protobuf version 1。这句话可能只说明 wire encoding，却被读成“双方 schema 相同”。

RFC 9996 明确区分 wire 层的版本与 schema language 的演进。Proto2、Proto3、Edition 2023、Edition 2024 可以继续变化，而 wire format 仍保持 version 1。应用自己的 schema 修订、生成代码版本、运行库行为与部署版本，又是另外几条时间线。

文档用 unknown enum 展示这种分离：相同的 wire 值可以保持合法，但不同 schema 或 runtime 对未识别枚举值的保留、暴露和处理方式可能不同。于是“编码兼容”并不自动推出“应用结果一致”。如果审计表只留下一个 version，事故发生后就无法知道变化来自 wire、IDL、descriptor、库还是业务规则。

最低限度的生产证据应包含四个独立坐标：wire encoding 版本、完整 message type、精确 descriptor 摘要、运行库与应用发布版本。任何一个坐标变化，都可能需要自己的兼容性判断。

二进制字段号不会自报姓名

Protocol Buffers 编码指南说明了为何外部 schema 不可省略。二进制消息携带字段号和 wire type，却不携带源码中的字段名；wire type 也不足以恢复 declared type。一个整数可能是普通整数、布尔值或枚举，一个 length-delimited 值可能是字符串、字节串、嵌套消息，也可能是 packed repeated 数据。只有被选中的消息定义才能补齐这些含义。

因此，解析器能读出对象只是一个中间观测。Protobuf 可以跳过未知字段，这种容忍能力让新增字段在许多二进制演进场景中保持向前兼容。然而，当接收方选错 schema 时，同一能力也会降低报警声量。错误的字段被忽略，碰巧对得上的字段被赋予另一种名字，默认值填补空缺，最终形成一个“看起来足够完整”的对象。

schema 的选择权属于应用契约。它可以由 endpoint、RPC method、生成客户端、内容 profile、版本化部署清单、签名 descriptor 包或受控 registry 来表达。没有一种方案适用于所有系统；真正必要的是把选择记录得足够明确，并让非授权中间人无法用另一份可解析的 schema 替换它。

这也解释了为什么没必要把全部语义压进 Content-Type。RFC 9205强调，基于 HTTP 的应用由 method、status、header、link relation、资源行为与媒体类型共同构成。媒体类型是契约的一部分，不是整份契约。RFC 9996 的克制不是缺陷，而是要求应用承认自己仍负有 schema 治理责任。

JSON 把名称放到线上，也没有消灭授权问题

application/protobuf+json 让字段名与枚举名更容易观察。RFC 6839定义的 +json structured syntax suffix，使不需要精确应用语义的工具可以按 RFC 8259进行通用 JSON 处理。这提高了可见性，却改变了演进风险。

ProtoJSON 指南指出，ProtoJSON 不像二进制 Protobuf 那样稳健地处理 unknown fields。新生产者增加一个字段，旧客户端可能直接拒绝。名称已经出现在 wire 上，因此改名会成为破坏性变更；从二进制转换成 JSON 再转换回来，还可能永久丢失 unknown fields。

Proto3 更新指南因而要求认真保留被删除的字段号，也应保留被删除的字段名。数字不能被新含义占用，名称也不能在 JSON 路径中被轻率复用。媒体类型能说明“这里是 ProtoJSON”，却无法检查团队是否遵守了字段生命周期纪律。

所以，二进制与 JSON 不是“安全”和“不安全”的二选一。二进制更容易在数值兼容的外表下隐藏 schema 偏差；JSON 更可能把新增字段变成显式拒绝，或在转换时损失未来信息。测试必须覆盖生产实际经过的 representation path，而不能只验证其中一种理想路径。

Any 的 URL 仍需回答“听谁的”

Protobuf 的 Any 把序列化字节与 type URL 放在一起，看上去已经提供了消息身份。RFC 9996 记录了现实限制：原始设计设想 URL 可以用于 schema dereference，但广泛使用的实现并不支持这一能力。许多系统只是把 URL 当作本地 registry 中的 key。

即使 resolver 确实可以联网取得 descriptor，URL 也只是定位或命名证据。DNS、TLS 和成功响应能够证明一些传输属性，却不能单独证明返回的 descriptor 是生产者、接口所有者和此次交易共同授权的版本。URL 内容可以变化，域名或仓库可以转手，自动查询还会泄露客户端正在处理哪些消息类型。

可靠的证据应是一组绑定：type name 或 URL、descriptor 的精确 digest、发布主体或信任根、取得渠道、审批状态，以及该绑定适用的接口范围。发现服务可以提出候选项，不能在没有额外验证时把候选项升级成权威。

“确定性输出”也不是跨系统的对象身份证

组织常希望对 Protobuf 字节做 hash 或签名。这里必须遵守 Google 关于序列化不是 canonical的提醒。字段顺序没有普遍保证；语义相同的消息可以产生不同字节。

deterministic serialization 只在受控上下文中提高重复性，它不等于跨语言、跨 build、跨库版本和跨 schema 的 canonical form。一个 digest 可以准确指认“这一次产生的这串字节”，却不能脱离 descriptor、runtime 与 normalization 规则，直接代表抽象业务对象。

对于缓存去重、长期签名和证据保全，这不是理论细节。只保留签名字节却丢失当时 schema 的机构，或许能证明某个 artifact 曾存在，却无法证明当时究竟批准了哪个语义对象。

将四层事实留在各自位置

按照 Heng Lu 的最小初始规范框架，共同层只应承载真正必须共同的内容。统一媒体标签和 wire 版本足以解决广泛协调；消息分类体系、descriptor 发布权与业务验证可保留在更贴近上下文的层级，直到出现需要进一步标准化的证据。

现实层次则提醒我们：媒体类型是表示层声明，descriptor 是解释规则，解析对象是运行时产物，状态变更才是业务现实。上一层准确，并不保证下一层准确。

最终，运行代码优先把证据落到服务的实际行为。registry 和 schema 规定应当发生什么；解析、校验、授权并提交状态的系统揭示实际发生了什么。生产可观测性需要保存这条链，而不是把它压缩成一个 content_type_valid。