url语法

url语法

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有时候被用来定位那些包含指示器的资源，而这些指示器又指向其他资源。有时候这

些指示器用关系链接表示，在关系链接中第二资源的位置表示符原则上“和那些除了带有

次相关路径的表示符相同”。在这篇文档中没有对关系链接进行描述。但是，关系链接的