URI

定义

按 RFC 3986 的表述,URI 是由一串符合特定语法规则的字符构成的标识符,借助一组可扩展的命名方案,对资源作统一识别^[1]。规范并不限定“资源”的范围:电子文档、图片、某项稳定的信息服务、一组资源的集合都可以是资源,人、机构、图书馆里的藏书,乃至数学运算中的数值等抽象概念同样可以成为被标识的对象^[1]。

标识与访问是两件不同的事。一个 URI 只是把对象与其他事物区分开来,并不要求系统真的去取回该资源,也不保证被标识的对象在物理上是单一实体^[1]。中文语境中,该术语也常译作统一资源识别符,英文缩写统一写作 URI^[3]。

原理

通用语法把 URI 从左到右按重要性递减的顺序拆成若干成分,其基本形式可写作 $\text{URI} = \text{scheme} \text{ ":" } ["//"\ \text{authority}]\ \text{path}\ ["?"\ \text{query}]\ ["#"\ \text{fragment}]$^[1][5]。方案名以字母开头,由字母、数字、加号、减号和句点组成,决定了后续内容的解析规则与语义,因此同一套通用语法可以容纳 http、ftp、mailto、urn 等差异很大的方案^[6]。

斜杠、问号和井号分别充当路径、查询与片段的分界符,让分层结构在各类方案中保持一致;相对引用则描述引用上下文与目标之间的层级差异,由解析算法补全为绝对形式,从而使一组文档可以整体迁移而无需改写内部链接^[1]。规范把“识别”的职责交给各方案的规定,通用语法只负责可以独立于方案完成的解析,这种分工使标识体系的演进与协议、数据格式的演进相互脱钩^[1]。

URI 可用字符仅限字母、数字和少量符号,其余字符须先按 UTF-8 转成字节,再逐字节写成百分号加 2 位十六进制数的形式,即百分号编码^[7][8]。由于百分号本身是转义标志,它在数据中出现时必须写成 %25;在路径成分内部需要原义使用斜杠时,则改用 %2F^[9][10]。

flowchart LR

A[URI 字符串] --> B[scheme 方案]

A --> C[authority 授权机构]

A --> D[path 路径]

A --> E[query 查询]

A --> F[fragment 片段]

B --> G[决定解析规则与语义]

F --> H[指向资源内部位置]

发展历程

URI 与 URL 同源。1990 年蒂姆·伯纳斯-李(Tim Berners-Lee)关于超文本的构想中,出现了用一个短字符串表示超链接目标的做法,当时被称作“超文本名”或“文档名”^[2]。随着万维网、HTTP 与浏览器的普及,区分“标记资源”与“取回资源”两类字符串的条件逐渐成熟,统一资源定位符与统一资源名称两个术语先后被使用^[2]。

1994 年 6 月,互联网工程任务组(IETF)发布 RFC 1630,非正式地提出 URL 与 URN 之分,并给出“通用资源标识符”的文法框架,其中“U”当时取“通用”之义^[2]。同年 12 月的 RFC 1738 正式定义了绝对与相对 URL,URN 的文法则要到 1997 年 5 月的 RFC 2141 才统一^[2]。

1998 年 8 月发布的 RFC 2396 使 URI 文法成为独立标准,并把“U”的含义由“通用”改为“统一”;1999 年 12 月的 RFC 2732 又允许 URI 中出现 IPv6 地址^[2]。此后对旧规范的修订由罗伊·菲尔丁(Roy Fielding)等人协调推进,最终形成 2005 年 1 月发布的 RFC 3986,它同时作为 STD 66 成为现行的官方通用语法^[2]。

2002 年 8 月的 RFC 3305 已指出,“URL”在日常用语中仍被广泛使用,但作为术语已近乎被弃用,其作用仅提示某个 URI 含有指向网络可达位置的协议^[2]。2006 年 2 月的 RFC 4395 则用较长的篇幅规定了新 URI 方案的指导方针与登记程序^[2]。

应用

万维网中的网页、图片、视频、程序等资源,都依靠 URI 加以指认与定位,超链接的地址栏内容原则上都是 URI,其中带上访问协议的属于 URL^[11][12]。URL 与 URN 构成互补关系:前者相当于住址,说明怎样找到某物;后者相当于姓名,只给出身份而不涉及位置,国际标准书号即为典型的 URN 用例^[13][4]。

URI 也被用作元数据与数据结构中的通用标识。资源描述框架等标准表明,资源标识并不需要指出通过互联网获取副本的方法^[2];在 XML 命名空间中,命名空间名称必须遵守通用 URI 文法,但它通常只被看作一个形似 URI 的字符串,并不暗示对应协议的语义^[13]。国家图书馆的元数据规范同样以 URI 形式给出每个术语的唯一标识符^[14]。

HTML 表单以 GET 方式提交时,表单数据放在请求 URI 的查询成分中;以另一种媒体类型封装时,空格被写成加号而非 %20,这类细节由 HTML 与 XForms 规范另行规定^[9]。因此,凡需拼装 URI 的接口都要求对用户输入做编码,以免其中以原义出现的保留字符改变 URI 的结构^[8]。

局限

URI 本身不携带任何持久的定位保证。一个曾经指向某资源的 URI 之后未必仍然指向它,也无从保证它不会改而指向别的内容;这种保证只能由维护名称与资源的一方给出^[10]。规范同样不要求 URI 长期标识同一对象,虽然这通常是各方案追求的目标^[1]。

对中文等非 ASCII 字符的处理长期存在歧义。RFC 3986 之前的众多方案假设字符先按某种未指明的编码转成字节,若 URI 无法提示所用编码,字符串便难以可靠还原^[9]。现行规范建议新方案把非 US-ASCII 字符一律按 UTF-8 转字节后再编码,但此前的方案并不受其约束^[9]。

字符集的限制也带来互操作成本。严格合规的 URI 只能含 ASCII 字符,非 ASCII 内容必须百分号编码^[7]。此外,大众媒介常使用只写主机名与路径的缩写形式,这类写法与相对路径语法相同,不能出现在允许相对引用的位置^[10]。片段标识符的语义随媒体类型而定,方案规范无法重新定义它^[1]。

参见

• 统一资源定位符 —— URI 的下位类型,在标识资源之外还给出获取该资源的主要方式与网络位置

• 统一资源名称 —— URI 的下位类型,仅以名称空间中的名字标识资源,与位置无关

• RFC 3986 —— 规定 URI 通用语法与语义的现行标准

• 百分号编码 —— 把 URI 中不允许直接出现的字符转为百分号加十六进制数字的编码方法

• 超文本传输协议 —— 万维网上最常承载 URI 访问请求的协议