- URI：Uniform Resource Identifier，统一资源标识符；(RFC 3986)
- URL：Uniform Resource Locator，统一资源定位符；（RFC 1738）
- URN：Uniform Resource Name，统一资源名称。（RFC 1737）
URI可被视为定位符（URL），名称（URN）或两者兼备。统一资源名（URN）如同一个人的名称，而统一资源定位符（URL）代表一个人的住址。换言之，URN定义某事物的身份，而URL提供查找该事物的方法。
用于标识唯一书目的ISBN系统是一个典型的 URN 使用范例。例如，ISBN 0-486-27557-4(urn:isbn:0-486-27557-4)无二义性地标识出莎士比亚的戏剧《罗密欧与朱丽叶》的某一特定版本。
为获得该资源并阅读该书，人们需要它的位置，也就是一个 URL 地址。在类Unix操作系统中，一个典型的URL地址可能是一个文件目录，例如file:///home/username/RomeoAndJuliet.pdf。该URL标识出存储于本地硬盘中的电子书文件。因此，URL和URN有着互补的作用。
URL方案分类图。URL(定位符)和URN(名称)方案属于URI的子类，URI可以为URL或URN两者之一或同时是URI和URN。技术上讲，URL和URN属于资源ID；但是，人们往往无法将某种方案归类于两者中的某一个：所有的URI都可被作为名称看待，而某些方案同时体现了两者中的不同部分。
—
URI 标准
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 标准，上面的第一个例子 —— http://www.cisco.com/en/US/partners/index.html —— 实际上是一个 URI，并且它由以下几个组成部分：
- 域名 (
www.cisco.com)
- 路径 (
/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 的一个扩展。它用路径名将主机名和用户名结合起来，以获取像/jbrown@freddie.ucla.edu:~mblack/这样的结果。为了跨机器进行命名，为 Web 开发的 URI 语法（按照非标准的 Apollo Domain UNIX）使用了双下划线符号，但是它也引入了方案语法，这样，来自许多不同协议的命名约定得到了统一。其中的一些例子有：
mailto:mbox@domainftp://host/filehttp://domain/path
这里介绍的第二个例子是 www.yahoo.com/sports，它不是一个真正的 URI。 它是对 http://www.yahoo.com/sports 的一种方便的简写，是一种受流行的 Web 浏览器用户界面 (UI) 支持的格式。然而，不要再犯在 XSLT 中遗漏方案这样的错误，如下所示：
<xsl:include href="exslt.org/math/min/math.min.template.xsl" />
|
因为它将不会按照您期望的那样工作，除非您真的 想 在 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。
用 xml:base 重写基本 URI
通常， URI 引用与在哪种文档中发现它有关。如果使用基本 URI http://exslt.org/math/min/math.min.template.xsl 查看一个文档，并看到了一个 URI 引用 ../../random/random.xml，那么引用将扩展为 http://exslt.org/random/random.xml。在 HTML 中，您可以把一个 base 元素放在文档顶端来重写基本 URI。XML Base 规范（请参阅 参考资料）在 XML 中也提供了同样的功能。
考虑一个既可以用 file:/my/doc 访问也可以用 http://my.domain/doc 访问的文档。通常，当通过文件系统访问文档时，您可能希望这些引用像 #part2 那样扩展为 file:/my/doc#part2；而通过 HTTP 访问文档时，您可能希望 #part2 扩展为 http://my.domain/doc#part2。但是在 Resource Description Framework (RDF) 模式中，为了使一些组件正常工作，展开的形式必须保持不变。 XML Base 使这种扩展变得容易（参见清单 1）。
清单 1. RDF 中的展开形式
<rdf:RDF
xmlns="&owl;"
xmlns:owl="&owl;"
xml:base="http://www.w3.org/2002/07/owl"
xmlns:rdf="&rdf;"
xmlns:rdfs="&rdfs;"
>
...
<Class rdf:about="#Nothing"/>
|
在这个例子中，无论您是在哪里找到的那个文件，#Nothing 引用均被扩展为 http://www.w3.org/2002/07/owl#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]。
http://www.ibm.com/developerworks/cn/xml/x-urlni.html
附录(梳理归类)：
其中，URL,URN是URI的子集，其区别如下： Web上地址的基本形式是URI,它代表统一资源标识符，有两种形式： URL：目前URI的最普遍形式就是无处不在的URL或统一资源定位器。 URN：URL的一种更新形式，统一资源名称(URN, Uniform Resource Name)不依赖于位置，并且有可能减少失效连接的个数。但是其流行还需假以时日，因为它需要更精密软件的支持。
参考：http://www.cnlei.org/blog/article.asp?id=356
URN 站点 : http://purl.org/ | http://www.doi.org/demos.html
[文章部分内容引用地址] :
http://blog.sina.com.cn/s/blog_5c4a1a800100gxke.html
[分清 URI、URL 和 URN] http://www.ibm.com/developerworks/cn/xml/x-urlni.html
P.S. : http://,https://,mms://,ftp://,rtsp://,ssl://,sftp://,pnm://,rtmp://等协议, 又如 thunder迅雷 , flashget快车 &&QQ旋风等.
thunder：//类似的协议是base64编码加密。
CSV
Plain text