摘要

  • RFC 3151 先规范化公共标识符字符串，再把空格、结构分隔符与字面保留字符转写为确定的 urn:publicid:；转写正确只证明名称变换正确，不证明所有者或资源有效。
  • 词法等价被严格限定：完成规范化后，两个 URN 只有逐字符相同时才等价；相同名称仍可能遇到不同目录、映射、字节和应用结果。
  • 解析可以来自 OASIS 目录、本地路径、程序内置知识或缓存，因此解析器选择、规则命中、取回、内容校验、解析器行为和用户结果都要分别留证。

它要解决的是名称搬运，不是资源定位

XML 外部实体同时拥有 system identifier 与 public identifier。前者按定义是 URI，历史上常是某台机器或某套系统里的位置；后者只是字符串，却往往被当作更全局、更持久的名字。

当 XSLT、XML Schema 等新规范要求外部标识符都采用 URI 时，旧名称无法原样进入接口。若强迫所有文档与目录改名，已安装的软件和内容会立即承担迁移成本。RFC 3151 选择了较小的桥：登记正式命名空间 publicid，把已有字符串表示为 urn:publicid:{transcribed-public-identifier}。

URI 的外形容易制造一次权威升级的错觉。事实上，结果的唯一性与持久性仍继承自原公共标识符。未登记的所有者不会因为前缀而获得登记，随意起的名字也不会突然变得可靠。

RFC 3151 是 Informational，并明确说自己不是互联网标准。文中的示例也只为教学，不保证现实存在。因此一组漂亮的前后转换只说明算法如何工作，不说明名称已部署、目录可用或资源能被取回。

规范化为了比较，主动丢掉一部分历史

转写之前，XML 公共标识符要先规范化：空格、制表符、回车和换行组成的连续片段统一变成一个普通空格，首尾空白被删除。RFC 在讨论编码时假定这一步已经完成。

于是，两份只在缩进或换行上不同的原始记录可以得到同一个规范化名称。这对比较有益，却不是无损变换。若系统只保存最终 URN，原始空白布局就无法复原。

规范化后的空格写成 +。由于连续空白早已合并，合规输出中不会因空格产生相邻的加号；源字符串里真正的字面 + 则必须写成 %2B。一个代表空格，一个代表字符本身，两者不能混为同一证据。

可审计记录应保存原字符串、字符编码、规范化结果、规则版本和最终字节。只留最后一列的数据库可以比较名称，却无法说明何时丢掉了哪些信息，也无法证明操作顺序正确。

分隔符保留了形状，没有替结构背书

SGML 的 Formal Public Identifier 是公共标识符中的结构化子集，通常包含所有者、公共文本类别、描述、语言或指示序列，以及可选的显示版本。常见 FPI 用 // 分开字段，也可能在内部使用 ::。

RFC 3151 把 // 写成 :，把 :: 写成 ;。这个机械规则能保留结构的外观，却不要求转写器理解完整 SGML 语法。判断源字符串是否真是合法 FPI、各字段是否有意义，本来就不属于算法。

因此，输出里的冒号可以证明规范化源中出现过双斜线，却不能证明所有者已登记，也不能证明该串满足 FPI 语法。

字面字符还要与转写产生的分隔符区分：不属于 :: 的 : 写成 %3A，不属于 // 的 / 写成 %2F，字面 ; 写成 %3B；撇号、问号、井号和百分号也各有转义。替换的位置与顺序都是收据的一部分。

往返测试可以证明实现没有破坏规范化名称，却仍然不能证明命名权、资源存在或解析成功。

逐字符相等没有扩张为内容相等

这份 RFC 给出的等价规则非常窄：源字符串完成强制规范化后，两个 publicid URN 当且仅当词法完全相同时才等价。它没有定义大小写折叠、所有者别名、字段语义比较或“指向同一文件”推理。

本地目录把两个名称映射到同一个目标，不会让两个名称在命名空间里变成相等。反过来，同一个 URN 也可能在两台机器上遇到不同的目录链、基准 URI、文件系统或缓存，最终拿到不同内容。

规范还允许一个资源拥有多个公共标识符。所以，名称相同、映射相同、字节相同和行为相同是四种不同判断；名称不同也不能直接推出资源不同。

RFC 3986、RFC 8141 等后续文件描述 URI/URN 规则怎样演进，却不会追溯修改某次历史目录查询，更不会把 RFC 3151 的词法等价扩写成资源等价。

命名空间把所有者的弱点一并带了过来

有登记所有者的 FPI 被要求唯一；非正式公共标识符以及所有者未登记的 FPI 可能唯一，也可能不唯一。RFC 没有宣称一种统一的执行政策。

持久性同样从源名称继承。登记所有者通常提供更好的基础，但并不保证目录在线、目标不变或内容永存。用域名生成登记所有者的 IDN 方案，至少继承域名本身的持久性弱点。

因此，“URN”不是自动升级。编码脆弱名称不会修复政策，登记所有者不会替它维护每个目录，稳定名称也不会冻结历次表示。如果资源尚无公共标识符，必须先按原制度创建，再应用转写；而一个资源可以有不止一个名称。

名称来源需要保存所有者、登记状态、分配政策、时间和上下文，不能从字符串外观反推权威。

解析仍是一组本地选择

RFC 列举了多种既有办法：OASIS 目录可以映射公共名称；系统可以把组成部分映射为本地路径；软件可以内置一组已知名称；缓存等 URI 机制也可以参与。urn:publicid: 背后没有由本文定义的唯一全球解析器。

目录顺序、重写规则、基准 URI、挂载路径、网络可达性和缓存新鲜度都可能改变结果。目录命中只证明某条规则选出了目标，不证明目标已被打开。

取回文件或响应后，还要记录字节与摘要；随后才轮到具体解析器、版本、实体策略和诊断；最后才是应用或用户结果。一个 resolved=true 会把整条链压扁成无法审计的结论。

RFC 没有指定验证机制。它说没有超出一般 URN 使用和解析的新安全考虑，也不等于所有者、目录、缓存或内容已经认证。确定的编码器完全可能精确地抵达过期或被替换的映射。

运行结果有权纠正完美名称

设想一个转写完全正确的 URN。解析器命中第一份目录，找到本地文件，文件也能被解析；但内容属于旧版包。名称层、映射层和文件打开都成功，应用结果仍然错。

另一台机器可以用同一 URN 命中另一份 DTD。缓存可以在所有者调整政策后继续保留旧目标。程序内置表可以在网络资源消失后仍然“成功”。它们各自真实，却不能互相冒充。

RFC 3151 的表格对名称转写具有规范权威。运行代码回答的是后半段：哪一个解析器执行、哪一条规则胜出、哪些字节抵达、应用做了什么。运行证据不是取消规范，而是阻止规范被夸大为结果证明。

这项历史工作的价值恰好在边界清楚：旧公共名称得以进入 URI 架构，却没有被伪装成位置。把身份带过语法边界，只完成了抵达资源之前的一步。

来源