URL、URI、以及URN

2005 年 7 月 11 日

在信息管理中，持久性和可用性是一对平衡关系。这种平衡导致把技术分为 Uniform Resource Names (URN) 和 Uniform Resource Locators (URL)。其间，Uniform Resource Identifiers (URI) 被设计充当持久性名称和可用位置。本文将解释如何在 XML 技术中使用当前的 URI 标准；介绍 URN 和 URL 的历史，并给出了持久性和可用性之间平衡关系的前景。

World Wide Web 结合了三种技术：数据格式、协议和将两者联系在一起的标识符。诸如 XML 和 HTML 这类数据格式之间的关系是相对清楚的，HTTP 和 FTP 这类协议之间的关系也是如此。但要理请标识符就有些复杂。

Web 地址在 12 年前还是一个相对模糊的东西，但现在，它们不只是出现在 Web 浏览器中，还出现在名片和简介材料中，以及户外广告牌、公共汽车和体恤衫上。一般把它们认为是 Uniform Resource Locators 或 URL。典型的例子是 。但一些简短的这类形式表示的是什 么呢？比如 ，它也是一个 URL 吗？../noarch/config.xsd 是什么呢？而 guide/glossary#octothorpe 又是什么呢?

为了在 XML 名称空间、XML 模式和 Extensible Stylesheet Language Transformations (XSLT) 中很好地利用 URL，您需要知道一些规则。但是 XML 家族的规范涉及到 URI 和 URN —— 它们与 URL 之间的不同是什么呢？这个问题由来已久了。

在这段历史中，我扮演的角色至少要追溯到 1991 年的 Hypertext 会议，在那次会议上，我遇见了 Douglas Engelbart（鼠标的发明者，以及网络计算机和超文本的先驱） 和 Tim Berners-Lee（World Wide Web 的创始人）。在 1990 年的一份关于他 20 多年的研究成果的摘要中，（请参阅 参 考资料），Engelbart 列出了对 Open Hyperdocument System 的需求。“原则上，想要或需要被引用的每个对象都应该有一个明确的地址。” 在 1991 年的一份关于命名的设计文档中， Berners-Lee 写到：

在开放的 hypertext 系统中，这可能是设计和标准化方面最至关重要的一个方面。 它涉及到一个名称的语法，文档或部分文档（锚）都是通过这个名称语法被世界各地引用的。

本文讨论的是 World Wide Web 的命名技术和标准化的目前发展水平， 以及一些技术的历史和发展过程。 它包括了在信息管理中命名的一些技术前景。

RFC3986，即“Uniform Resource Identifier (URI)：Generic Syntax”，是一个 Internet Standard。 Request for Comments (RFC) 系列是著名的档案式文档系列，该系列构成了 Internet Engineering Task Force (IETF) 标准过程的主干。 在数以千计的 RFC 中，只有很少的部分，比如 TCP (RFC793) 以及 Internet Mail 格式 (RFC821) 和协议 (RFC822)， 提高了整个 Internet Standard 的发展水平。 RFC3986 在 2005 年 1 月也提高了这个水平。

按照 URI 标准，上面的第一个例子 —— —— 实际上是一个 URI，并且它由以下几个组成部分：

• 方案名 (http)
• 域名 ()
• 路径 (/en/US/partners/index.html)

IETF 达成共识，共同管理该方案。Official IANA Registry of URI Schemes（请参阅 参 考资料）中包括一些大家所熟悉的方案，如 http、 https 和 mailto，还有其他许多您可能熟悉或不熟悉的方案。

URI 路径像一个典型的文件路径名。URI 按照 UNIX® 的惯例采用了正下划线 (a/b/c)，因为在 20 世纪 80 年代后期设计 URI 的时候, 在 Internet 上， UNIX 文化比 PC 文化更流行。正是那个时候，出现了几个用于访问远程文件的流行表示法。其中一个是 Ange-ftp， 它是用来编辑远程文件的 emacs 的一个扩展。它用路径名将主机名和用户名结合起来，以获取像/[e-mail]:~mblack/这 样的结果。为了跨机器进行命名，为 Web 开发的 URI 语法（按照非标准的 Apollo Domain UNIX）使用了双下划线符号，但是它也引入了方案语法，这样，来自许多不同协议的命名约定得到了统一。其中的一些例子有：

