RFC3986

本文的英文原文来自Uniform Resource Identifier (URI): Generic Syntax

被更新: 6874	标准
	存在勘误表
网络工作组	T. Berners-Lee
申请讨论: 3986	W3C/MIT
STD: 66	R. Fielding
更新: 1738	Day Software
取代: 2732 2396 1808	L. Masinter
类别: 标准跟踪	Adobe Systems
	2005年1月

统一资源标识符（URI）：通用语法

本文的状态

本文为互联网社区指定了一个互联网标准跟踪协议, 并为改进它而请求讨论和建议. 关于标准化状态和本协议的状态请参考当前版本的 "互联网官方协议标准" (STD 1). 本文不受限制分发.

版权声明

Copyright (C) The Internet Society (2005).

摘要

一个统一资源标识符(URI)是一个字符的紧凑序列，用来标识一个抽象或物理资源. 本协议定义了通用的URI语法和一个解析相应格式URI引用的过程, 以及在互联网上使用URIs的指南和安全事项. URI语法定义了所有合法的URIs的一个超集的语法, 允许一个实现来解析一个URI引用的常用部件而不需要知道每个可能的标识符的scheme特有的需求. 本协议不为URIs定义现成的语法; 那个任务由每个URI scheme的个体的协议来执行.

绪论

一个统一资源标识符(URI)为识别一个资源而提供一个简单的可扩展含义. 本协议的URI语法和语义衍生于万维网全局信息倡议所引入的概念, 这些标识符的使用从1990年就开始了并且在 "WWW中的统一资源标识符" RFC1630 中描述了它们. 语法的设计满足了 "互联网资源定位器功能建议" RFC1736 和 "统一资源名称功能需求" RFC1737 提出的建议.

本文取代了 RFC2396, 它融合了 "统一资源定位器" RFC1738 和 "相对统一资源定位器" RFC1808 以为所有URIs定义一个单一, 通用的语法. 它取代了 RFC2732, 该协议引入了用于IPv6地址的语法. 它排除了RFC 1738中定义了个别URI schemes的特有语法的部分; 那些部分将被更新到独立的文档中. 新URI schemes的注册过程被独立地定义在 BCP35. 给新URI schemes设计者的建议可以在 RFC2718 找到. 所有从 RFC 2396 而来的显著变更都备注在 附录D. RFC 2396以来的变更

本协议遵循 BCP19 提供的建议使用术语 "character" 和 "coded character set" , 并且以 "character encoding" 来取代 BCP19 中所指的 "charset".

URIs概述

URIs的特征如下:

统一

统一性提供了很多好处. 它允许不同类型的资源标识符被用在相同的上下文中, 即使当访问那些资源使用的机制不同的时候. 它允许跨越资源标识符的不同类型的常用语法习惯拥有统一的语义解释. 它允许引入新类型的资源标识符而不妨碍现有标识符的使用. 他允许标识符被重用于不同的上下文, 从而允许新的应用或协议支持一个早已存在的, 大的, 和广泛的资源标识符的集合.

资源

本协议不限制能成为一个资源的范围; 相反, 术语 "resource" 被用于一般意义上的任何可以由URI标识的东西. 熟悉的例子包括一个电子文档, 一个图片, 一个包含一致的目的的信息源(例如, "洛杉矶今日天气"), 一个服务(例如, 一个 HTTP 到 短信 的网关), 以及一个其他资源的集合. 通过互联网来访问一个资源不是必需的; 例如, 自然人, 组织, 以及在一个图书馆内的限定的书也可能成为资源. 同样的, 抽象概念能成为资源, 类似一个数学方程式的运算符和操作数, 关系的类型(例如, "父母" 或 "雇员"), 或数值(例如, 0, 1, 以及 无穷大).

标识符

一个标识符包含如何在身份识别的范围中从其他事物区分出被标识的事物的信息. 我们使用术语 "identify" 和 "identifying" （识别）来指代从其他资源区分出一个资源的行动, 不管那个行为是如何完成的(例如, 通过名称, 地址, 或上下文). These terms should not be

     mistaken as an assumption that an identifier defines or embodies
     the identity of what is referenced, though that may be the case
     for some identifiers.  Nor should it be assumed that a system
     using URIs will access the resource identified: in many cases,
     URIs are used to denote resources without any intention that they
     be accessed.  Likewise, the "one" resource identified might not be
     singular in nature (e.g., a resource might be a named set or a
     mapping that varies over time).

  A URI is an identifier consisting of a sequence of characters
  matching the syntax rule named <URI> in Section 3.  It enables
  uniform identification of resources via a separately defined
  extensible set of naming schemes (Section 3.1).  How that
  identification is accomplished, assigned, or enabled is delegated to
  each scheme specification.

  This specification does not place any limits on the nature of a
  resource, the reasons why an application might seek to refer to a
  resource, or the kinds of systems that might use URIs for the sake of
  identifying resources.  This specification does not require that a
  URI persists in identifying the same resource over time, though that
  is a common goal of all URI schemes.  Nevertheless, nothing in this

Berners-Lee, et al. Standards Track [Page 5]

RFC 3986 URI Generic Syntax January 2005

  specification prevents an application from limiting itself to
  particular types of resources, or to a subset of URIs that maintains
  characteristics desired by that application.

  URIs have a global scope and are interpreted consistently regardless
  of context, though the result of that interpretation may be in
  relation to the end-user's context.  For example, "http://localhost/"
  has the same interpretation for every user of that reference, even
  though the network interface corresponding to "localhost" may be
  different for each end-user: interpretation is independent of access.
  However, an action made on the basis of that reference will take
  place in relation to the end-user's context, which implies that an
  action intended to refer to a globally unique thing must use a URI
  that distinguishes that resource from all other things.  URIs that
  identify in relation to the end-user's local context should only be
  used when the context itself is a defining aspect of the resource,
  such as when an on-line help manual refers to a file on the end-
  user's file system (e.g., "file:///etc/hosts").