RFC双语计划：rfc1738中文版(中英文对照)............统一资源定位器（URL）

RFC双语计划：rfc1738中文版(中英文对照)............统一资源定位器（URL）
http://kummerwu.web.officelive.com/Documents/rfc1738-0.html

更多RFC中文版，中英文对照版，请查阅http://kummerwu.web.officelive.com/Documents/index.html

这儿目前收录来OSPF，BGP，RIP，MPLS(VPN)、HTTP，Telnet,RSVP，PPP，POP3，RTP，NAT，FTP等最新RFC中文版和中英文对照版。而且内容还在不断更新中......
------------------------------------------------------------------------

统一资源定位器（URL）
这份备忘录的情况
本备忘录详细说明了一种为因特网团体提供的因特网标准追踪协议（track protocol），恳请大家讨论并提出宝贵意见。如果你想了解这个协议的情况及标准化状态，请参考《因特网正式协议标准（Internet Official Protocol Standards）》（STD 1）的最新版本。本备忘录可以自由发布发布，不受任何限制。
摘要
该文档详细说明了统一资源定位器、定位的语法和语义以及如何通过因特网来访问资源。
1．绪论
因特网上的可用资源可以用简单字符串来表示，该文档就是描述了这种字符串的语法和语义。而这些字符串则被称为：“统一资源定位器”（URL）。
这篇说明源于万维网全球信息主动组织（World Wide Web global information initiative）介绍的概念。RFC1630《通用资源标志符》描述了一些对象数据，他们自1990年起就开始使用这些对象数据。这篇URL说明符合《因特网资源定位符的功能需求（Functional Requirements for Internet Resource Locators）》[12]中说明的需求。
这篇文档是由工程任务组织（IETF）的URI工作小组写的。如果你有什么建议和意见的话，你可以给编辑或者URI工作小组< uri@bunyip.com>写信.这个小组的讨论档案存放在URL:http://www.acl.lanl.gov/URI/archive/uri-archive.index.html。
2．常规URL语法
正如访问资源的方法有很多种一样，对资源进行定位的方案也有好几种。
URL的一般语法只是为使用协议来建立新方案提供了一个框架，当然除了已经在这篇文档中定义过的。
URL通过提供资源位置的一种抽象标志符来对资源进行定位。系统定位了一个资源后，可能会对它进行各种各样的操作，这些操作可以抽象为下面的几个词：访问，更新，替换，发现属性。一般来说，只有访问方法这一项在任何URL方案中都需要进行描述。
2．1  URL的主要部分
第五部分给出了URL语法的完整BNF描述。
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   （使用NNTP访问的USENET新闻）
telnet （交互式会话访问）
wais    Wide Area Information Servers（广域信息服务系统）
file    Host-specific file names（特殊主机文件名）
prospero Prospero Directory Service(prospero目录服务)
在以后的说明书中可能会对其他一些方案加以描述。这篇文档的第四部分介绍了如何注册新的方案，并且列出了一些正在研究中的方案名。
3．1通用因特网方案语法
虽然URL其他部分的语法因方案的不同而不同，但那些直接使用基于IP的协议来定位因特网上的主机的URL方案都使用了如下形式的通用语法来表示特定的方案数据：
//<用户名>:<密码>@<主机>:<端口>/<url路径>
可能会省略“<用户名>:<密码>@”，“ :<密码>”，“ :<端口>”，和“/<url路径>”这些部分的某些或者全部。这些方案的特定数据以双斜线“//”开头来表明它遵从通用因特网方案语法。各个部分分别遵守如下规则：
用户名
任意的用户名称。有些方案（例如：ftp）允许使用用户名称的描述。
密码
任意的密码。如果存在的话，它紧跟在用户名后面并用一个冒号隔开。
用户名（和密码）如果存在的话，其后紧跟一个商用符号“@”。在用户名和密码字段中出现的任何“:”，“@”或者“/”都要进行编码。
注意空的用户名或者密码不同于没有用户名和密码；决不能在没有指定用户名的情况下指定密码。例如：<URL:
------------------------------------------------------------------------
。。。。。。。。
完整内容参见 http://kummerwu.web.officelive.com/Documents/rfc1738-0.html
更多RFC中文版，中英文对照版，请查阅http://kummerwu.web.officelive.com/Documents/index.html

这儿目前收录来OSPF，BGP，RIP，MPLS(VPN)、HTTP，Telnet,RSVP，PPP，POP3，RTP，NAT，FTP等最新RFC中文版和中英文对照版。而且内容还在不断更新中......