• mailto:mbox@domain
• ftp://host/file

这里介绍的第二个例子是 ，它不是一个真正的 URI。 它是对 http:// 的一种方便的简写，是一种受流行的 Web 浏览器用户界面 (UI) 支持的格式。然而，不要再犯在 XSLT 中遗漏方案这样的错误，如下所示：

因为它将不会按照您期望的那样工作，除非您真的 想 在 XSLT 样式表之后引用 exslt.org 目录中的一个文件。XSLT 的 href 属性采用了一个 URI 引用，它可能是绝对引用，也可能是相对 引用。以一个方案和一个冒号开始的 URI 引用是绝对引用；否则，该引用就是相对引用。相对的 URI 引用更像一个文件路径。例如，../noarch/config.xsd 也是一个相对的 URI 引用。

HTML 中的 href 属性采用了 URI 引用，这样讲有些过于简单。URI 和 URI 引用都是从有限的 ASCII 字符集合中得出的，并且 HTML 比它们更加国际化。事实上，对遵循 RFC3986 的注释的请求是符合 RFC3987 标准，即 Internationalized Resource Identifiers (IRI) 标准（请参阅 参 考资料）。此规范在 IETF 标准化过程中没有它的前辈走的远，但是技术本身已是相当成熟，并被广泛部署。除了能够使用所有 Unicode 字符，而不是仅仅能够使用 ASCII 字符之外，IRI 和 URI 是完全一样的。像 URI一样，每个 IRI 都有一个相应的编码，以防需要在只接受 URI 的协议（比如 HTTP）中使用 IRI。

通常， URI 引用与在哪种文档中发现它有关。如果使用基本 URI 查看一个文档，并看到了一个 URI 引用 ../../random/random.xml，那么引用将扩展为 。 在 HTML 中，您可以把一个 base 元素放在文档顶端来重写基本 URI。XML Base 规范（请参阅 参 考资料）在 XML 中也提供了同样的功能。

考虑一个既可以用 file:/my/doc 访问也可以用 访问的文档。通常，当通过文件系统访问文档时，您可能希望这些引用像 #part2 那样扩展为 file:/my/doc#part2； 而通过 HTTP 访问文档时，您可能希望 #part2 扩展为 #part2。 但是在 Resource Description Framework (RDF) 模式中，为了使一些组件正常工作，展开的形式必须保持不变。 XML Base 使这种扩展变得容易（参见清单 1）。

				
  xmlns="&owl;"
  xmlns:owl="&owl;"
  xml:base=""
  xmlns:rdf="&rdf;"
  xmlns:rdfs="&rdfs;"
>
...
    

在这个例子中，无论您是在哪里找到的那个文件，#Nothing 引用均被扩展为 #Nothing。

好了，关于 URI、IRI 和 URI 引用的介绍就到此结束了。下面将介绍 URL 和 URN。

回页首

设计 URI 的目的是让它起到名称和定位器的作用。当 IETF 用它们实现标准化的时候，它们就成了通常所说的 Uniform Resource Locators，并且另一项关于 Uniform Resource Names 的独立的工作也已经开始了。

对于 Internet 主机，名称和位置都有单独的标准。主机名和域名有相同的语法（例如，zork1.example.edu）。 这些主机名通过 Domain Name System (DNS) 协议和类似 192.168.300.21 的地址相连。当主机改变了在网络中的位置或重新编号之后，这种间接的做法允许主机保留其名称。

Web 中偶尔中断的链接使 Web 地址从外观上看更像是一个位置，而不是一个名称，并且在 IEIF 社区中也出现了不同的观点：

• URI:RFC1630，发布于 1994 年 6 月，被称为“Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web”（请参阅 参 考资料）。它是一个Informational RFC —— 也就是说，它没有获得社区的任何认可。
• URL:RFC1738，发布于 1994 年 12 月, 被称为“Uniform Resource Locators”（请参阅 参 考资料）。它是一个 Proposed Standard —— 也就是说，它是一个共识过程的结果，虽然它还没有经过测试，并成熟到足以成为一个完整的 Internet Standard。
• URN:RFC1737，发布于 1994 年 12 月，被称为“Functional Requirements for Uniform Resource Names”（请参阅 参 考资料）。

1997 年，紧随 Proposed Standard RFC2141（即 URN Syntax）之后发布了 RFC1737，它指定了另一个方案 —— urn: —— 来加入 http:、ftp:和 其他协议中。

最终的 URI Standard (RFC3986) 在 1.1.3 小节“URI, URL, and URN”中澄清了这一区别：

URI 可以进一步分为定位器、名称，或者二者兼具。术语“Uniform Resource Locator” (URL) 涉及的是 URI 的子集，除识别资源外，它还通过描述其最初访问机制（比如它的网络“位置”）来提供定位资源的方法。 术语“Uniform Resource Name” (URN) 在历史上曾用于引用“urn”方案 [RFC2141] 下的 URI，这个 URI 需要是全球惟一的，并且在资源不存在或不再可用时依然保持不变，对于其他任何拥有名称的一些属性的 URI，都需要使用这样的 URI。

对于单独的方案，没有必要将其分为仅仅是一个 “名称”或者是一个“定位器”。 来自任意特定方案的 URI 实例可能有名称或定位器的特征，或两者兼而有之， 这通常取决于标识符分配中的持久性和命名机构对其关注程度， 而不取决于其他方案的质量。未来的规范和相关的文档应当使用通用术语“URI”，而不是使用有更多限制的条目“URL”和“URN” [RFC3305]。

回页首

持久性和可用性之间存在着一种天生的紧张关系。如果我在一台连接到 Internet 的主机上有一个文件，使其可用的最简单的方法是：在主机上运行一个 Web 服务器，并交给您一个由主机碰巧得到的名称组成的 URI，以及文件名（例如， ）。 在 Dynamic Host Configuration Protocol (DHCP) 租约到期之前，它一直工作得很好，接着，我改变了 ISP，或者说我将文件从 /drafts/ 移动到了 /keepers/ 中。如果服务逐渐流行，那么我决定购买它的时候将会发生什么呢？名称中的信息越是无关紧要，它能够坚持不改变的可能性就越小。

但是一个良好的持久的名称（如 ）是不易管理的。必需 要注册一个域，维护从域名到主机地址的映射，还要记住，ls434 是保存我的午餐服务描述的文件，或者是在 Web 服务器上建立一个文件映射表的地方。

PURL 项目和 Digital Object Identifier (DOI) 系统（请参阅 参 考资料）代表了解决持久性问题的不同方法。Persistent URL (PURL) 在域中是一个普通的 HTTP URI，它受到强大的持久性策略的支持。例如，purl.org 由 Online Computer Library Center (OCLC)运行，OCLC 是一个全球范围的库协作组织。任何人都可以申请一个帐户并管理他或她的 PURL 设置。可以将内容发布在普通的 Web 服务器上，然后用 HTTP 重定向连接到 PURL。从 PURL 到持久性较底的 HTTP URI，这种的间接性和 DNS 提供的间接性非常相似，只要重定向的来源和目的不在同一类别中即可。在安装好一个 PURL（如 之后，就可以像使用其他任何 HTTP URI 一样使用它。更重要的是，您想要进行通信的人可以像使用其他任何 HTTP URI 一样使用它；不需要任何插件或增件。

