摘要

  • RFC 3987 为可包含 Unicode 的国际化资源标识符（IRI）建立了明确位置，使它能与以 URI 为基础的软件协作。转换取决于网址中的具体部分：域名式主机可能需要 IDNA 处理；路径或查询里的 Unicode 字符则通过 UTF-8 与百分号编码表示。
  • RFC 3987 的作者是 Martin J. Dürst 和 Michel Suignard；Dürst 的大学简历称他是 IRI 规范的主要作者。这项标准连接了读者熟悉的文字与既有软件，但不会替域名完成注册、证明控制权，也不能证明两个外观相似的字符串指向同一资源。

从输入框到服务器：先还原处理链

设想一条网址：路径里有日文，主机名则用另一种文字书写。读者可以把它当作一个整体；客户端却必须先识别方案、权限部分、路径、查询和可能存在的片段。每个部分随后进入不同的协议规则。人能读的形式与只能接受 URI 的软件收到的形式可以对应起来，却不必逐字符相同。

这正是国际化资源标识符（Internationalized Resource Identifier，IRI）的用途。RFC 3986 定义了统一资源标识符（URI）的通用语法，其字符范围受限于 US-ASCII 的一部分。2005 年发布的 RFC 3987 没有悄悄改写 URI 定义，而是增加了一个能承载 Unicode 的配套标识形式。规范作者解释，另设协议元素可以保持清楚区分，避免破坏现有软件。接受 IRI 的组件可以继续处理较宽的字符范围；如果资源获取链路里的某个组件只接受 URI，就需要按规则把 IRI 映射为相应 URI。

这不是承诺所有旧网络组件从此都会理解任意文字，而是一项互通设计：让支持 IRI 的软件保留更完整的字符序列，并规定何时跨入较窄的接口。标识符可能被保存、显示、复制，也可能用于获取资源；这些操作不一定发生在同一组件，也不一定同时发生。

两个斜线之后，才轮到域名规则

最关键的分界出现在 // 之后的网址权限部分。若主机是 DNS 式域名，RFC 3987 在 2005 年描述的映射会对每个以点分隔的标签执行 IDNA 的 ToASCII 操作，产出适合 URI 时代软件处理的 ASCII 兼容形式。RFC 给出的例子把主机 résumé.example.org 转为 xn--rsum-bpad.example.org。

这个例子既说明 Punycode 做什么，也说明它不做什么：它把域名标签编码为 ASCII 兼容形式，却不转换整条网址，更不能套用到每个非 ASCII 部分。xn-- 也不是有效性的徽章。RFC 5890 把通过 IDNA 规则验证的 A-label 与仅仅长得像 A-label 的字符串区分开来；是否有效需要协议校验，不能靠外观判断。

标准本身也有时间边界。RFC 3987 的主机映射引用了 2003 年的 IDNA 协议 RFC 3490。后来的 IDNA2008 框架（包括 RFC 5890 和 RFC 5891）更新了术语和协议规则。RFC 5895 是一份信息性文件，它讨论应用在 IDNA2008 协议处理之前如何映射用户输入，并指出这类映射可能随语言、应用和输入方式而变。因此，RFC 3987 的例子反映的是该规范在 2005 年的语境，不代表今天每款浏览器都使用同一套转换。

路径不是域名标签

把同样的 Unicode 字符移到路径里，处理方式就不同。路径片段 /研究 在 URI 中可以先转换成 UTF-8 字节，再表示为 /%E7%A0%94%E7%A9%B6。路径不使用 Punycode。它可能由 Web 服务器、应用框架、文件系统或专用路由器解释；DNS 不会逐段解析路径。

查询与片段也有各自语义。百分号、斜线、问号或井号可能是结构分隔符，而不是普通数据，因此解析与转义的先后次序十分重要。RFC 3987 沿用 URI 的组件语法，同时扩展 IRI 可直接包含的字符范围。它并不是“把所有 Unicode 字符改写成某种 ASCII 拼法”。应当采用哪种操作，要看方案和组件。

所以规范建议尽量晚些转换：等到确实要把标识符交给不支持 IRI 的组件时再做。太早转换会在其他 IRI 能力组件接手前丢掉读者熟悉的形式；如果服务器用不同顺序做规范化或解码，两个系统对请求路径的理解也可能不一致。Dürst 与 Suignard 处理的是系统之间的接缝，而不只是如何让地址栏显示非拉丁文字。

格式有效不等于域名已注册

IDNA 只回答一个范围很窄的问题：某个标签能否依照适用规则表示并验证？RFC 5891 把 IDN 注册和查询分成两个流程，并说明注册商在申请到达区域管理者之前的处理不属于该协议的定义；注册局或区域管理者验证的是申请注册的具体字符串。因此，语法有效的 A-label 不能证明域名已经注册、已在 DNS 中委派，或由读者预期的服务控制。

人们把熟悉的 Unicode 名称复制进文件时，很容易忽略这些层次。至少有几份不同的凭据：用户实际输入的字符、界面应用的映射、提交给 DNS 的主机标签，以及 Web 服务返回的响应。注册记录与服务控制证明又是另外的证据，并不是同一字符串的不同拼写。转换成功不能代替其中任何一项。

这也是安全问题。RFC 3987 提到主机和路径都可能受到视觉欺骗：字符相似、双方对规范化的预期不一致，或客户端与服务器的处理规则不同，都可能让外观接近的网址选择不同资源。规范并没有说 Unicode 本身危险，而是要求系统弄清楚自己依赖的是哪一部分、经过了什么处理。屏幕上的字符串能说明呈现方式，却不是身份凭证。

Dürst 的贡献，不是单人发明史

RFC 3987 的署名作者是 M. Dürst 和 M. Suignard。Dürst 在青山学院大学的官方简历称他是 IRI 规范的主要作者，并记载了他在 Web 国际化、Unicode 使用及复合字符规范化方面的工作。简历还显示，他在 RFC 3987 形成的相当一段时间里领导 W3C 国际化活动。青山学院将他列为理工学部教授。

这些记录支撑的是重要贡献，而不是独自完成标准的说法。成果的意义体现在设计选择上：不要求 URI 软件猜测新字符的含义，而是为能处理 Unicode 的软件定义自己的字符表示，并规定何时需要映射。Dürst 的工作属于更广泛的标准化协作，RFC 本身也同时署名 Suignard。

把本文和 Heng Lu 的“准确记录权”联系起来，只是一种有限的分析类比。那份权利主张针对区域互联网注册管理机构与互联网号码资源，不是 DNS 政策，也不管理域名。这里借用的只是一个问题：记录是否准确描述了它声称描述的状态？Unicode 拼写、A-label、DNS 委派和 Web 服务资源键，都是相关但分属不同层级的记录；任何一个都不能代表全部。

来源