摘要

  • ICANN 2026 年 8 月 24 日的公示总结确认一项具体更正：U+A9B4 可跟在 U+A9BA 或 U+A9BB 之后，而不是草案所写的 U+A9BA 或 U+A9BC。
  • 错误不只在说明文字里。4 月 23 日的支持提案、可读 HTML 和 RFC 7940 XML 都使用了 A9BA/A9BC；XML 规则名就是 follows-A9BA-A9BC。
  • ICANN 表示会与爪哇文社群讨论并把更正纳入最终版本。截至 9 月 1 日，二级参考 LGR 页面仍以 2024 年 10 月 25 日为当前版本，没有最终爪哇文条目。
  • 参考 LGR 用于帮助注册局设计 IDN 表，也用于 ICANN 审查注册局提交的表；它本身不是某家注册局的 IDN 表，更不会自动更新下游部署。
  • 最小闭环应是一份版本化更正回执，把意见、社群处置、精确差异和最终文件哈希连起来，同时把注册局采用保留为另一项可归属事实。

一个码位关系穿过了三份草案

本轮公示 5 月 12 日开始，6 月 23 日结束，涵盖两份新增参考 LGR——爪哇文和统一加拿大原住民音节文字——以及六份更新。ICANN 收到 33 条相关意见，其中 32 条支持；唯一一条针对爪哇文的意见要求纠错并澄清规则关系。

提交者 Arif Budiarto 是爪哇文提案的贡献者。他指出，U+A9B4（JAVANESE VOWEL SIGN TARUNG）应允许跟在 U+A9BA（JAVANESE VOWEL SIGN TALING）或 U+A9BB（JAVANESE VOWEL SIGN DIRGA MURE）之后。草案误写成了 U+A9BC（JAVANESE VOWEL SIGN PEPET）。他同时强调，这项修改不改变底层正字法意图，而是把原本的意图准确写回文件。

这不是只改 PDF 里的一句话。40 页支持提案在第 38 页的规则 4 使用 A9BA/A9BC；HTML 版本重复同样条件；XML 把 follows-A9BA-A9BC 作为 U+A9B4 的 when 规则，并在规则类中列入 A9BA 与 A9BC。公示意见因此直指机器可读条件。

规则 3 与规则 4 的分工也需要留下来。规则 3 是一般要求：依附元音必须跟在辅音、中介辅音或独立元音之后。规则 4 针对 U+A9B4 施加更窄的限制。它不是取消一般规则，而是在满足一般位置要求后，再限定特定前序组合。工作组承诺会同步修改文字、规则引用和支持文件的说明。

边界同样重要。A9BC 仍是草案字符库中的 JAVANESE VOWEL SIGN PEPET。本文没有把它描述成普遍无效字符；更正只涉及它能否成为 U+A9B4 在这条特殊规则中的前序字符。

总结报告确认方向，却不是最终规则文件

ICANN 的总结报告对后续动作写得很清楚：先与爪哇文社群讨论，再把更新纳入最终版本；在考虑意见并按需修改后，把最终参考 LGR 发布到二级参考 LGR 页面。

这段处置记录证明 ICANN 没有忽略意见，但它无法替代更正后的 XML、对应 HTML 和修订支持提案。9 月 1 日核查时，官方页面仍显示“当前版本：2024 年 10 月 25 日”，按文字体系列出的发布清单中没有爪哇文。公示阶段的 4 月文件仍是可下载的爪哇文包。

八天的间隔本身不构成延误指控。社群确认、三份材料的一致修改和 XML 验证都需要时间。真正容易出错的是把不同状态压成一句话：若说“规则已改”，就把总结当成制品；若说“更正未被接受”，又与 ICANN 明示的处置相矛盾。

ICANN 的开发指南说明了为何必须等文件。参考 LGR 的规范规则用 RFC 7940 XML 表达，审查还要确认 XML 是否准确刻画预期码位与规则。文字承诺证明意图，版本化文件才证明实现。

参考文件不会替注册局作决定

最终发布后，注册局可以在设计国际化域名表时参考这些规则，ICANN 也会在审查 gTLD 注册局提交的 IDN 表时使用它们。这让参考 LGR 具有实际影响，但没有把它变成远程配置系统。

共同参考文件、注册局提交的表、ICANN 的审查结果和运营商最终采用状态，是四个不同对象。它们可能在不同日期对齐，也可能因为本地需求而保留可解释差异。

这种拆分能同时抑制两种夸张。现有证据没有指出哪份在用的注册局表复制了草案错误，也没有发现域名失效、注册被拒或安全事故。另一方面，未来看到最终 XML 上线，也不能直接宣布所有注册局已完成修复。

更正回执不必很大

第一部分固定“观察到什么”：4 月 23 日包的三个 URL 与哈希、U+A9B4、受影响规则名、A9BA/A9BC 条件、提交者和 A9BA/A9BB 更正。规则 3 与规则 4 的关系也应作为限定说明保存。

第二部分固定“谁作了什么决定”：意见提交时间、爪哇文社群讨论状态、ICANN 处置、最终验证责任职能。如果最终 XML 通过改名或重构实现等价条件，而不是直接替换字符串，回执要说明语义等价。

第三部分固定“发布了哪些字节”：最终 XML、HTML 和支持提案的版本、日期、稳定链接与哈希。一份机器可读 diff 应显示，在 U+A9B4 的特殊前序集合里移除 A9BC、加入 A9BB；配套测试列出允许与不允许的序列。旧草案可继续用于历史研究，但必须显著标记为已被替代。

最后，注册局层只做链接，不做推定。提交的 IDN 表注明所依据的参考版本；ICANN 记录审查；注册局记录采用。没有记录时只能说“尚无公开证据”，不能替运营商作结论。

这正是 Heng Lu 所说的最小共同层：只保存参与者协调所需的角色、制品、规则、状态、版本、日期与修订，本地实施仍由承担责任的主体决定。

现有证据的限度

没有一手资料显示某家现行 gTLD 注册局采用了 4 月草案，也没有证据把该条件与活跃域名或用户损失相连。公示本来就是在最终发布前发现此类问题的环节。

同样，没有依据把这件事写成 ICANN 抵制社群意见。总结报告明确承诺纳入最终版。新闻价值在于：发现已经可归属，闭环仍需要同样可归属的最终制品。

来源

  1. ICANN：2026 年 8 月 24 日公示总结报告
  2. ICANN：Additional Reference Label Generation Rules 公示
  3. ICANN：Arif Budiarto 提交意见
  4. ICANN：5 月 12 日参考 LGR 文件索引
  5. ICANN：爪哇文参考 LGR 草案 XML
  6. ICANN：爪哇文参考 LGR 草案 HTML
  7. 爪哇文生成小组：支持提案
  8. ICANN：二级参考标签生成规则
  9. ICANN：二级参考 LGR 开发指南
  10. RFC Editor：RFC 7940
  11. Heng Lu：Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption