统一资源定位系统（uniform resource locator;URL）是因特网的万维网服务程序上用于指定信息位置的表示方法。它最初是由蒂姆·伯纳斯·李发明用来作为万维网的地址。现在它已经被万维网联盟编制为互联网标准RFC1738。

因特网上的可用资源可以用简单字符串来表示，该文档就是描述了这种字符串的语法和语义。而这些字符串则被称为：“统一资源定位器”（URL）。这篇说明源于万维网全球信息主动组织（World Wide Web global informationinitiative）介绍的概念。RFC1630《通用资源标志符》描述了一些对象数据，他们自1990年起就开始使用这些对象数据。这篇URL说明符合《因特网资源定位符的功能需求（Functional Requirements for Internet Resource Locators）》中说明的需求。这篇文档是由工程任务组织（IETF）的URI工作小组写的。

统一资源定位系统是专为标识Internet网上资源位置而设置的一种编址方式，平时所说的网页地址指的即是URL。 统一资源定位符是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示，是互联网上标准资源的地址。互联网上的每个文件都有一个唯一的URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它。

正如访问资源的方法有很多种一样，对资源进行定位的方案也有好几种。URL的一般语法只是为使用协议来建立新方案提供了一个框架，当然除了已经在这篇文档中定义过的。URL通过提供资源位置的一种抽象标志符来对资源进行定位。系统定位了一个资源后，可能会对它进行各种各样的操作，这些操作可以抽象为下面的几个词：访问，更新，替换，发现属性。一般来说，只有访问方法这一项在任何URL方案中都需要进行描述。

第一部分 模式/协议：它告诉浏览器如何处理将要打开的文件。最常用的协议是超文本传输协议（Hypertext Transfer Protocol，缩写HTTP），这个协议可以用来访问网络。

第二部分 务器的名称或IP地址，后面是到达这个文件的路径和文件本身的名称。

URL是由一串字符组成，这些字符可以是字母，数字和特殊符号。一个URL可以用多种方法来表现,例如：纸上的字迹，或者是用字符集编码的八位字节序列。URL的解释仅取决于所用字符的特性。在大多数URL方案中，都是使用URL不同部分的字符序列来代表因特网协议中所使用的八位字节序列。例如，在ftp方案中主机名，目录名和文件名就是这样的八位字节序列，它们用URL的不同部分代表。在这些部分里，一个八位字节数可以用这样的字符来表示：该字符在US—ASCII[20]编码字符集中的编码是这个八位字节数。另外，八位字节数可以被编成如下形式的代码：“%”后加两个十六进制数字（来自于“0123456789ABCDEF”），这两个十六进制数字代表了这八位字节数的值。(字符“abcdef”也可以用于十六进制编码)。如果存在下面的情况：八位字节数在US-ASCII字符集中没有相应的可显示字符，或者使用相应字符会产生不安全因素，或者相应的字符被保留用于特定的URL方案的解释，那么它们必须被编成代码。

URL有时候被用来定位那些包含指示器的资源，而这些指示器又指向其他资源。有时候这些指示器用关系链接表示，在关系链接中第二资源的位置表示符原则上“和那些除了带有次相关路径的表示符相同”。在这篇文档中没有对关系链接进行描述。但是，关系链接的使用依赖于包含分层结构的原始URL，它是关系链接的基础。有些URL方案（例如ftp，http，和文件方案）包含的名字可以被认为是分层次的；这些层次之间用“/”分隔。

1、绝对URL：URL显示文件的完整路径，这意味着绝对URL本身所在的位置与被引用的实际文件的位置无关。

2、相对URL： 相对URL以包含URL本身的文件夹的位置为参考点，描述目标文件夹的位置。如果目标文件与当前页面（也就是包含URL的页面）在同一个目录，那么这个文件的相对URL仅仅是文件名和扩展名，如果目标文件在当前目录的子目录中，那么它的相对URL是子目录名，后面是斜杠，然后是目标文件的文件名和扩展名。