DOI 系统使用它自身的方案 —— 比如 doi:10.123/456。Web 浏览器可以适应的支持这个带有插件的方案。DOI 基金会像 PURL 提供者（如 OCLC）一样提供策略、注册服务和 HTTP 重定向服务。当 DOI 基金会支持格式 的每个 DOI 的别名时，DOI Handbook（请参阅 参 考资料）声称此系统“与分解器插件比较时有明显的缺点。” 为一个对象管理两个不同的名称似乎是我的一个明显不足之处。

回页首

尽管持久性和可用性之间存在压力，但好的 URI 可以同时具备这两种特性；好的 URI 既是一个持久性名称，又是一个可用的位置。所以，URL 实际上是一个带有实际有用工具的 URI。

urn: 方案的支持者争辩说，他们认为这种压力在 HTTP 和 DNS 的范围内是矛盾的。我承认确实涉及到了某些领域，但每个 Web 管理者都面对着相同的问题，而且社区正在学习一些信息管理原理，以便对它们进行定位。基本的问题是：世界在不断变化，要保持事物同步就需要付出努力。

大多数时候，使用 DNS 命名的分层结构特性是为了提供便利，但它在一个位置集中了大量的力量，并产生了复杂的管理方式问题。点对点设计，比如分布式散列表，可能用 DNS 消除一些集中问题，但谁知道使用它们将带来什么样的管理问题呢？许多不同的前沿开发展示了如何将新协议服务于现有的 名称，增加现有超媒体网络的价值。对任何与 HTTP 的 GET/PUT/POST/DELETE 操作相似的远程操作而言，这种方法看起来比新方案的部署更有可能成功。 我期望目前信息管理中的最佳实践和未来协议增强使得构建在 HTTP 和 DNS 上的精选的 URI 能够持续很长一段时间。

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• 请参阅“Knowledge-Domain Interoperability and an Open Hyperdocument System”，这是 Douglas Engelbart 于 1990 年在计算机支持的协作工作 (CSCW) 领域中的前沿研究成果的总结。
  
  
• 研究 Tim Berners-Lee 撰写的 的“Document Naming”部分，这个系列的文章始于 1991 年，并一直持续至今。
  
  
• 找到更多关于 的信息，该机构开发了 Internet Protocol、DNS、Internet Mail和其他许多 Internet 技术。 RFC 系列是 IETF 标准过程的主干。接下来的 RFC 系列将在下列文章中讨论：
  • (W3C 保持了 )
  • (Roy Fielding 的 也很方便)
  
  
• 请参阅 ，它在其他内容中保留了 。
  
  
• 想了解更多关于 PURL 的信息以及它们的使用方法吗？请参阅 ，同时请务必阅读.
  
  
• 查 找关于 的信息以及它的持久性方法。DOI Handbook 有它自己的 。
  
  
• 访问 W3C，查找更多关于 , 和 的信息。
  
  
• 在 Uche Ogbuji 撰写的 developerWorks 文章“XML 设计原则：小心使用 XML 名称空间”（2004 年 4 月）和他的 XML 标准概览: 第 1 部分（2004 年 1 月）中进一步学习 URL、URN 和 URI。
  
  
• 在 developerWorks XML 专区 上有更多 XML 方面的参考资料。
  
  
• 可以在 developerWorks Developer Bookstore 上浏览大量与 XML 相关的主题。
  
  
• 学习如何才能成为一名 。
  

		Dan Connolly 是 W3C URI Activity 的领导、W3C Technical Architecture Group 的成员和 RDF Data Access Working Group 的主席。他于 1995 年加入 W3C。在 1995 年编辑了 HTML 2.0 规范，领导 Working Group 生产出了 HTML 3.2 和 4.0 以及 CSS 1.0， 还领导 XML Activity 在 1998 年发布了 XML 1.0 版本，随后于 2001 年发布了 XML 模式，接着，他参与了 Web Ontology Language 的开发，使其在 2004 年成为 W3C Recommendation。Dan 还是 MIT Computer Science and Artificial Intelligence Laboratory 中的 Decentralized Information Group 的一名研究科学家。