Skip to content

网络

了解 URI, URL, and URN

url-300x197

  • 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,并且它由以下几个组成部分:

th

  • 方案名 (http)

url(uniformresourcelocator)

  • 域名 (www.cisco.com)
  • 路径 (/en/US/partners/index.html)

thCA1OQ0FA

IETF 达成共识,共同管理该方案。Official IANA Registry of URI Schemes(请参阅 参考资料)中包括一些大家所熟悉的方案,如 httphttpsmailto,还有其他许多您可能熟悉或不熟悉的方案。

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@domain
  • ftp://host/file
  • http://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编码加密。

 

Special-Use Domain Names

  • Created

2012-07-06

  • Last Updated

2013-02-21

Special-Use Domain Names

Registration Procedure(s)
Standards Action and IESG Approval
Reference
[RFC6761]
Note
The "Special Use" designation applies to both the listed domains and their subdomains.
Alternative Formats
CSV      Plain text
Name Reference
10.in-addr.arpa. [RFC6761]
16.172.in-addr.arpa. [RFC6761]
17.172.in-addr.arpa. [RFC6761]
18.172.in-addr.arpa. [RFC6761]
19.172.in-addr.arpa. [RFC6761]
20.172.in-addr.arpa. [RFC6761]
21.172.in-addr.arpa. [RFC6761]
22.172.in-addr.arpa. [RFC6761]
23.172.in-addr.arpa. [RFC6761]
24.172.in-addr.arpa. [RFC6761]
25.172.in-addr.arpa. [RFC6761]
26.172.in-addr.arpa. [RFC6761]
27.172.in-addr.arpa. [RFC6761]
28.172.in-addr.arpa. [RFC6761]
29.172.in-addr.arpa. [RFC6761]
30.172.in-addr.arpa. [RFC6761]
31.172.in-addr.arpa. [RFC6761]
168.192.in-addr.arpa. [RFC6761]
254.169.in-addr.arpa. [RFC6762]
8.e.f.ip6.arpa. [RFC6762]
9.e.f.ip6.arpa. [RFC6762]
a.e.f.ip6.arpa. [RFC6762]
b.e.f.ip6.arpa. [RFC6762]
example. [RFC6761]
example.com. [RFC6761]
example.net. [RFC6761]
example.org. [RFC6761]
invalid. [RFC6761]
local. [RFC6762]
localhost. [RFC6761]
test. [RFC6761]

域名注册信息查询工具 Net Info Tools

发布我自用的一个域名注册信息查询工具。 功能主要集中在域名WHOIS方面。

A Tools for  Domain/IP Whois, HTTP Scan, Route trace, root servers Monitoring, QQWry IPLocate. :)p
一个多功能的域名工具. 可以whois域名/IP, 扫描http头信息, 路由追踪, 服务器状态, 调用QQWry查询ip归属. (最新版本 几乎支持所有域名后缀的可注册状态查询, 需要服务端接口支持, 暂不公开发布

下载:(可下载使用的版本

域名 和 IP地址的 WHOIS信息查询

1

WHOIS域名,查询域名相关注册信息,还可转至映射(Referral)的域名管理商WHOIS服务器查询更详细的注册信息。

IP WHOIS 查询IP地址所在的NIC归属,以及AS地址编码等相关分配所有信息。

2

 

HTTP Scan

扫描获取相关IP地址的WEB服务器HTTP 头信息, 可查询一个C类地址段。

22

 

IP Info

目前有3个功能, 简单路由追踪,Root跟服务器状态监视,ipv4地址分配表。

33

QQWty

如同其名,调用 纯真网络 的QQWty.dat 查询IP归属地。QQWty可以从 “纯真网络 -> 金狐软件 获取。

44

Tools

域名注册及查询相关工具。 包括WHOIS服务器验证,以及域名列表生产器,可以根据各种域名后缀TDL, 进行组合成。

55

.CN Delete

到期删除的.CN域名和中文域名列表,可以查询最近3天的域名删除列表。 支持按后缀类型,长度进行筛选过滤。

66

 

Bulk

域名注册可用状态的批量查询。 支持从文件选择打开。

可配合上面Tools中的域名组合生成器,方便进行批量可用域名的检测,也可对所需域名进行全后缀的检测,适合玩米的人士。目前几乎支持世界上全部域名后缀的查询。 (P.S. 此功能需要服务器接口支持。由于目前性能及缺少可用服务器,暂不对外开放使用。)

77

 

TLDs Server

根据 IANA 所使用的 ISO 3166-1 自动检测查询各个 通用顶级域名(gTLD)和 国家顶级域名(ccTLD)  的WHOIS服务器和注册地址,方便玩米的朋友注册,了解各域名的注册机开放信息。

88

关于

下图显示的是目前开发的最新版本,非可下载使用版本。 ( 下载:可下载使用的版本

0

 

个人使用工具,难免问题众多。有建议和问题欢迎回复及谈论。

在考虑后续增加的一些功能:域名价格列表,在线注册,抢注和会员账号等。。。

 

文件大小换算

1 Mio file = 1 mebioctet* = 220 octets = 1,024 Kio = 1,048,576 octets
10 Mio file = 10 mebioctet = 10 x 220 octets = 10,240 Kio = 10,485,760 octets
100 Mio file = 100 mebioctet = 100 x 220 octets = 102,400 Kio = 104,857,600 octets
1 Gio file = 1 gibioctet = 230 octets = 1,024 Mio = 1,073,741,824 octets
10 Gio file = 10 gibioctet = 10 x 230 octets = 10,240 Mio = 10,737,418,240 octets

1 Mbit file = 1 megabit = 106 bits = 1,000 kbit = 1,000,000 bits
10 Mbit file = 10 megabit = 107 bits = 10,000 kbit = 10,000,000 bits
100 Mbit file = 100 megabit = 108 bits = 100,000 kbit = 100,000,000 bits
1 Gbit file = 1 gigabit = 109 bits = 1,000 Mbit = 1,000,000,000 bits
10 Gbit file = 10 gigabit = 1010 bits = 10,000 Mbit = 10,000,000,000 bits