一些已经存在的标准协议和正处于试验中的协议之间的映射关系的轮廓用BNF语法定义进行描述。下面对一些协议进行了注释：

在以后的说明书中可能会对其他一些方案加以描述。这篇文档的第四部分介绍了如何注册新的方案，并且列出了一些正在研究中的方案名。

虽然URL其他部分的语法因方案的不同而不同，但那些直接使用基于IP的协议来定位因特网上的主机的URL方案都使用了如下形式的通用语法来表示特定的方案数据：

//<用户名>:<密码>@<主机>:<端口>/

可能会省略“<用户名>:<密码>@”，“ :<密码>”，“ :<端口>”，和“/”这些部分的某些或者全部。这些方案的特定数据以双斜线“//”开头来表明它遵从通用因特网方案语法。各个部分分别遵守如下规则：

用户名（和密码）如果存在的话，其后紧跟一个商用符号“@”。在用户名和密码字段中出现的任何“:”，“@”或者“/”都要进行编码。注意空的用户名或者密码不同于没有用户名和密码；决不能在没有指定用户名的情况下指定密码。例如：的用户名为空并且没有密码，没有用户名，而的用户名是“foo”并且密码为空。

FTP URL方案可以用来指定因特网上使用FTP协议（RFC959）的可达主机上的文件和目录。FTP URL遵从3.1节所描述的语法。如果:<端口>被省略的话，则使用缺省端口21。

1、FTP 用户名和密码

在连接上FTP服务器后，可以用“USER”和“PASS”命令来指定用户名和密码。如果没有提供用户名或者密码并且FTP服务器只要求一项，那么将使用到“匿名”服务器的转换，如下所示：用户名“anonymous”被发送。访问资源的终端用户的因特网电子邮件地址被作为密码发送。如果URL提供用户名但不提供密码，那么远程服务器将要求提供密码，而解释FTP URL的程序则要求用户输入密码。

2、FTP URL-路径FTP URL的URL-路径语法如下：

这里的到和（可能被编码）都是字符串，是字符“a”，“i”和“d”之一。“;type=”这一部分可以被省略。和部分可以为空。整个url－路径，包括它和包含用户名，密码，主机及端口的前缀间的分界符“/”都可以被省略。url－路径可以被解释成如下的一串FTP命令：每个元素被作为CWD（改变工作目录）命令的参数发送。如果类型编码是“d”，则执行一个以作为参数的NTLS（名字列表）命令，并把结果解释为一个文件目录列表。否则，执行一个用作为参数的TYPE命令，然后访问文件名为的文件（例如，使用RETR命令）。name或者CWD部分的字符“/”和“;”都是保留字符，必须进行编码。在FTP协议中，这些部分在使用前被解码。特别的是，如果访问一个特定文件的适当FTP命令序列需要发送一个包含“/”的字符串作为CWD或者RETR命令的参数，那么必须对每个“/”都进行编码。例如，URL被FTP解释为“host.dom”，并以用户名“myname”登录（如果需要，则提示输入密码），然后执行“CWD /etc”，再接着执行“RETR motd”。这和的含义不一样，它先执行“CWD etc”然后执行“RETR motd”；开始的“CWD”可能被执行，进入用户“myname”的缺省目录。另一方面，将执行一个不带参数的“CW D”命令，然后执行“CWD etc”，接着执行“RETR moth”。FTP URL也可以用于其他操作；例如，可以更新远程文件服务器上的文件，或者根据它的目录列表来推断它的一些信息。完成这些功能的机制在这儿没有仔细介绍。

3、 FTP 类型编码是可选择的

FTP URL的整个;type=部分都是可选择的。如果这一部分被省略，那么解释URL的客户程序必须猜测适当模式来使用。一般来说，文件数据内容的类型只能从文件名来猜测，例如根据文件名后缀猜测；用来传输文件的合适的类型编码于是可以从文件的数据内容推断出来。

4、层次

在有些文件系统中，用来表示URL的层次结构的“/”与用来构建文件系统层次的分隔符相同，这样一来，文件名和URL路径看起来就很像。但这并不意味着URL是一个Unix文件名。

5、优化

客户端通过FTP对资源进行访问时可能会使用一些额外的搜索方法来优化交互过程。例如，对一些FTP服务器来说，当访问同一个服务器的多个URL的时候，则保持控制连接一直打开是比较合理的。但FTP协议没有通用的层次模式，因此当一个改变目录的命令发出后，如果是一个不同的路径，那么一般不可能推断出下一次将要给另一个目录发送什么样的序列。唯一可靠的算法是断开然后重新建立控制连接。

HTTP URL 方案是用来标志因特网上使用HTTP(HyperText Transfer Protocol，超文本传输协议)的可达资源。HTTP协议在其他的地方进行了详细说明。本文只介绍了HTTP URL的语法。HTTP URL的形式如下：

http://:/?

其中和已经在3.1节说明过了。如果:部分省略，那么就使用缺省的端口80。不需要用户名和密码。是一个HTTP选择器，是查询字符串。,和它前面的“?”都是可选择的。如果和部分都没有，则“/”也可以省略。和部分中的“/”，“;”和 “？”都是保留字符。“/”字符可以在HTTP中用来表示层次结构。

Gopher URL方案用来标志因特网上使用Gopher协议的可达资源。基本Gopher协议是在RFC1436中介绍的，它支持项和项（目录）集合。Gopher+ 协议则在基本Gopher协议的基础上进行了扩展，并且向上兼容。中对它进行了介绍。Gopher+支持联合属性的任意集合和使用Gopher项的替换数据表示。Gopher URL提供了Gopher与Gopher+的项和项属性。

1、Gopher URL 语法

Gopher URL的形式如下：

gopher://:/

这里的是%09%09%09之一。

如果:被省略，那么使用缺省端口70。是一个单字符域，它表示URL引用的资源的Gopher类型。部分也可以整个为空。在这种情况下，分隔符“/”也是可选择的，并且的缺省值是“1”。是Gopher选择器字符串。在Gopher协议中，Gopher 选择器字符串一个八位字节串，它包括除了十六进制的09（US-ASCII HT 或tab），0A(US-ASCII 字符 LF)和0D(US-ASCII 字符CR)外的所有八位字节。Gopher客户通过向Gopher服务器发送Gopher选择器字符串来指定要获得的项。中没有保留字符。需要注意的是：有些Gopher字符串是以字符的一个拷贝来开头，在这种情况下，这个字符将会连续出现两次。Gopher选择器可能是空字符串；Gopher客户端就是这样来查询Gopher服务器的高层目录的。

2、为Gopher搜索引擎指定URL

如果URL被提交到Gopher搜索引擎进行查询，那么选择器后将紧跟一个已编码的tab（%09）和一个搜索字符串。Gopher客户为了向Gopher搜索服务器提交一个搜索必须向Gopher服务器发送字符串（编码后），一个tab字符，和一个搜索字符串。

3、Gopher+项的URL语法

Gopher+项的URL有一个已编码的tab字符（%09）和一个Gopher+字符串。注意尽管元素可以是空字符串，但在这种情况下必须提供%09字符串。被用来表示取得Gopher+项所需要的信息。Gopher+项可以拥有交替视图，任意的属性系，也可以有与它们相关联的电子表格。客户为了获得与Gopher+URL相关联的数据，必须连接到服务器并且发送Gopher选择器，这个选择器的后面紧跟一个tab字符和搜索字符串（可以为空）然后是一个tab字符和Gopher+命令。

4 、缺省的Gopher+数据表示

当一个Gopher服务器向客户返回目录列表时，Gopher+项后面跟着一个“+”（表示Gopher+项）或者一个“?”（表示具有与它们相关联的+ASK形式的Gopher+项）。Gopher+字符串只有一个字符“+”的Gopher URL采用项的缺省的视图（数据表示），而Gopher+字符串只有一个字符“?”的Gopher URL则采用具有相关联的Gopher电子表格的项。

5 、具有电子表格的Gopher+项

具有与之相关联的+ASK的Gopher+项（也就是跟着一个“?”的Gopher+项）要求客户端取得该项的+ASK属性来获得表格定义，然后让用户填写这个表格并将用户应答和获得项的选择器字符串一起返回。Gopher+客户端知道如何完成这些工作，但需要依赖于Gopher+项描述中的“？”标签来知道什么时候处理这种情况。Gopher+项中的“?”被用来与Gopher+协议中这种符号的用法相兼容。

6 、Gopher+项属性集

为了表示项的Gopher+属性，Gopher URL的Gopher+字符串由“!”或者“$”组成。“!”涉及Gopher+项的所有属性。“$”则涉及Gopher目录中所有项的所有项属性。

7、涉及特定的Gopher+属性

为了表示特殊的属性，URL的gopher+_string是“!”或者“$”。例如，gopher+_string的值为“!+ABSTRACT” 表示属性包含一个项的抽象。为了表示几个属性，gopher+_string可以由几个属性名组成，并且用已编码的空格分隔开。例如，“!+ABSTRACT%20+SMELL”代表一个项的+ABSTRACT和+SMELL属性。

8、Gopher+交替视图的URL语法

Gopher+允许项有优化的交替数据表示(交替视图)。Gopher+客户端发送适当的视图和语言标志（出现在项的+VIEW属性里）来获得Gopher+的交替视图。为了引用一个特定的Gopher+交替视图试图，URL的Gopher+字符串的形式必须如下所示：

+<视图名称>%20<语言名称>

9、 Gopher+电子表格的URL语法

一个引用了填充有特定数据的Gopher+电子表格（一个ASK块）所参考的项的URL的Gopher+字符串是通过对客户送给服务器的gopher+字符串进行编码得到的。这个gopher+字符串的形式如下所示：

+%091%0D%0A+-1%0D%0A%0D%0A%0D%0A.%0D%0A

Gopher客户端为了获得这个项，它发送如下信息给Gopher服务器：

mailto URL方案是用来指明一个个体或者服务的因特网邮件地址的。它只代表因特网邮件地址，而不表示任何其它的附加信息。Mailto URL的形式如下所示：

mailto:

新闻URL方案被用来查阅新闻组或者USENET新闻上的独立文章，这一点在RFC1036中详细说明了。新闻URL的形式是下面两个之一：

news:

news:

是一个用句点分隔的层次名称，例如：“comp.infosystems.www.misc”。与RFC1036中的2.1.5节中的Message-ID一样，只是后者没有用“<”和“>”括起来；它的形式如下@。消息标志符通过代表“在（at）”的“@”字符和新闻组名称相区分。除此之外，在新闻URL组件中没有其它的保留字符。如果是“*”（例如：），那么它表示“所有可用的新闻组”。新闻URL是不同寻常的，因为它们自身不包含足够的信息来定位一个单一资源，但是它们的位置是任意的。

（Network News Transfer Protocol,网络新闻传输协议）URL方案是引用新闻文章的另一个方法，这个方案在用来从NNTP服务器指定新闻文章时是非常有用的（RFC977）。网络新闻传输协议URL的形式如下：

nntp://://

这里的和在3.1节进行了阐述。如果省略:，那么端口缺省为119。是组名，是新闻组中文章的数字编号。注意nntp:URL指定了文章资源的一个唯一的位置，大多数因特网上的NNTP服务器目前进行的配置只允许本地客户端访问，因此nntp URL并不代表全球可访问的资源。这样URL的news:形式成为标志新闻文章的首选方法。

远程登录URL方案被用来指明交互式服务，这种服务可以通过Telnet协议来进行访问。telnet URL的形式如下：

telnet://:@:/

向3.1节所讲的那样，最后面的“/”字符可以被省略。如果:被省略，那么端口缺省为23。:也可以被省略，:部分也可以整个被省略。这个URL并不指定一个数据对象，而是指定一个交互式的服务。远程交互式服务在允许远程登录的方法上差别很大。实际上，提供的和仅供参考：正在访问一个telnet URL的客户端仅仅建议所暗示的用户名和密码的用户。

（Wide Area Information Servers,广域信息服务系统）WAIS URL 方案用来指示WAIS数据库，搜索或者WAIS数据库中可用的单个文档。WAIS在中进行了描述。RFC1625[17]对WAIS协议进行了阐述。虽然WAIS协议是基于Z39.50-1988的，但 WAIS URL方案并不是特意用来和任意的Z39.50服务一起使用的。WAIS URL有如下几个形式：

wais://:/

wais://:/?

wais://:///

这里的和在3.1节阐述过了。如果省略了:，那么端口缺省为210。第一种形式指定了一个可以用来搜索的WAIS服务器。第二种形式表明了一个特定的搜索。是被查询的WAIS数据库名。第三种形式表明了WAIS数据中的一个要获取的特定文档。在这种形式中是对象类型的WAIS表示。许多WAIS实现需要一个在取得信息之间就能够认识对象“类型”的客户端，这个类型和搜索响应中的内部对象标志符一起返回。包含在URL中，这是为了让客户端能理解URL的足够信息来取得文档。WAIS URL的由WAIS文档标志组成，这个文档标志使用了2.2节所叙述的方法进行编码。WAIS 文档标志在处理时应该是不透明的；它仅可以被发布它的服务器分解。

文件URL方案被用来指定那些特定主机上的可访问的文件。这个方案和其它大多数方案不一样，因为它并不表示一个在因特网上普遍可访问的资源。文件URL的形式如下：

file:///

这里的是系统域名的全称，在这个系统中是可访问的，它是形如/ /.../的层次目录。例如，一个VMS文件：DISK:[MY.NOTES]NOTE123456.TXT的形式如下：

有一种特殊情况，就是可以是字符串“localhost”或者空字符串；它被解释为解释这个URL的主机。

文件URL方案是与众不同的，因为它不指定一个因特网协议或者访问这些文件的方法；这样它在主机间网络协议上的效用是有限的。

Prospero URL方案是用来指定那些可以通过Prospero目录服务访问的资源。Prospero协议在其它地方介绍了。Prospero URL的形式如下：

prospero://:/;=

这里和和3.1节介绍的一样。如果省略了:，那么端口缺省为1525。这里不需要用户名和密码。是Prospero协议中特定主机的对象名称，它需要被编码。这个名称是不透明的，它是由Prospero服务器解释。分号“;”是保留字符，它不能不经过引用就出现在中.Prospero URL是通过联系特定主机和端口上的Prospero目录服务器来解释的，然后用来决定访问资源的合适的方法，这些资源自身可能被表示成不同的URL。外部的Prospero链接被表示成采用底层访问方法的URL，而不是表示成Prospero URL。注意斜线“/”可以不经过引用就出现在中，应用程序假定它不代表任何意义。尽管斜线在服务器上可以用来表示层次结构，但是这些结构并不被承认。注意许多是由斜线开头，在这种情况下，主机或者端口之后将紧跟一个双斜线：前面是URL语法的斜线，后面是的开始斜线。（举例来说：表示为“/pros/name”）。另外，与Prospero链接相关联的任意的字段和值都可以成为URL中之后的一个部分。在这种情况下，每个“字段/值”组合对都用一“;”（分号）相互以及与URL的其它部分分隔开。字段名称和它的值用一个“=”（等号）分隔开。如果出现这种情况，这些域将用来标志URL的目标。例如，OBJECT-VERSION域可以被用来标志对象的特定版本。

可以通过定义一个到相应URL语法的映射和使用一个新的前缀来引入一个新的方案。URL试验方案可以通过团体间的共同协议来使用。用字符“x-”开头的方案名称是保留给试验方案用的。国际数字分配权威（IANA，Internet Assigned Numbers Authority）将管理URL方案的注册。任何提交的新URL方案都必须包含一个访问该方案中资源的法则的定义还必须包含描述这个方案的语法。URL方案必须具有可论证的实用性和可操作性。提供这样一个示范的方法就是借助一个为使用已有协议的客户端提供新方案中的对象的网关。如果新方案不能够定位一个数据对象资源，那么这个新领域中的名称的属性必须要进行清晰的定义。新方案应该在适当的地方努力遵从与已有方案相同的语法规则。对于可以用URL访问的协议的地方也是同样的。客户端软件被规定配置成使用特定网关定位符来通过新的命名方案间接访问。下面的方案已经多次被提议，但这个文档没有定义它自己的语法。它建议IANA保留它们的方案名以备将来定义：

afs Andrew 文件系统全局文件名（Andrew File System global file names）。

mid 电子邮件报文标志（Message identifiers for electronic mail）.

cid MIME主体部分的内容标志符（ Content identifiers for MIME body

parts）.

nfs 网络文件系统（NFS）文件名（Network File System file names）.

tn3270 交互式3270竞争会话(Interactive 3270 emulation sessions).

mailserver 访问邮件服务器上的有效数据（Access to data available from mail

servers）.

z39.50 访问ANSI Z39.50服务(Access to ANSI Z39.50 services).

这是统一资源定位器语法的类BNF描述，它使用了RFC822中的约定，除了用“|”表示

来，可选元素放在方括号[]内，元素可以用*来开头表明有n个或者更多个此元素；n

缺省为0。

;URL的一般形式如下：

;特定的预定义方案在这里进行定义；新方案可以在IANA那儿注册

url = httpurl | ftpurl | newsurl |

nntpurl | telneturl | gopherurl |

waisurl | mailtourl | fileurl |

prosperourl | otherurl

;新方案遵从一般语法

otherurl = genericurl

;方案都是小写的；解释程序应该忽略大小写

schemepart = *xchar | ip-schemepart

;基于协议的ip的URL方案部分：

host = hostname | hostnumber

alphadigit = alpha | digit

port = digits

urlpath = *xchar ;建立在3.1节的协议基础上

;预定义方案：

;FTP(文件传输协议，请参考RFC959)

;FILE(文件)

;HTTP(超文本传输协议)

;GOPHER(请参考RFC1436)

gtype = xchar

selector = *xchar

gopher+_string = *xchar

;MAILTO(请参考RFC822)

encoded822addr = 1*xchar ;在RFC822中进一步定义了

;NEWS（新闻,请参考RFC1036）

;NNTP（网络新闻传输协议,请参考RFC977）

;TELNET(远程登录协议)

;WAIS(广域信息服务系统，请参考RFC1625)

waisurl = waisdatabase | waisindex | waisdoc

database = *uchar

wtype = *uchar

wpath = *uchar

;PROSPERO

其他的定义

alpha = lowalpha | hialpha

unreserved = alpha | digit | safe | extra

uchar = unreserved | escape

xchar = unreserved | reserved | escape

digits = 1*digit

URL方案自身并不会造成安全威胁。用户需要小心的是：在一个时刻指向一个给定对象的URL并不会保证一直指向这个对象。甚至也不保证因服务器上对象的移动而会在后来指向另一个不同的对象。一种同URL相关的安全威胁是：构建一个试图执行像取回对象这样无害的等幂操作的URL有时可能会导致发生破坏性的远程操作。这个不安全的URL通常是通过指定一个除了那些保留给正在讨论的网络协议用的端口数产生的。客户端在无意间同一个服务器打了交道，而这个服务器实际上正在运行一个不同的协议，这样就导致URL内容中包含的指令被其他的协议解释了，从而产生意外操作。一个例子就是使用gopher URL来生成一个原始的消息并通过SMTP服务器来发送。在使用那些指定端口不是缺省端口的URL时应该进行警告，尤其是在这个端口数出现在保留空间里面的情况下。当URL包含有嵌入式已编码的特定协议中的分隔符（例如，telnet协议的CR和LF字符）并且在传输前没有被解码时应该引起注意。这样除了可能被用来模拟一个超出其范围的操作或者参数，会干扰这个协议，并再一次引起执行意想不到的而且可能是有害的远程操作。使用包含应该作为秘密的密码的URL是非常轻率的。