摘要

  • RFC 2987 让 charset 与 language 使用相同的等值比较框架，却明确指出前者通常是设备能力，后者通常是用户偏好。
  • 字符集采用主要登记名、语言标签按完整 token 比较，可以减少命名歧义，却不能证明解码、字形、语音质量或人的理解。
  • q 权重只是在本地策略中排列候选谓词，不是所选内容存在、成功呈现或满足用户的回执。

两张相邻的登记表

RFC 2987 很短。它没有发明一套庞大的新协议，主体只是依照 RFC 2506 的程序填写两份媒体特征登记表。charset 获得 IETF 树中的对象标识符 1.3.6.1.8.1.31，language 获得 1.3.6.1.8.1.32。今天的 IANA 媒体特征登记表仍把它们列为第 31 和第 32 项。

这种登记解决了真实的协调问题。不同应用可以沿用同一词汇描述呈现能力或偏好，不必各造一套私有字段。RFC 2533 又提供了组合谓词与附加质量值的语法。于是名称、值域和比较方法可以跨协议复用。

两项登记的表面结构几乎完全平行。值都是 token；只允许等值比较；比较不区分大小写；示例都以 OR 连接多个候选，并给出 q 值。

真正重要的是平行结构中的不平行语义。

RFC 2987 说，对大多数设备而言，charset 通常是一项 capability。设备不知道某种字符集时，一般无法有意义地处理其中的文本。language 则通常是一项 preference，而不是 requirement。文档设想的“显示语言”很多时候指计算机语音，但边界不限于语音：人可以更喜欢一种语言，却不等于机器在技术上无法呈现其他语言。

同一种表达式因此承载了两类约束。

字符集先问机器能不能做

字符集示例把 utf-8、iso-8859-1 和 utf-16 分别排为 1.0、0.9 和 0.5。数字看上去像三种喜好；能力不存在时，它们却没有可比较的输出。

charset=utf-8 匹配成功，只能说明某个声明与某个 token 相等。载荷标签仍可能与真实字节冲突；解码器可能没有安装；映射实现可能有错；解码得到的字符可能缺少字体；字形可能正确显示但读者并不理解。每一步都是新的事实。

RFC 2913 把媒体 type 单独登记为一项特征。一个系统可以接受 text/plain，却不能接受这种文本的每一种编码。内容类型与字符解码相邻，但不是同一张回执。

名称本身也需要纪律。RFC 2978 允许一个字符集拥有多个名称，同时要求指定一个主要名称，并保证每个名称只指向一个字符集。RFC 2987 不建议在特征表达式里使用别名，因为处理工具可能把别名改写成主要名称，进而改变原表达式的排列或匹配结果。

统一用小写主要名称，可以减少本来无意义的拼写分歧。它没有验证解码表，更没有验证运行代码。规范化解决了名字问题，没有替机器完成工作。

RFC 2987 还要求：只要宣称能够处理文本数据，就应同时给出 charset 能力。单说“这是文本”，却不说明字节如何变成字符，会把最关键的执行前提藏起来。

语言先问人想要什么

语言示例依次给出 no-nynorsk、no-bokmaal 与 i-sami-no。同样是等值比较，失败的意义却不同。

RFC 1766 允许语言标签包含主标签和子标签，但要求应用把完整标签当作一个 token。子标签是登记与管理结构，不是一棵自动推导互通性的树。拥有相同前缀，不代表两种语言变体可以互换，更不代表具体听众一定理解。

RFC 2987 延续了这条限制：完整 token、不区分大小写、比较时不拆子标签。字符串结构不能替语言能力或用户选择发言。

不过，等值失败也不应自动升级为设备故障。用户可能愿意接受第二选择，总好过什么都没有；也可能明确拒绝替代语言。决定取决于已提供的版本、偏好顺序和应用自己的回退政策。

把偏好一律硬化为门槛，会丢弃可用服务；把偏好一律软化为建议，会让用户持续收到无法使用的内容。RFC 2987 使输入可检查，并没有替所有实现规定同一个答案。

质量值并不测量结果质量

RFC 2533 中的质量值用于限定谓词，未写时默认为 1。它没有提供一种适合所有应用的通用偏好合成算法。不同系统可以有不同候选集，也可以有不同回退规则。

所以 q=1.0 的含义很窄：某份特征集合在那个时点把某个谓词排得很高。它不能证明偏好仍然新鲜，不能保证相应内容存在，不能保证语音自然，也不能证明用户最终理解并完成任务。

字符集的边界更硬，但道理相同。权重可以在真实可用的解码路径之间排序，却不能安装解码器，不能证明标签与字节相符，也不能证明中间设备没有改写内容。

可追责的运行记录至少需要保留：收到的特征集合、规范化结果、评估器版本、本地政策、全部候选、胜出谓词、执行资源、呈现结果以及必要时的用户结果。“协商成功”不能替这些不同问题作答。

登记表只命名问题

IANA 登记项延续至今，说明 RFC 2987 完成了一项耐久的最小协调工作。独立实现可以共享名称与比较语义，不需要由某个应用垄断词汇。

但登记机构不负责安装能力，也不负责作出每一次选择。配置生产者决定宣称什么；内容提供者决定有哪些版本；接收端决定规范化、匹配、权重与回退；用户承担选择的后果。

用 Lu Heng 的“最小初始规范”观察，这套设计把共同层控制在互操作所需的边界：名称、值域、等值语义。未来选择留在本地，没有设立一个全球偏好裁判。

本地自由并不免除证据责任。实现如果把语言偏好当成硬性拒绝，或者把字符集能力当成可随意放宽的建议，就控制了最关键的解释权。它必须留下政策和结果回执，不能把自己的决定包装成登记表的命令。

“运行代码优先”又补上最后一层：标准发布证明共同说明存在，不证明设备已经实现。真正可执行的事实，是机器实际收到了什么、怎样规范化、选择了什么、能否解码、如何呈现，以及用户是否得到可用结果。

应分别保存九层现实：登记、表达、规范化、评估、选择、能力、执行、感知、结果。前一层为真，不代表它有权替后一层作证。

一条克制的安全警告

RFC 2987 在两项登记里都提醒：若某环境在显示特定字符集或语言时存在已知安全缺陷，暴露设备接受该项的事实，可能略微帮助攻击者。文档没有指认产品、漏洞或事件，历史文章也不应凭空制造。

这条警告仍揭示了能力声明的操作性。它会影响选择，也可能暴露攻击面。系统应只收集和披露决策所需的信息，并保持声明新鲜；“接受”更不等于“安全”。

RFC 2987 的历史价值，不在于让字符集与语言变得相同，而在于允许它们共用机械结构，同时不丢失含义差异。

一个问题通常是：机器做得到吗？另一个问题通常是：人更想要哪一个？

两者可以使用相同 token、相同比较和相同权重。可靠系统必须一直记得，答案的权限并不相同。

来源