URL的主要部分
URL通常被写成如下形式：
<方案>:<方案描述部分>
一个URL包含了它使用的方案名称（<方案>）, 其后紧跟一个冒号，然后是一个字符串
（<方案描述部分>），这部分的解释由所使用的方案来决定。
方案名称由一串字符组成。小写字母“a”——“z”，数字，字符加号（“+”），句点（“.”）
和连字号（“-”）都可以。为了方便起见，程序在解释URL的时候应该视方案名称中的大
写字母和小写字母一样。（例如：视“HTTP”和“http”一样）。
2．2 URL字符编码问题
URL是由一串字符组成，这些字符可以是字母，数字和特殊符号。一个URL可以用多种方
法来表现,例如：纸上的字迹，或者是用字符集编码的八位字节序列。URL的解释仅取决
于所用字符的特性。
在大多数URL方案中，都是使用URL不同部分的字符序列来代表因特网协议中所使用的
八位字节序列。例如，在ftp方案中主机名，目录名和文件名就是这样的八位字节序列，
它们用URL的不同部分代表。在这些部分里，一个八位字节数可以用这样的字符来表示：
该字符在US—ASCII[20]编码字符集中的编码是这个八位字节数。
另外，八位字节数可以被编成如下形式的代码：“%”后加两个十六进制数字（来自于
“0123456789ABCDEF”），这两个十六进制数字代表了这八位字节数的值。(字符“abcdef”
也可以用于十六进制编码)。
如果存在下面的情况：八位字节数在US-ASCII字符集中没有相应的可显示字符，或者使
用相应字符会产生不安全因素，或者相应的字符被保留用于特定的URL方案的解释，那
么它们必须被编成代码。
没有相应的可显示字符：
URL只能用US-ASCII字符编码集中的可显示字符表示。US-ASCII中没有用到十六进制的
八位字节80-FF，并且00－1F和7F代表了控制字符，这些字符必须进行编码。
不安全：
字符不安全的原因很多。空格字符就是不安全的，因为URL在被转录或者被排版或者被
字处理程序处理后其中重要的空格可能被忽略，而可忽略的空格却有可能被解释了。“<”
和“>”字符也是不安全的，因为它们被用来作为URL在文本中的分隔符；而在有些系统
中用引号“"”来界定URL。“#”字符也是不安全的，因为它在万维网和其他一些系统中
被用来从“片段/锚点”标志符中界定URL，所以它通常都要被编码。字符“%”被用来对
其他字符进行编码，它也是不安全的。其他一些字符，如："{", "}", "|", "\", "^",
"~","[", "]",和"`"，由于网关和其他传输代理有时会对这些字符进行修改，所以它们
也是不安全的。
必须对URL中所有不安全的字符进行编码。例如，URL中的字符“#”即使是在通常不处
理片断或者锚点标志符的系统也需要进行编码，这样如果这个URL被拷贝到使用这些标
志符的系统中，也不必改变URL编码了。
保留：
许多URL方案保留了一些字符并赋予特定的含义：它们出现在URL的特定部位并表示特
定的含义。如果一个字符对应的八位字节在方案中被保留了，那么这个八位字节必须进行
编码。字符";","/", "?", ":", "@", "=" 和 "&"可能被某个方案所保留，除此之外没
有其他的保留字符。
通常情况下一个八位字节被用一个字符表示后或者被编码之后，URL的解释都是一样的。
但这对于保留字符来说就不适用了：对某一特定方案的保留字符进行编码可能会改变URL
的语义。
这样，在URL中只有字母与数字，以及特殊字符“$-_.+!*'(),”和用作保留目的的保留
字符可以不进行编码。
另一方面，不必进行编码的字符（包括字母与数字）如果出现在URL的特定部位，只要
它们不用作保留目的，则可进行编码。
2．3 分层方案和关系链接
URL有时候被用来定位那些包含指示器的资源，而这些指示器又指向其他资源。有时候这
些指示器用关系链接表示，在关系链接中第二资源的位置表示符原则上“和那些除了带有
次相关路径的表示符相同”。在这篇文档中没有对关系链接进行描述。但是，关系链接的
使用依赖于包含分层结构的原始URL，它是关系链接的基础。
有些URL方案（例如ftp，http，和文件方案）包含的名字可以被认为是分层次的；这些
层次之间用“/”分隔。
3．特殊方案
一些已经存在的标准协议和正处于试验中的协议之间的映射关系的轮廓用BNF语法定义
进行描述。下面对一些协议进行了注释：
ftp File Transfer protocol（文件传输协议）
http Hypertext Transfer Protocol（超文本传输协议）
gopher The Gopher protocol（Gopher协议）
mailto Electronic mail address（电子邮件地址）
news USENET news（USENET新闻）
nntp USENET news using NNTP access
（使用NNTP访问的USENET新闻）
telnet Reference to interactive sessions
（交互式会话访问）
wais Wide Area Information Servers（广域信息服务系统）
file Host-specific file names（特殊主机文件名）
prospero Prospero Directory Service(prospero目录服务)
在以后的说明书中可能会对其他一些方案加以描述。这篇文档的第四部分介绍了如何注册
新的方案，并且列出了一些正在研究中的方案名。
3．1通用因特网方案语法
虽然URL其他部分的语法因方案的不同而不同，但那些直接使用基于IP的协议来定位因
特网上的主机的URL方案都使用了如下形式的通用语法来表示特定的方案数据：
//<用户名>:<密码>@<主机>:<端口>/<url路径>
可能会省略“<用户名>:<密码>@”，“ :<密码>”，“ :<端口>”，和“/<url路径>”这些部
分的某些或者全部。这些方案的特定数据以双斜线“//”开头来表明它遵从通用因特网方
案语法。各个部分分别遵守如下规则：
用户名
任意的用户名称。有些方案（例如：ftp）允许使用用户名称的描述。
密码
任意的密码。如果存在的话，它紧跟在用户名后面并用一个冒号隔开。
用户名（和密码）如果存在的话，其后紧跟一个商用符号“@”。在用户名和密码字段中出
现的任何“:”，“@”或者“/”都要进行编码。
注意空的用户名或者密码不同于没有用户名和密码；决不能在没有指定用户名的情况下指
定密码。例如：<URL:ftp://@host.com/>的用户名为空并且没有密码，<
URL:ftp://host.com/>没有用户名，而<URL:ftp://foo:@host.com/>的用户名是“foo”
并且密码为空。
主机
网络主机的域名，或者它的以“.”分隔的四组十进制数字集合形式的IP地址。域名的
形式在RFC1034[13]的3.5节和RFC1123[5]的2.1节中进行了描述，即用“.”分隔的域
标志串，域标志以字母或者数字开头和结束，也可能包含“-”字符。最右边的域标志不
能以数字开头，这样就在语法结构上将域名和IP地址区分开来了。
端口
指明链接的端口。大部分方案都给协议指定一个默认的端口。也可以随意指定一个十进制
形式的端口，并用冒号与主机隔开。如果忽略端口，那么这个冒号也要忽略。
url路径
定位符的其他部分由方案的特殊数据组成，这些特殊数据被称为“url－路径”。它提供
了如何对特定资源进行访问的详细信息。注意主机（或端口）与url－路径间的“/”不
是url－路径的一部分。
url－路径的语法依赖于所使用的方案。也依赖于它在方案中的解释方法。
3．2 FTP
FTP URL方案可以用来指定因特网上使用FTP协议（RFC959）的可达主机上的文件和目录。
FTP URL遵从3.1节所描述的语法。如果:<端口>被省略的话，则使用缺省端口21。
3．2．1 FTP 用户名和密码
在连接上FTP服务器后，可以用“USER”和“PASS”命令来指定用户名和密码。如果没
有提供用户名或者密码并且FTP服务器只要求一项，那么将使用到“匿名”服务器的转
换，如下所示：
用户名“anonymous”被发送。
访问资源的终端用户的因特网电子邮件地址被作为密码发送。
如果URL提供用户名但不提供密码，那么远程服务器将要求提供密码，而解释FTP URL
的程序则要求用户输入密码。
3．2．2 FTP URL-路径
FTP URL的URL-路径语法如下：
<cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>
这里的<cwd1>到<cwdN>和<name>（可能被编码）都是字符串，<typecode>是字符“a”，
“i”和“d”之一。“;type=<typecode>”这一部分可以被省略。<cwdx>和<name>部分可
以为空。整个url－路径，包括它和包含用户名，密码，主机及端口的前缀间的分界符“/”
都可以被省略。
url－路径可以被解释成如下的一串FTP命令：
每个<cwd>元素被作为CWD（改变工作目录）命令的参数发送。
如果类型编码是“d”，则执行一个以<name>作为参数的NTLS（名字列表）命令，并把结
果解释为一个文件目录列表。
否则，执行一个用<typecode>作为参数的TYPE命令，然后访问文件名为<name>的文件（例
如，使用RETR命令）。
name或者CWD部分的字符“/”和“;”都是保留字符，必须进行编码。在FTP协议中，
这些部分在使用前被解码。特别的是，如果访问一个特定文件的适当FTP命令序列需要
发送一个包含“/”的字符串作为CWD或者RETR命令的参数，那么必须对每个“/”都进
行编码。
例如，URL<URL:ftp://myname@host.dom/%2Fetc/motd>被FTP解释为“host.dom”，并以
用户名“myname”登录（如果需要，则提示输入密码），然后执行“CWD /etc”，再接着
执行“RETR motd”。这和<URL:ftp://myname@host.dom/etc/motd>的含义不一样，它先
执行“CWD etc”然后执行“RETR motd”；开始的“CWD”可能被执行，进入用户“myname”
的缺省目录。另一方面，<URL:ftp://myname@host.dom//etc/motd>将执行一个不带参数
的“CWD”命令，然后执行“CWD etc”，接着执行“RETR moth”。
FTP URL也可以用于其他操作；例如，可以更新远程文件服务器上的文件，或者根据它的
目录列表来推断它的一些信息。完成这些功能的机制在这儿没有仔细介绍。
3．2．3 FTP 类型编码是可选择的
FTP URL的整个;type=<typecode>部分都是可选择的。如果这一部分被省略，那么解释
URL的客户程序必须猜测适当模式来使用。一般来说，文件数据内容的类型只能从文件名
来猜测，例如根据文件名后缀猜测；用来传输文件的合适的类型编码于是可以从文件的数
据内容推断出来。
3．2．4层次
在有些文件系统中，用来表示URL的层次结构的“/”与用来构建文件系统层次的分隔符
相同，这样一来，文件名和URL路径看起来就很像。但这并不意味着URL是一个Unix文
件名。
3．2．5优化
客户端通过FTP对资源进行访问时可能会使用一些额外的搜索方法来优化交互过程。例
如，对一些FTP服务器来说，当访问同一个服务器的多个URL的时候，则保持控制连接
一直打开是比较合理的。但FTP协议没有通用的层次模式，因此当一个改变目录的命令
发出后，如果是一个不同的路径，那么一般不可能推断出下一次将要给另一个目录发送什
么样的序列。唯一可靠的算法是断开然后重新建立控制连接。
3．3 HTTP
HTTP URL 方案是用来标志因特网上使用HTTP(HyperText Transfer Protocol，超文本
传输协议)的可达资源。
HTTP协议在其他的地方进行了详细说明。本文只介绍了HTTP URL的语法。
HTTP URL的形式如下：
http://<host>:<port>/<path>?<searchpart>
其中<host>和<port>已经在3.1节说明过了。如果:<port>部分省略，那么就使用缺省的
端口80。不需要用户名和密码。<path>是一个HTTP选择器，<searchpart>是查询字符串。
<path>,<searchpart>和它前面的“?”都是可选择的。如果<path>和<searchpart>部分
都没有，则“/”也可以省略。
<path>和<searchpart>部分中的“/”，“;”和“？”都是保留字符。“/”字符可以在HTTP
中用来表示层次结构。
3．4 GOPHER
Gopher URL方案用来标志因特网上使用Gopher协议的可达资源。
基本Gopher协议是在RFC1436中介绍的，它支持项和项（目录）集合。Gopher+ 协议则
在基本Gopher协议的基础上进行了扩展，并且向上兼容。[2]中对它进行了介绍。Gopher+
支持联合属性的任意集合和使用Gopher项的替换数据表示。Gopher URL提供了Gopher
与Gopher+的项和项属性。
3．4．1 Gopher URL 语法
Gopher URL的形式如下：
gopher://<host>:<port>/<gopher-path>
这里的<gopher-path>是
<gophertype><selector>
<gophertype><selector>%09<search>
<gophertype><selector>%09<search>%09<gopher+_string>
之一。
如果:<port>被省略，那么使用缺省端口70。<gophertype>是一个单字符域，它表示URL
引用的资源的Gopher类型。<gopher-path>部分也可以整个为空。在这种情况下，分隔
符“/”也是可选择的，并且<gophertype>的缺省值是“1”。
<selector>是Gopher选择器字符串。在Gopher协议中，Gopher 选择器字符串一个八位
字节串，它包括除了十六进制的09（US-ASCII HT 或tab），0A(US-ASCII 字符 LF)和
0D(US-ASCII 字符CR)外的所有八位字节。
Gopher客户通过向Gopher服务器发送Gopher选择器字符串来指定要获得的项。
<gopher-path>中没有保留字符。
需要注意的是：有些Gopher<selector>字符串是以<gophertype>字符的一个拷贝来开头，
在这种情况下，这个字符将会连续出现两次。Gopher选择器可能是空字符串；Gopher客
户端就是这样来查询Gopher服务器的高层目录的。
3．4．2为Gopher搜索引擎指定URL
如果URL被提交到Gopher搜索引擎进行查询，那么选择器后将紧跟一个已编码的tab
（%09）和一个搜索字符串。Gopher客户为了向Gopher搜索服务器提交一个搜索必须向
Gopher服务器发送<selector>字符串（编码后），一个tab字符，和一个搜索字符串。
3．4．3Gopher+项的URL语法
Gopher+项的URL有一个已编码的tab字符（%09）和一个Gopher+字符串。注意尽管
<search>元素可以是空字符串，但在这种情况下必须提供%09<search>字符串。
<gopher+_string>被用来表示取得Gopher+项所需要的信息。Gopher+项可以拥有交替视
图，任意的属性系，也可以有与它们相关联的电子表格。
客户为了获得与Gopher+URL相关联的数据，必须连接到服务器并且发送Gopher选择器，
这个选择器的后面紧跟一个tab字符和搜索字符串（可以为空）然后是一个tab字符和
Gopher+命令。
3．4．4 缺省的Gopher+数据表示
当一个Gopher服务器向客户返回目录列表时，Gopher+项后面跟着一个“+”（表示
Gopher+项）或者一个“?”（表示具有与它们相关联的+ASK形式的Gopher+项）。Gopher+
字符串只有一个字符“+”的Gopher URL采用项的缺省的视图（数据表示），而Gopher+
字符串只有一个字符“?”的Gopher URL则采用具有相关联的Gopher电子表格的项。
3．4．5 具有电子表格的Gopher+项
具有与之相关联的+ASK的Gopher+项（也就是跟着一个“?”的Gopher+项）要求客户端
取得该项的+ASK属性来获得表格定义，然后让用户填写这个表格并将用户应答和获得项
的选择器字符串一起返回。Gopher+客户端知道如何完成这些工作，但需要依赖于Gopher+
项描述中的“？”标签来知道什么时候处理这种情况。Gopher+项中的“?”被用来与Gopher+
协议中这种符号的用法相兼容
转载自：http://man.chinaunix.net/develop/rfc/RFC1738.txt
参考：http://baike.baidu.com/link?url=nBk-N7x5R5Vp5sdu0_mSYrc70uySnzXhe32eh2959ExvzkxTYtKlHLwNp3zVQNQrvDAj0sx79fd_lkTD6ej2hq
