Summary

  • RFC 2376 登记了 text/xml 与 application/xml，但省略 charset 的后果完全不同：前者即使看见 BOM 或 UTF‑8/UTF‑16 声明也必须按 US‑ASCII，后者则让 XML 处理器检查实体本身。
  • 这场分歧把登记名称、收到的首部、正文八位组、解码优先级和应用语义拆成不同凭证；RFC 7303 后来统一了两类处理并取消旧默认值。

自描述文档仍带着外部标签

XML 的重要承诺之一，是结构化文档可以离开原来的机器与软件继续被理解。文档开头能够声明编码，字节序标记还能让处理器在读取正文前辨认若干关键序列化方式。

但它通过 HTTP、邮件或 WebDAV 旅行时，并不是一串孤立字节。外层 MIME 风格信封带有 Content-Type，其中还可能有 charset。于是接收端面对的不只是一份自述，而是多份都声称能回答“这些字节是什么字符”的证据。

1998 年 7 月发布的 RFC 2376 是 Informational 文档，不是 Internet Standard。它登记 text/xml 和 application/xml，也说明为什么不能继续借用 SGML 类型：XML 与 SGML 的处理能力和参数都不完全相容。为 XML 建立公共名称是必要协调，真正困难的是发生冲突时谁说了算。

为了便于阅读，权威层级却变了

任何 XML 实体都可使用 application/xml。不懂 XML 的程序可以把它当作不透明文件。text/xml 则表示默认按普通文本展示也算合理。

这项展示便利把 MIME 顶层 text 的历史规则一起带了进来。RFC 2376 规定，只要显式提供 charset，它对两种类型都有权威。内部 XML 声明未必是最终裁决者。

参数缺席时，两条路突然分开。application/xml 的缺席表示 MIME 首部没有提供编码信息；懂 XML 的处理器可以看 BOM、起始字节形态与内部声明，不懂 XML 的 MIME 程序则不应猜测。

text/xml 的缺席却自动变成 US‑ASCII。即便走 HTTP，即便正文实际是 UTF‑8 或 UTF‑16，甚至已经明确写出编码声明，处理器仍必须服从 US‑ASCII。外部空白没有留下选择空间，而是启动了一条继承来的命令。

规范用一个必败样例划出边界

RFC 2376 故意展示一份带 UTF‑16 BOM、内部写着 encoding="utf-16" 的实体，外层却只有 text/xml。规范给出的结论仍是 US‑ASCII。处理器若相信文档自述，反而不再符合传输契约。

相同迹象若装在 application/xml 里，BOM 就能决定 UTF‑16；没有 BOM 时，XML 处理器还能读取起始模式与内部声明。媒体类型里一个词，就改变了哪项证据可以生效。

这不只是解析器的趣闻。中间网关可能转换正文并更新外部 charset，却未同步文档声明；归档程序也可能丢掉 MIME 首部，只保存曾经依赖外部信息才能解释的字节。文档脱离传输环境后，决定过它含义的权威可能一并消失。

自描述无法给自己排定宪法位阶

XML 1.0 承认这个限制：存在外部编码信息时，优先级应由更高层的交付协议规定。这样的分工有现实理由，因为传输代理能做文档无法察觉的转换。

问题也因此从编码技术变成控制结构：哪一层能推翻哪一层？字段缺失表示未知，还是已经选中默认值？RFC 2376 部分沿用了 MIME 的历史答案。

2001 年的 RFC 3023 取代它，却继续保留 text/xml 的 US‑ASCII 默认。新文本更充分地解释了外部 charset 的价值，特别是中间件可能转码的场景。随后，运行实践与文本媒体类型的规范继续移动。

修复的重点是移除无声决定

RFC 6657 后来要求新的文本媒体类型明确写出 charset 行为，而不是继承一个通用假设。2014 年 RFC 7303 又把 text/xml 与 application/xml 对齐，不再让顶层类型的选择单独改变编码解释。

新规则最多处理三项证据：先看 BOM；没有 BOM 时看显式 MIME charset；两者都没有才交给 XML 自身规则。规范仍建议 application/xml，原因之一正是避免旧分歧留下的混乱。

+xml 后缀则解决另一个层次的问题。应用专用类型既可让通用工具知道它采用 XML 语法，又可保留更精确的用途名称。能构造 XML 树，不等于理解词汇表，更不等于可以安全执行其中表达的动作。

登记表不是运行结果

今天 IANA 的媒体类型登记把 application/xml 等项目指向 RFC 7303。这证明名称与引用已经协调，却不证明某次响应真的带了预期首部、代理保留了字节、解析器选择了同一编码，或业务程序理解了内容。

Lu Heng 的现实层次视角要求把登记类型、抓到的首部、原始八位组、BOM、内部声明、解码结果、解析树与业务动作分开。运行代码优先意味着要观察真实对象和真实处理器。最小初始规范也让我们能准确评价 RFC 2376：它建立了有用的公共入口，后续修订移除的是隐藏在默认值里的权力，而不是命名协调本身。