更新时间：2024-04-17 15:52
统一资源定位系统（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方案都使用了如下形式的通用语法来表示特定的方案数据：
//<用户名>:<密码>@<主机>:<端口>/
可能会省略“<用户名>:<密码>@”，“ :<密码>”，“ :<端口>”，和“/
用户名（和密码）如果存在的话，其后紧跟一个商用符号“@”。在用户名和密码字段中出现的任何“:”，“@”或者“/”都要进行编码。注意空的用户名或者密码不同于没有用户名和密码；决不能在没有指定用户名的情况下指定密码。例如：
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-路径语法如下：
这里的
3、 FTP 类型编码是可选择的
FTP URL的整个;type=
4、层次
在有些文件系统中，用来表示URL的层次结构的“/”与用来构建文件系统层次的分隔符相同，这样一来，文件名和URL路径看起来就很像。但这并不意味着URL是一个Unix文件名。
5、优化
客户端通过FTP对资源进行访问时可能会使用一些额外的搜索方法来优化交互过程。例如，对一些FTP服务器来说，当访问同一个服务器的多个URL的时候，则保持控制连接一直打开是比较合理的。但FTP协议没有通用的层次模式，因此当一个改变目录的命令发出后，如果是一个不同的路径，那么一般不可能推断出下一次将要给另一个目录发送什么样的序列。唯一可靠的算法是断开然后重新建立控制连接。
HTTP URL 方案是用来标志因特网上使用HTTP(HyperText Transfer Protocol，超文本传输协议)的可达资源。HTTP协议在其他的地方进行了详细说明。本文只介绍了HTTP URL的语法。HTTP URL的形式如下：
http://
其中
Gopher URL方案用来标志因特网上使用Gopher协议的可达资源。基本Gopher协议是在RFC1436中介绍的，它支持项和项（目录）集合。Gopher+ 协议则在基本Gopher协议的基础上进行了扩展，并且向上兼容。中对它进行了介绍。Gopher+支持联合属性的任意集合和使用Gopher项的替换数据表示。Gopher URL提供了Gopher与Gopher+的项和项属性。
1、Gopher URL 语法
Gopher URL的形式如下：
gopher://
这里的
如果:
2、为Gopher搜索引擎指定URL
如果URL被提交到Gopher搜索引擎进行查询，那么选择器后将紧跟一个已编码的tab（%09）和一个搜索字符串。Gopher客户为了向Gopher搜索服务器提交一个搜索必须向Gopher服务器发送
3、Gopher+项的URL语法
Gopher+项的URL有一个已编码的tab字符（%09）和一个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是“!
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
Gopher客户端为了获得这个项，它发送如下信息给Gopher服务器：
mailto URL方案是用来指明一个个体或者服务的因特网邮件地址的。它只代表因特网邮件地址，而不表示任何其它的附加信息。Mailto URL的形式如下所示：
mailto:
新闻URL方案被用来查阅新闻组或者USENET新闻上的独立文章，这一点在RFC1036中详细说明了。新闻URL的形式是下面两个之一：
news:
news:
是一个用句点分隔的层次名称，例如：“comp.infosystems.www.misc”。
（Network News Transfer Protocol,网络新闻传输协议）URL方案是引用新闻文章的另一个方法，这个方案在用来从NNTP服务器指定新闻文章时是非常有用的（RFC977）。网络新闻传输协议URL的形式如下：
nntp://
这里的
远程登录URL方案被用来指明交互式服务，这种服务可以通过Telnet协议来进行访问。telnet URL的形式如下：
telnet://
向3.1节所讲的那样，最后面的“/”字符可以被省略。如果:
（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://
这里的
文件URL方案被用来指定那些特定主机上的可访问的文件。这个方案和其它大多数方案不一样，因为它并不表示一个在因特网上普遍可访问的资源。文件URL的形式如下：
file://
这里的
有一种特殊情况，就是
文件URL方案是与众不同的，因为它不指定一个因特网协议或者访问这些文件的方法；这样它在主机间网络协议上的效用是有限的。
Prospero URL方案是用来指定那些可以通过Prospero目录服务访问的资源。Prospero协议在其它地方介绍了。Prospero URL的形式如下：
prospero://
这里
可以通过定义一个到相应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中的约定，除了用“|”表示
来，可选元素放在方括号[]内，元素可以用
缺省为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是非常轻率的。