URI

RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax

统一资源标识符（URI）提供了一种简单且可扩展的方式来标识资源。URI语法和语义的规范源自万维网全球信息倡议提出的概念，该概念的使用始于1990年，并在“ WWW中的通用资源标识符”中进行了描述[RFC1630]。

本文档更新并合并了“统一资源定位符” [RFC1738]和“相对统一资源定位符” [RFC1808]，以便为所有URI定义单一的通用语法。它排除了RFC 1738中定义了各个URL方案的特定语法的那些部分；这些部分将作为单独的文档进行更新，将注册新URI方案的过程。本文档不讨论处理US-ASCII字符集[ASCII]以外的字符的问题和建议；这些建议将在单独的文档中进行讨论。

定义

统一

统一提供了许多好处：即使在机制不同的情况下，它也允许在同一上下文中使用不同类型的资源标识符。用于访问这些资源的方式可能有所不同；它允许跨不同类型的资源标识符对通用语法约定进行统一的语义解释；它允许引入新类型的资源标识符，而不会干扰使用现有标识符的方式；并且，它允许标识符在许多不同的上下文中被重用，从而允许新的应用程序或协议利用现有的，大型的和广泛使用的资源标识符集。

资源

资源可以是具有身份的任何东西。熟悉的示例包括电子文档，图像，服务（例如“今天的洛杉矶天气报告”）以及其他资源的集合。并非所有资源都是网络“可检索”的；例如，人类，公司和图书馆中的绑定书也可以视为资源。

资源是到一个实体或一组实体的概念性映射，不一定是在任何特定时间点对应于该映射的实体。因此，即使概念的映射在过程中不发生变化，即使资源的内容（当前与之相对应的实体）随时间变化，该资源也可以保持不变。

识别码

标识符是可以用作对具有身份的事物的引用的对象。对于URI，对象是具有受限语法的字符序列。

标识了资源后，系统可以对该资源执行各种操作，其特征可能在于“访问”，“更新”，“替换”或“查找属性”。

URI，URL和URN

URI 可以进一步分类为定位符，名称或两者。
URL通过主要访问权限机制的表达（例如，网络的“location”）来识别资源，而不是按名称或该资源的某些其他属性。
URN必须保持全局唯一性和持久性，即使该资源不再存在或变得不可用。

许多 URL 方案都是以协议号开头的，但并不意味着使用协议获取资源（例如，在本地缓存找不到访问“http”的URL资源时，将同时使用DNS和HTTP来获取）

分层URI和相对形式

absolute URI 描述标识所在 context 的资源；相反 ，related URI 只用描述当前 context 与资源的差别。

分层 URI 中名称的层次结构由“/”定界符表示

相对 URI

URI的相对寻址允许文档树部分独立于其位置和访问方案。例如，如果文档使用相对 URI 相互引用，则可以通过 “文件”，“ http” 和 “ ftp” 方案中的每个方案同时访问和遍历单个超文本文档集。此外，这样的文档树可以整体移动，而无需更改任何相对引用。 WWW 中的经验表明，执行相对引用的功能对于嵌入式URI的长期可用性是必需的。

有必要在之前加上其他句段（例如“ ./this:that”），以便将其引用为相对路径。

只有其 base URI 符合 <hier_part> 语法的文件，才能使用相对 URI。

URI 句法成分

<scheme>://<authority><path>?<query>

除了 scheme，其他都可以缺失。例如，有些URI方案不允许使用<authority>组件，有些不使用<query>组件。

scheme        = alpha *( alpha | digit | "+" | "-" | "." )

authority     = server | reg_name
	
	server：<userinfo>@<host>:<port>	注："<userinfo>@" 和 ":<port>" 可能省略
	
	reg_name      = 1*( unreserved | escaped | "$" | "," |
                      ";" | ":" | "@" | "&" | "=" | "+" )

path          = [ abs_path | opaque_part ]

query         = *uric

Fragment 标识符

当 URI 用来对标识的资源进行检索，可使用可选的 Fragment 标识符附加参考信息（通常使数据的一个属性）给用户代理器来解释数据，Fragment 使用井号（“＃”）字符分割，这不是 URI 的一部分，但通常与 URI 结合使用。

fragment      = *uric

Fragment 标识符只有在 URI 检索的结果是一个对 Fragment 进行了一致定义的文档时才有效。

使用正则表达式解析URI引用

绝对URI

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
 一二          三 四         五      六 七       八 九

示例：

http://www.ics.uci.edu/pub/ietf/uri/#Related

匹配导致以下子表达式：
$1 = http:
$2 = http
$3 = //www.ics.uci.edu
$4 = www.ics.uci.edu
$5 = /pub/ietf/uri/
$6 = <undefined>
$7 = <undefined>
$8 = #Related
$9 = Related

其中<undefined>表示该组件不存在，即示例中查询组件的情况。

四个组件和片段的值可以从中确认：
scheme    = $2
authority = $4
path      = $5
query     = $7
fragment  = $9

解析相对 URI

  http://a/b/c/d;p?q

在具有明确定义的 base URI（定义见上）的对象内，相对 URI 的解析如下：

正常例子

  g:h           =  g:h
  g             =  http://a/b/c/g
  ./g           =  http://a/b/c/g
  g/            =  http://a/b/c/g/
  /g            =  http://a/g
  //g           =  http://g
  ?y            =  http://a/b/c/?y
  g?y           =  http://a/b/c/g?y
  #s            =  (current document)#s
  g#s           =  http://a/b/c/g#s
  g?y#s         =  http://a/b/c/g?y#s
  ;x            =  http://a/b/c/;x
  g;x           =  http://a/b/c/g;x
  g;x?y#s       =  http://a/b/c/g;x?y#s
  .             =  http://a/b/c/
  ./            =  http://a/b/c/
  ..            =  http://a/b/
  ../           =  http://a/b/
  ../g          =  http://a/b/g
  ../..         =  http://a/
  ../../        =  http://a/
  ../../g       =  http://a/g

异常例子

尽管异常例子不常见，所有 URI 解析器也应该能够正确解析它们。

空引用是指当前文档的开头：

  <>            =  (current document)

处理“…”段多于相对 URI 的结构层次时，不能超出 authority component 范围：

  ../../../g    =  http://a/../g
  ../../../../g =  http://a/../../g

实践中，一些实现会对相对 URI 计算后剥除多余 (".", “…”) 符号，来杜绝此种请求失败，将以上引用解释为 “http://a/g”。

当 “.” 和 “…” 不是相对路径上的组件时，解析器不应该将其视为保留字符：

  /./g          =  http://a/./g
  /../g         =  http://a/../g
  g.            =  http://a/b/c/g.
  .g            =  http://a/b/c/.g
  g..           =  http://a/b/c/g..
  ..g           =  http://a/b/c/..g

相对 URI 使用不必要的或荒谬的 “.” 和 “…” 路径形式情况比较少见：

  ./../g        =  http://a/b/g
  ./g/.         =  http://a/b/c/g/
  g/./h         =  http://a/b/c/g/h
  g/../h        =  http://a/b/c/h
  g;x=1/./y     =  http://a/b/c/g;x=1/y
  g;x=1/../y    =  http://a/b/c/y

所有客户端应用程序在解析相对 URI 之前都将 query component 从基本 URI 中删除。但是，某些应用程序却没将相对路径的 query and/or fragment component 分离，再将其与基本路径合并。因为 fragment 的典型用法永远不会包含层次结构（“ /”）字符，并且 query component 不常在相对应用中使用，所以这个错误很少被注意到：

  g?y/./x       =  http://a/b/c/g?y/./x
  g?y/../x      =  http://a/b/c/g?y/../x
  g#s/./x       =  http://a/b/c/g#s/./x
  g#s/../x      =  http://a/b/c/g#s/../x

一些解析器允许与 base URI 的 scheme 相同的名称出现在相对 URI 中。这在部分的 URI [RFC1630] 中被任务时早前规范的漏洞，应该被避免：

  http:g        =  http:g           ; 新的验证解析
                |  http://a/b/c/g   ; 向后兼容

将基本 URI 嵌入 HTML 文档中

HTML 定义一个特殊元素 “BASE”，作为 “HEAD” 文件的一部分，表示解析器应使用的 BASE 元素的 “HREF” 属性作为 base URI 来解析任何相对 URI。“HREF” 属性必须是绝对URI。

示例：

  <!doctype html public "-//IETF//DTD HTML//EN">
  <HTML><HEAD>
  <TITLE>An example HTML document</TITLE>
  <BASE href="http://www.ics.uci.edu/Test/a/b/c">
  </HEAD><BODY>
  ... <A href="../x">a hypertext anchor</A> ...
  </BODY></HTML>

当读文档时遇到相对 URI “…/x”，无论获取示例文档的上下文如何，解析器都会解释成以下绝对 URI：

  <http://www.ics.uci.edu/Test/a/x>