摘要

  • RFC 9512 为 application/yaml 与 +yaml 注册了明确而有限的用途：标识 YAML 序列化，并服务于内容协商。
  • 格式标识并不能证明版本已获准、完整流已核验、语义合格、签名仍有效，或某项实际操作已经获授权。

一份文件在入口处被贴上 YAML 标签，常会产生一种不应有的安定感。接收端知道该调用哪类解析器，自动化看似已经启动，于是“识别格式”悄然被讲成“可信输入”。这中间隔着的，不是文书上的小差别，而是一连串本应有人承担的决策：接受哪一种版本和特性；是否读完了整个流；标签和图结构是否处在可接受的边界内；数据是否符合业务含义；以及谁有权让它改变真实系统。

RFC 9512 的价值正在于没有跨过这些边界。它注册 application/yaml 媒体类型和 +yaml 结构化语法后缀，使独立系统能够在交换和内容协商时识别 YAML 表示。这是公共接口需要的最小共同事实。它并没有把一个格式名称扩张为跨组织、跨应用的安全判决，更没有把接收方的政策判断委托给发送方。

版本问题首先说明了这一点。该注册与具体 YAML 版本无关；文档可以通过 YAML 指令说明版本，但内容类型本身不替接收方选择版本。接收服务必须自行列明可接受的版本和行为。+yaml 也一样：某个专用子类型可以说明它以 YAML 为基础，但 RFC 9512 要求该子类型自行定义片段标识符语义，application/yaml 的规则不会自动覆盖它。家族标签提供方向，不提供完整路线图。

文档流的边界更容易被忽略。YAML 流可以包含零个或多个文档。RFC 9512 指出，如果应用只期待一个文档，收到多个时应报错，而不是默默忽略余下内容。这里关键不是对多文档流作价值判断，而是让应用对自己究竟验证了什么保持诚实。若程序只根据首个文档采取行动，却把同一输入的其余部分视而不见，它已经作出了一个未被记录的本地范围决定。

RFC 的安全考虑同样没有提供万能结论。它说明在某些实现中，YAML 标签可能导致任意代码执行，并建议默认禁用这种行为；表示图可能存在循环，或在构造时指数扩展，因此应作适当验证并限制递归或资源；增量解析可能先给出部分结果，之后才发现错误，所以应用应在开始处理结果前一并测试流中的所有文档。它们不是“所有 YAML 都不安全”的证据，而是提醒接收方：安全姿态由本地实现、限制和核验范围决定。

证据链还会在转换处断裂。RFC 9512 提醒，从 YAML 转为 JSON 可能丢失注释、指令和别名节点；多文档、非 UTF-8 编码、非字符串键、循环、.inf、.nan 与标签等特征也可能造成互操作困难。重新编码甚至可能改变空白或锚点，从而影响签名验证。因而，“转换后看起来相同”不能自动等于“它仍是被签名的同一证据对象”。接收的字节、解释后的结构、验证结果和被授权的动作应当保留为不同记录。

更可靠的流程不是把 YAML 变成一张通行证，而是把它放在正确的一格：先识别表示；再选择允许的解析配置并验证完整输入；继而核验模式和本地语义；由独立的权限与政策环节决定是否采取效果；最后用可观察的状态说明实际发生了什么。自动化可以覆盖这些步骤，但任何一步都不应借用上一层的名称来冒充完成。

这也契合 Heng Lu 对“最小初始规范、后续本地决策”的强调。共同规范只承担它真正能够承担的事实，后果性的选择则应留给承担风险的一方。运行中的代码值得尊重，但解析成功只说明某段软件完成了一项处理；它不是授权，也不是对现实效果的证明。

来源