摘要

  • RFC 1874 把不靠 SGML 软件仍能让人理解大意的实体归为 text/sgml，其余归为 application/sgml；这是回退规则，不是无害证明。
  • charset、SGML-bctf 与 SGML-boot 分别处理普通文本显示、SGML 位组合到传输字节的变换，以及指向另一 MIME 部件的启动映射。声明参数不等于接收端已正确执行。
  • RFC 明确提醒，SGML 处理系统可能允许系统级命令。后来 XML 另设媒体类型，说明共同语法祖先并不能证明处理器、参数或实体角色可以互换。

“文本”先回答失败时还剩什么

通常，人们看到 Content-Type 会问：这是什么格式？RFC 1874 先问了一个更朴素的问题：如果收件人没有 SGML 软件，这份东西还剩多少意义？

RFC 1874 规定，只有那些无需 SGML 显示软件、普通人也容易辨认内容的实体，才适合 text/sgml。为了维持这种最低可用性，每个由 SGML 记录起止字符界定的记录，都要对应 MIME 正文中的一行。其余实体使用 application/sgml。

于是，“文本”不是在评价结构简单，也不是保证每条指令无害。它只表示专业解释失败之后，还有一条人类可读的退路。标签、实体引用、排版关系可能仍然暴露在屏幕上；读者得到的是大意，不一定是发送者预期的完整呈现。

RFC 2046 后来把这层逻辑写得更一般：即使不知道子类型，顶级媒体类型也能指导客户端如何处理未知数据。未知文本可以考虑直接显示，未知图像或音频通常不能。文本子类型不应把理解大意完全押在专用程序上。

这是一份降级承诺。它没有替解析器签发权限。

同一个头部里有三套解释

text/sgml 的 charset 服务于普通 MIME 文本路径，让不懂 SGML 的软件知道如何显示字符。SGML 软件面对的是另一层：SGML-bctf 描述“位组合变换格式”，说明 SGML 模型中的定宽数值怎样变成传输中的八位字节。

RFC 列出了不变换的 identity、若干定宽形式和可变编码。接收端能识别子类型，不代表它实现了指定 BCTF；它能把字节变成字符，也不代表这些字符编号与 SGML 声明一致。参数是发送者对解释方法的陈述，不是接收者的执行日志。

SGML-boot 又把关键材料放到了别处。这个参数本身不携带启动映射，只携带另一段 application/octet-stream MIME 部件的 Content-ID。被引用部件中的整数三元组，用来重建 SGML 声明里重要字符的编号关系，而且只适用于文档实体。

引用存在，不等于对象在场。邮件网关可能丢掉部件，组合包可能出现重复标识，接收程序也可能保留正文却抛弃外围结构。即使找到目标，三元组仍须正确读取，声明仍须通过解析。

RFC 1590 建立的是媒体类型的公开登记程序。登记让名字与说明可查，并不逐份检查文件，也不认证某台机器上的解析器。注册表记录“应如何理解”，运行记录才说明“实际发生了什么”。

可显示与可执行属于不同权力层

RFC 1874 的安全段落没有因为顶级类型叫 text 就放松警惕。它指出，SGML 实体会被接收方系统解析和处理；某些系统可能允许显式的系统级命令，面向排版或呈现的处理指令也可能带来类似 PostScript 的风险。

因此，同一组字节有两条不同证据链。普通查看器显示若干行，证明一条低权限回退成功。SGML 处理器读取声明、解析实体并考虑执行指令，则跨过了新的控制面。前者不能授权后者。

一次成功解析也不能说明命令应该执行。策略可以允许构建语法树，同时阻止外部访问和主动指令。反过来，阻止解析不会抹掉纯文本路径上的信息价值。用一个“已打开”状态覆盖两者，会让故障和责任都无法定位。

MIME 还要求忽略未知参数，以便扩展不会让旧软件立刻崩溃。这对信封层是兼容性，对依赖 SGML-boot 的文档却可能意味着信息不足。接受 Content-Type 并不证明完整再现。

XML 用新名字拒绝继承错误的把握

XML 是 SGML 的子集，看上去最省事的办法是沿用 SGML 类型。可是 RFC 2376 选择了 text/xml 与 application/xml。原因不是品牌，而是运行能力：不少 XML 程序无法处理 SGML 的更大特性集；SGML 程序也未必支持 XML 使用的后续修订；XML 根本不用 SGML-bctf 和 SGML-boot，收到它们反而产生歧义。

“子集”是语言关系，不是软件兼容性测试。形式上的家族归属，不能替代已安装程序的输入边界。

RFC 3023 进一步引入 +xml 后缀。完整媒体类型继续表达具体应用语义，后缀只告诉通用工具：这里有一层 XML 语法可能利用。

RFC 6838 又为结构化语法后缀规定登记与评审内容，包括编码、互操作、片段和安全考虑。通过评审的是一份规范主张，不是每个客户端的支持证明。

RFC 7303 把动作顺序写得很谨慎：软件可以看到 +xml，调用 XML 处理器验证这个假设，然后再依具体类型继续。若通用 XML 处理本来就不合适，设计者可以不使用后缀。后缀提供的是检查入口，不是自动执行权。

该 RFC 还区分文档实体、外部 DTD 子集、外部已解析实体与外部参数实体。它们共享 XML，却不能任意替换。语法识别成功，仍要回答对象在结构中扮演什么角色。

最窄的收据才能经得住复核

“媒体类型已登记”“邮件已收到”“头部已解析”“文本已显示”“BCTF 已应用”“boot 部件已找到”“语法树已生成”“主动指令已拦截”“结果已交给用户”，是九种不同事实。

RFC 1874 的历史意义不需要虚构某个产品事故来证明。它自身就展示了一个分布式系统常见的误差：把便宜、早期的信号当成昂贵、后期的结果。可读性降低了失败成本，却没有取消解释者的权力与责任。

来源与边界

RFC 1590、1874 和 2046 说明登记、SGML 参数及 MIME 回退；RFC 2376、3023、6838 和 7303 说明 XML 分离与结构化后缀。它们不证明现时采用率、具体产品行为、真实命令执行、漏洞利用、用户损害或商业结果。