统一资源定位符（或称统一资源定位器/定位地址、URL地址等，英语：Uniform Resource Locator，常缩写为URL），有时也被俗称为网页地址（网址）。如同在网路上的门牌，是因特网上标准的资源的地址（Address）。它最初是由蒂姆·伯纳斯-李发明用来作为万维网的地址。现在它已经被万维网联盟编制为因特网标准 RFC 1738 在网际网路的历史上，统一资源定位符的发明是一个非常基础的步骤。统一资源定位符的语法是一般的，可扩展的，它使用ASCII代码的一部分来表示因特网的地址。统一资源定位符的开始，一般会标志着一个计算机网络所使用的网络协议。 统一资源定位符的标准格式如下： 协议类型:[//服务器地址[:端口号]][/资源层级UNIX文件路径]文件名[?查询][#片段ID] 统一资源定位符的完整格式如下： 协议类型:[//[访问资源需要的凭证信息@]服务器地址[:端口号]][/资源层级UNIX文件路径]文件名[?查询][#片段ID] 其中【访问凭证信息@ :端口号 ?查询 #片段ID】都属于选填项。 语法用法 主条目：统一资源标志符 § 文法 超文本传输协议（HTTP）的统一资源定位符将从因特网获取信息的五个基本元素包括在一个简单的地址中： 1.传送协议。Data URI scheme（英语：Data URI scheme） 2.层级URL标记符号(为[//],固定不变) 3.访问资源需要的凭证信息（可省略） 4.服务器。（通常为域名，有时为IP地址） 5.端口号。（以数字方式表示，若为HTTP的预设值“:80”可省略） 6.路径。（以“/”字元区别路径中的每一个目录名称） 7.查询。（GET模式的表单参数，以“?”字元为起点，每个参数以“&”隔开，再以“=”分开参数名称与资料，通常以UTF8的URL编码，避开字元冲突的问题） 8.片段。以“#”字元为起点 以http://www.zewww.com:80/w/index.php?title=Special:%E9%9A%8F%E6%9C%BA%E9%A1%B5%E9%9D%A2 为例, 其中： 1.http，是协议； 2.www.zewww.com，是服务器； 3.80，是服务器上的网络端口号； 4./w/index.php，是路径； 5.?title=Special:%E9%9A%8F%E6%9C%BA%E9%A1%B5%E9%9D%A2，是询问。 大多数网页浏览器不要求用户输入网页中“http://”的部分，因为绝大多数网页内容是超文本传输协议文件。同样，“80”是超文本传输协议文件的常用端口号，因此一般也不必写明。一般来说用户只要键入统一资源定位符的一部分（www.zewww.com/wiki/Special:%E9%9A%8F%E6%9C%BA%E9%A1%B5%E9%9D%A2）就可以了。 由于超文本传输协议允许服务器将浏览器重定向到另一个网页地址，因此许多服务器允许用户省略网页地址中的部分，比如 www。从技术上来说这样省略后的网页地址实际上是一个不同的网页地址，浏览器本身无法决定这个新地址是否通，服务器必须完成重定向的任务。 其它使用范围 统一资源定位符不但被用作网页地址，JDBC 客户端也使用统一资源定位符连接其数据库服务器。作为对比，ODBC 的连接字符串作用相同，但并不采用 URL 格式，而是分号和等号分隔的键值对。 跳到搜索 URL方案分类图。URL(定位符)和URN(名称)方案属于URI的子类，URI可以为URL或URN两者之一或同时是URI和URN。技术上讲，URL和URN属于资源ID；但是，人们往往无法将某种方案归类于两者中的某一个：所有的URI都可被作为名称看待，而某些方案同时体现了两者中的不同部分。 在计算机术语中，统一资源标识符（英语：Uniform Resource Identifier，或URI）是一个用于标识某一互联网资源名称的字符串。 该种标识允许用户对网络中（一般指万维网）的资源通过特定的协议进行交互操作。URI的最常见的形式是统一资源定位符（URL），经常指定为非正式的网址。更罕见的用法是统一资源名称（URN），其目的是通过提供一种途径。用于在特定的名字空间资源的标识，以补充网址。 与URL和URN的关系 URI可被视为定位符（URL），名称（URN）或两者兼备。统一资源名（URN）如同一个人的名称，而统一资源定位符（URL）代表一个人的住址。换言之，URN定义某事物的身份，而URL提供查找该事物的方法。 用于标识唯一书目的ISBN系统是一个典型的URN使用范例。例如，ISBN 0-486-27557-4无二义性地标识出莎士比亚的戏剧《罗密欧与朱丽叶》的某一特定版本。为获得该资源并阅读该书，人们需要它的位置，也就是一个URL地址。在类Unix操作系统中，一个典型的URL地址可能是一个文件目录，例如file:///home/username/RomeoAndJuliet.pdf。该URL标识出存储于本地硬盘中的电子书文件。因此，URL和URN有着互补的作用。 技术观点 URL是一种URI，它标识一个互联网资源，并指定对其进行操作或获取该资源的方法。可能通过对主要访问手段的描述，也可能通过网络“位置”进行标识。例如，http://www.wikipedia.org/这个URL，标识一个特定资源（首页）并表示该资源的某种形式（例如以编码字符表示的，首页的HTML代码）是可以通过HTTP协议从www.wikipedia.org这个网络主机获得的。URN是基于某名字空间通过名称指定资源的URI。人们可以通过URN来指出某个资源，而无需指出其位置和获得方式。资源无需是基于互联网的。例如，URN urn:ISBN 0-395-36341-1 指定标识系统（即国际标准书号ISBN）和某资源在该系统中的唯一表示的URI。它可以允许人们在不指出其位置和获得方式的情况下谈论这本书。 技术刊物，特别是IETF和W3C发布的标准中，通常不再[何时？]使用“URL”这一术语，因为很少需要区别URL和URI。[1] 但是，在非技术文献和万维网软件中，URL这一术语仍被广泛使用。此外，术语“网址”（没有正式定义）在非技术文献中时常作为URL或URI的同义词出现，虽然往往其指代的只是“http”和“https”协议。 关于URI的讨论多源于题目为《W3C/IETF URI规划联合小组报告：统一标识资源符（URI），URL和统一资源名（URN）：阐明与建议》的 RFC3305 文件。这一RFC文件描述了一个，以统一W3C和IETF内部对于各种“UR*”术语之间关系的不同看法为目的而设立的，W3C/IETF联合工作小组的工作。虽然未作为标准被这两个组织所发布，但该文件确立了上述种种共识，并就此催生了许多标准的诞生。 文法 URI文法由URI协议名（例如“http”，“ftp”，“mailto”或“file”），一个冒号，和协议对应的内容所构成。特定的协议定义了协议内容的语法和语义，而所有的协议都必须遵循一定的URI文法通用规则，亦即为某些专门目的保留部分特殊字符。URI文法同时也就各种原因对协议内容加以其他的限制，例如，保证各种分层协议之间的协同性。百分号编码也为URI提供附加信息。 通用URI的格式如下： scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment] 例子 下图展示了两个 URI 例子及它们的组成部分。 hierarchical part ┌───────────────────┴─────────────────────┐ authority path ┌───────────────┴───────────────┐┌───┴────┐ abc://username:password@example.com:123/path/data?key=value&key2=value2#fragid1 └┬┘ └───────┬───────┘ └────┬────┘ └┬┘ └─────────┬─────────┘ └──┬──┘ scheme user information host port query fragment urn:example:mammal:monotreme:echidna └┬┘ └──────────────┬───────────────┘ scheme path 历史 命名、定位与标识资源 URI与URL有着共同的历史。在1990年，蒂姆·伯纳斯-李的关于超文本的提案[2] 间接地引入了使用URL作为一个表示超链接目标资源的短字符串的概念。当时，人们称之为“超文本名”[3] 或“文档名”。 在之后的三年半中，由于万维网的HTML（超文本标记语言）核心技术、HTTP与浏览器都得到了发展，区别提供资源访问和资源标记的两种字符串的必要性开始显现。虽然其时尚未被正式定义，但“统一资源定位符”这一术语开始被用于代表前者，而后者则由“统一资源名称”所表示。 在关于定义URL和URN的争论中，人们注意到两者事实上基于同一个基础的“资源标识”的概念。在1994年6月，IETF发布了Berners-Lee的RFC 1630，（非正式地）指出了URL和URN的存在，并进一步定义了“通用资源标识符”——语义和语法由具体协议规定的类URL字符串的规范文法。此外，该RFC文档亦尝试定义了其时正被使用着的URL协议的文法，同时指出（但并未标准化）了相对URL和片段标识符的存在。 标准改良 1994年12月，RFC 1738 正式定义了绝对和相对URL，改进了URL文法，定义了如何解析URL为绝对形式，并更加完善地列举了其时正处于使用中的URL协议。而URN定义和文法直到1997年5月RFC 2141公布后才正式统一。 1998年8月，随着RFC 2396的发表，URI文法形成了独立的标准[4]，同时RFC 1630和1738中关于URI和URL的许多部分也得到了修订和增补。[谁？]。新RFC修改了“URI”中“U”的含义：它开始代表统一（Uniform）而不再是通用（Universal）。RFC 1738中总结了既存URL协议的部分被移至另外一篇独立文档中。[5]IANA 保留着这些协议的注册信息[6]，而RFC 2717首次描述了注册它们的流程。 在1999年12月，RFC 2732对RFC 2396进行了小幅更新，开始允许URI包括IPv6地址。一段时间以后，在两个标准中暴露出的一些问题促使了一系列的修订草案的发展，这些草案被统称为rfc2396bis。这一由RFC 2396的共同作者Roy Fielding引导协调的集体努力，由2005年1月RFC 3986的发布推至了顶峰。该RFC文档成为了现今（2009年）于互联网上被推荐使用的URI文法版本，并使得RFC 2396成为了历史。然而，它却并未替代现有的URL协议细节；RFC 1738继续管辖着大多数协议，除了某些已被它取而代之的场合——例如被RFC 2616改良的”HTTP”协议等。与此同时，IETF发布了RFC 3986，亦即完整的STD 66标准，标识着URI通用文法正式成官方因特网协议。 在2002年8月，RFC 3305指出，虽然术语“URL”仍被广泛地用于日常用语之中，但其本身已几乎被废弃。其现在的功用，仅是作为对于某些URI因包含某种指示着网络可达性的协议而作为地址存在的提醒而已。基于URI的众多标准，例如资源描述框架等，已经清楚地表明，资源标识本无需指出通过互联网获得资源副本的方法，亦无须指出资源是否基于网络。 在2006年11月1日，W3C技术架构小组公布了《连接替代副本使查找和发布可行化》，一个对于发布给定资源的多个版本的权威URI和其最佳实践的指导。例如，内容可能因用于访问资源的设备的支持性和设定不同，而语言或大小上有所调整已适应这种差异。 语义网使用HTTP URI协议以标识文档和现实世界中的概念：这使得人们就如何区分二者产生了一些困扰。W3C技术架构小组(TAG)在2005年6月发布了一封关于如何解决这一问题的电子邮件，该邮件被称为“http范围-14 决议” 。 为了扩充这个（相当简短的）电子邮件，W3C在2008年3月发布了互联网组注释《用于语义网的酷URI》[8]。这一文档详细阐释了内容协商和303重定向码的使用。 URI引用 另一种类型的字符串——“URI引用”——代表一个URI并（相应地）代表被该URI所标识的资源。非正式使用中，URI和URI引用的区别少有被提及，但协议文档自然不应允许歧义的存在。 URI引用可取用的格式包括完整URI，URI中协议特定的部分，或其后附部分——甚至是空字符串。一个可选的片段标识符以#开头，可出现在URI引用的结尾。引用中，#之前的部分间接标识一个资源，而片段标识符则标识资源的某个部分。 为从URI引用获得URI，软件将URI引用与一个绝对“基址”基于一个固定算法合并，并转换为“绝对”形式。系统将URI引用视作相对于基址URI，虽然在绝对引用的情况下基址并无意义。基址URI一般标识包含URI引用的文档，但仍可被文档内包含的声明，或外部数据传输协议所包括的声明改写。若基址URI包括一个片段标识符，则该标识符在合并过程中被忽略。如果在URI引用中出现片段标识符，则在合并过程中被保留。 网络文档标记语言时常使用URI引用指向其它资源，如外部文档或同一逻辑文档的其他部分等。 标记语言中URI引用的使用 在HTML中，img元素的src属性值是URI引用，a或link元素的href属性值亦如是。 在XML中，在一个DTD中的SYSTEM关键字之后出现的系统描述符是一个无片段的URI引用。 在XSLT中，xsl:import元素/指令的href属性值是一个URI引用，document()函数的第一个参数与之相仿。 绝对URI的例子 http://example.org/absolute/URI/with/absolute/path/to/resource.txt ftp://example.org/resource.txt urn:issn:1535-3613 URI引用的例子 http://en.wikipedia.org/wiki/URI#Examples_of_URI_references （"http" 指定协议名, "en.wikipedia.org"是“典据”, "/wiki/URI"是指向英文维基页面的“路径”，而"#Examples_of_URI_references"是指向英文维基页面相应片段的“片段”。) http://example.org/absolute/URI/with/absolute/path/to/resource.txt //example.org/scheme-relative/URI/with/absolute/path/to/resource.txt /relative/URI/with/absolute/path/to/resource.txt relative/path/to/resource.txt ../../../resource.txt ./resource.txt#frag01 resource.txt #frag01 (空字符串) URI解析 “解析”一个URI意味着将一个相对URI引用转换为绝对形式，或者通过尝试获取一个可解引URI或一个URI引用所代表的资源来解引用这个URI。文档处理软件的“解析”部分通常同时提供这两种功能。 一个URI引用可以是一个同文档引用：一个指向包含URI引用自身的文档的引用。文档处理软件可有效地使用其当前的文档资源来完成对于同文档引用的解析而不需要重新获取一份资源。这只是一个建议——文档处理软件自然可以选用另外的方法来决定是否获取新资源。 当前截至2009 年的URI规范，RFC 3986，将一个同文档引用的URI定义为“当解析为绝对形式时与引用的基文档地址完全一致的文档”。一般来说，基文档URI就是包含引用的文档的URI。例如，XSLT 1.0包括document()函数以实现这一功能。RFC 3986同时也正式定义了URI等效性，一个可以被[谁？]用来判断一个与基URI不同的URI是否表示同一个资源，并因此可以被认为是同文档引用。 RFC 2396给出了一个不同的判断同文档引用的方法；RFC 3986替代了RFC 2396，但RFC 2396仍旧作为许多规范和实现的基础而存在。这一规范将一个空字符串或仅包括#字符和可选的片段标识符组成的URI引用定义为同文档引用。 与XML名字空间的关系 XML拥有一个叫名字空间的，一个可包含元素集和属性名称的抽象域的概念。名字空间的名称（一个必须遵守通用URI文法的字符串）用于标识一个XML名字空间。但是，名字空间的名称一般[9]不被认为是一个URI，因为URI规范定义了字符串的“URI性”是根据其目的而不是其词法组成决定的。一个名字空间名称同时也并不一定暗示任何URI协议的语义；例如，一个以“http:”开头的名字空间名称很可能与HTTP协议没有任何关系。XML专家们就这一问题在XML开发电子邮件列表上进行了深入的辩论；一部分人认为[谁？]名字空间名称可以是URI，由于包含一个具体名字空间的名称集可以被看作是一个被标识的资源，也由于“XML中的名字空间”规范的一个版本指出过名字空间名称“是”一个URI引用。[10] 但是，集体共识似乎指出一个名字空间名称只是一个凑巧看起来像URI的字符串，仅此而已。 早先，名字空间名称是可以匹配任何非空URI引用的语法的，但后来的一个对于“XML名字空间建议”的订正废弃了相对URI引用的使用。一个独立的、针对XML 1.1的名字空间的规范允许使用IRI引用作为名字空间名称的基准，而不仅是URI引用。 为了消除XML新人中产生的对于URI（尤其是HTTP URL）的使用的困惑，一个被称为RDDL（资源目录描述语言）的描述语言被创建了，虽然RDDL的规范并没有正式地位，也并没有获得任何相关组织（例如W3C）的检查和支持。一个RDDL文档可以提供关于一个特定名字空间和使用它的XML文档的，机器与人类都能读懂的信息。XML文档的作者鼓励使用RDDL文档，这样一旦文档中的名字空间名称被索引，（系统）就会获取一个RDDL文档。这样，许多开发者对于让名字空间名称指向网络可达资源的需求就能得到满足。
网友评论