摘要

  • RFC 9553 先按 RFC 5646 语言标签选择 PatchObject，再复制基础 Card、去掉 localizations，把全部补丁施加到副本，并将其作为本地化变体使用。
  • 整体拒绝规则能防止半套补丁落地，却不能证明译文官方、别名获批、作者有权修改，或联系方式仍属当前事实。
  • 可问责的本地化记录必须绑定基础版本、选中标签、补丁哈希、授权范围、输出哈希和后续用途，而不是把每种语言当作独立事实源。

完整页面制造了独立来源的错觉

读者不会看到“基础对象加若干路径替换”。他看到的是一张完整联系人卡片。姓名、头衔、电话、地址同时出现，界面自然让人以为这一语言版本有自己的一套来源和审核。

RFC 9553 对 localizations 的定义更严格。它是从语言标签到 PatchObject 的映射。生成变体时，应用先确定语言标签；若存在对应条目，就复制 Card，但不复制 localizations；随后把全部补丁应用到副本，可选择更新副本的 language，再使用这个结果。

副本没有因此获得新的 uid，标准也没有赋予它单独的修订历史、事实负责人或身份验证结果。它继承基础 Card 未被修改的字段，并依赖选中的那一组补丁。

如果系统只保存最终页面，就失去了两项关键输入。以后出现差异时，无法判断错误来自基础数据、补丁文字、语言选择还是缓存的旧版本。本来可重放的投影，会退化成一份来历不明的复制品。

原子性只回答结构问题

PatchObject 的键使用带隐含前导斜杠的 JSON Pointer 子集。最后一个路径段之前的对象必须已经存在；可以替换数组中的现有成员，却不能用 插入或删除；同一补丁集中不能有一条路径是另一条的前缀；新值必须符合目标属性的类型和限制，null 只能删除可选属性。

任何一项无效，整个 PatchObject 都必须被拒绝，不能留下已经成功的一部分。这个规则很重要：系统不能只替换姓名，却悄悄忽略失败的地址修改，然后向读者展示混合状态。

但“整体有效”只说明这组转换能对给定基础对象按模型执行。它不说明译文自然，不说明新职务仍然真实，也不说明提交者有权换掉电话或电子邮箱。

生产系统至少应区分：JSON 可解析、模型有效、补丁可应用、来源已认证、字段修改已授权、身份名称已批准、事实仍有效、实际联络已成功。把它们合并为一个“已本地化”状态，是把解析器没有做过的判断强加给解析器。

路径与基础版本不可分离

RFC 9553 给出两种很不一样的示例。一种用另一种文字完整替换顶层 name；另一种只修改 titles/t1/name，保留 t1 的其他成员。后者精确而高效，但它假定 titles 仍存在、t1 仍指向同一职务、name 仍允许这个值。

标准要求同一 JSContact 对象多个版本之间保留 Id 映射键，这正是为了稳定引用和补丁。不过这些键只是局部坐标。标准明确指出，相同 Id 出现在不同映射或不同 Card 中，并不自动表示语义关联。

所以，为基础哈希 A 审核过的补丁，不能在没有记录的情况下直接套到 B。若 t1 的业务含义已经改变，路径仍可能有效，输出却已经过时；若键被移除，补丁应当失败；若基础只改了不相关字段，补丁可能继续适用，但这需要明确的复核规则。

updated 无法还原这段历史。它只表示 Card 数据最近被修改的时间，不告诉系统改了哪个字段、谁改的、依据是什么、旧值是什么，也不证明所有本地化都重新审核。prodId 是产品标识，不是签名。version 是 JSContact 模型版本，不是这张卡片的业务修订号。

语言标签不是官方名称证明

RFC 5646 标签可以表达语言，也可带文字或地区信息。RFC 9553 的流程第一步是“确定语言标签”，却没有替所有产品规定完整的协商政策。是否从 zh-Hant-HK 回退到 zh-Hant，如何处理读者偏好，何时使用主语言，仍是应用决策。

格式正确的标签也不会认证标签背后的字符串。机构的另一语言名称可能是官方名称、惯用译名、音译、编辑便利说法，或者彻底杜撰。个人姓名换一种文字，可能保留了本人认可的原名，也可能创造一个从未使用过的名字。

PatchObject 可以携带这个替代值，但没有权力把它升级成官方别名。涉及个人和机构身份时，系统应保存官方多语来源、本人确认的别名，或经过审查的转写规则。没有这些证据，最多只能说“系统能够展示这一语言变体”。

这条边界也适用于地址和职务。地址本地化可能只是调整顺序，也可能把地区翻错；职务翻译可能准确，也可能无意中提高或降低级别。语法合格无法替代语义审核。

攻击者同样会写流利的本地化内容

RFC 9553 的安全章节把联系人数据称为高度敏感信息，因为它可能暴露身份、位置、凭据、就业、兴趣和社交关系。文档列出窃听、重放、插入、删除、修改和路径中攻击。

更直接的例子是冒充：攻击者使用他人的姓名，却填入自己的联系方式。自然的本地化甚至会让欺骗更可信。读者看到熟悉的文字、得体的称谓和本地格式，可能更少检查电话或邮箱究竟由谁控制。

RFC 要求会产生现实后果的系统认证收到的数据，并确保修改来自获授权实体。随后它又划清自身范围：本文只定义数据格式；API、存储和传输方式必须承担外围安全责任。

因此，认证传输只能说明哪个服务送来了 Card，不一定说明该服务能修改所有字段。数字签名可以证明谁签了补丁，不一定证明姓名主体批准了别名。模式校验能识别非法路径，却识别不了类型完全正确的谎言。

注册表协调词汇，不裁定事实

RFC 9553 注册 JSContact 1.0，并建立版本、属性、类型和枚举值注册表。条目可标记 Since Version 和 Until Version，帮助实现判断某个属性在何种模型中有效。

这是互操作权威，不是实例事实权威。注册表能回答“这个属性是否定义”，不能回答“首席科学家是否仍是此人的职务”“这个地址是否可公开”“这个号码是否属于姓名所指的人”。

“有效 JSContact”应当保留这种精确含义：它针对指定模型和注册表快照有效。若界面把它翻译成“联系人已验证”，就把格式治理错误提升成身份认证。

轻量谱系比九份独立副本更可靠

可重放记录并不复杂。它包含基础 Card 的 uid、模型版本、内容哈希和业务修订；语言选择请求或政策；PatchObject 原文、哈希、来源和授权范围；整体校验结果；输出哈希、时间和下游消费者。

若补丁改变受保护的个人或机构名称，再附上别名批准依据。若本地化邮箱、电话或地址触发自动化，再记录动作与结果。页面成功显示不能代替邮件送达、电话接通或权限正确授予。

基础更新到来时，这条谱系能支持三种不同结论：补丁不受影响、补丁需要复核、补丁已失效。系统不必靠复制九张卡片并期待它们偶然保持一致。

本地化的价值在于让同一份资料更容易理解。只有当继承事实、替代字符串、批准者和实际效果都能被解释时，这种便利才不会变成无声的权力扩张。

来源