除了普通的字母,数字,中文,还有特殊字符,但是规范的使用应该是使用字符转义。
"+" URL 中+号表示空格 %2B
"空格" URL中的空格可以用+号或者编码 %20
"/" 分隔目录和子目录 %2F
"?" 分隔实际的 URL 和参数 %3F
"%" 指定特殊字符 %25
"#" 表示书签 %23
"&" URL 中指定的参数间的分隔符 %26
"=" URL 中指定参数的值 %3D
"\" 表示目录路径 %5C
"." 句号 %2E
":" 冒号 %3A
关于URL编码,RFC1738做 了如下的规定:
“On
ly alphanumerics [0-9a-zA-Z], the special characters “$-_.+!*’(),” [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL.”
RFC继而说明了保留字、特殊符号、不安全字符的含义——也就是说,下面三类字符可以不经过编码,直接出现在URL上:
- [0-9a-zA-Z]
- 特殊字符:$-_.+!*’(),
- 保留字符:&/:;=?@
为了让我们思路更清晰,我们再总结一下,哪些字符必须要编码:
- ASCII表中没有对应可显示字符的,例如汉字
- 不安全字符,包括:#”%<>[]{}|\^`~
- 不当做保留字符来使用的保留字符,即&/:;=?@
详见这张图,一目了然(点击看大图):
如何编码?
众所周知,字符是可由八位字节数(octet)来表示的,八位字节数可用十六进制来表示它的值。如字符“<”的八位字节数十六进制值是3C。 在URL中,字符的编码方式为:“%”加上字符的两个十六进制数值。举几个例子:
- “<”可以被编码为%3C,空格“SP” 可被编码为“%20”
- “田”的GB2312编码十六进制值是CC EF,这时“田”的URL编码为%CC%EF
- “囧”的GBK编码十六进制值是87 E5,这时“囧”的URL编码为%87%E5
- “田”的UTF-8编码十六进制值是E7 94 B0,这时“田”的URL编码为%E7%94%B0
URL中包含汉字时的更多话题
RFC1738没有规定汉字的编码方式,而是让浏览器自己去决定,因此造成了URL汉字编码的不统一。经过研究,对于URL中的“查询字符串”和 “路径”中包含汉字,不同浏览器有不同的处理。
1. 查询字符串中包含汉字
在网址输入:http://www.baidu.com/s?wd=田囧 ,敲击回车,使用Fiddler观察浏览器发出的请求(以IE8和Firefox为例):
IE8将汉字作为GBK编码,直接发往服务器(这其实是不符合RFC规范的);Firefox则多了一次加%的操作。Windows操作系统是 GBK编码。得到结论,地址栏直接访问URL,汉字作为查询字符串(Query string)时,IE和Firefox会使用系统编码发至服务器端,Firefox会按规矩编码。
注意1:不要用Google进行测试,Google的搜索URL(类 似:http://www.google.com/#hl=en&source=hp&q=田囧 ),搜索关键词那里不是查询字符串,因为前面有个#……我开始没注意到,被搞迷茫了很久……
注意2:这只是对URL直接访问的规律。如果页面时从链接点击打开的,例如从A页面含中文的链接打开了B页面, 那么浏览器对中文的编码取决于A页面的编码。
2. URL路径中包含汉字
在网址直接输入:http://www.hudong.com/wiki/田囧 ,敲击回车,观察请求:
IE8和Firefox都把汉字作为UTF8,按规范进行了URL编码,还好。
总结
什么字符应该编码,什么字符不用编码,URL编码的基本问题,到此已经解决啦。