关于URL编码

作者: 阮一峰

日期: 2010年2月11日

一、问题的由来

URL就是网址,只要上网,就一定会用到。

bg2010021101.jpg

一般来说,URL只能使用英文字母、阿拉伯数字和某些标点符号,不能使用其他文字和符号。比如,世界上有英文字母的网址"http://www.abc.com",但是没有希腊字母的网址"http://www.aβγ.com"(读作阿尔法-贝塔-伽玛.com)。这是因为网络标准RFC 1738做了硬性规定:

"...Only 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."

"只有字母和数字[0-9a-zA-Z]、一些特殊符号"$-_.+!*'(),"[不包括双引号]、以及某些保留字,才可以不经过编码直接用于URL。"

这意味着,如果URL中有汉字,就必须编码后使用。但是麻烦的是,RFC 1738没有规定具体的编码方法,而是交给应用程序(浏览器)自己决定。这导致"URL编码"成为了一个混乱的领域。

下面就让我们看看,"URL编码"到底有多混乱。我会依次分析四种不同的情况,在每一种情况中,浏览器的URL编码方法都不一样。把它们的差异解释清楚之后,我再说如何用Javascript找到一个统一的编码方法。

二、情况1:网址路径中包含汉字

打开IE(我用的是8.0版),输入网址"http://zh.wikipedia.org/wiki/春节"。注意,"春节"这两个字此时是网址路径的一部分。

bg2010021102.jpg

查看HTTP请求的头信息,会发现IE实际查询的网址是"http://zh.wikipedia.org/wiki/%E6%98%A5%E8%8A%82"。也就是说,IE自动将"春节"编码成了"%E6%98%A5%E8%8A%82"。

bg2010021103.png

我们知道,"春"和"节"的utf-8编码分别是"E6 98 A5"和"E8 8A 82",因此,"%E6%98%A5%E8%8A%82"就是按照顺序,在每个字节前加上%而得到的。(具体的转码方法,请参考我写的《字符编码笔记》。)

在Firefox中测试,也得到了同样的结果。所以,结论1就是,网址路径的编码,用的是utf-8编码。

三、情况2:查询字符串包含汉字

在IE中输入网址"http://www.baidu.com/s?wd=春节"。注意,"春节"这两个字此时属于查询字符串,不属于网址路径,不要与情况1混淆。

bg2010021104.jpg

查看HTTP请求的头信息,会发现IE将"春节"转化成了一个乱码。

bg2010021105.png

切换到十六进制方式,才能清楚地看到,"春节"被转成了"B4 BA BD DA"。

bg2010021106.png

我们知道,"春"和"节"的GB2312编码(我的操作系统"Windows XP"中文版的默认编码)分别是"B4 BA"和"BD DA"。因此,IE实际上就是将查询字符串,以GB2312编码的格式发送出去。

Firefox的处理方法,略有不同。它发送的HTTP Head是"wd=%B4%BA%BD%DA"。也就是说,同样采用GB2312编码,但是在每个字节前加上了%。

bg2010021107.png

所以,结论2就是,查询字符串的编码,用的是操作系统的默认编码。

四、情况3:Get方法生成的URL包含汉字

前面说的是直接输入网址的情况,但是更常见的情况是,在已打开的网页上,直接用Get或Post方法发出HTTP请求。

根据台湾中兴大学吕瑞麟老师的试验,这时的编码方法由网页的编码决定,也就是由HTML源码中字符集的设定决定。

  <meta http-equiv="Content-Type" content="text/html;charset=xxxx">

如果上面这一行最后的charset是UTF-8,则URL就以UTF-8编码;如果是GB2312,URL就以GB2312编码。

举例来说,百度是GB2312编码,Google是UTF-8编码。因此,从它们的搜索框中搜索同一个词"春节",生成的查询字符串是不一样的。

百度生成的是%B4%BA%BD%DA,这是GB2312编码。

bg2010021109.jpg

Google生成的是%E6%98%A5%E8%8A%82,这是UTF-8编码。

bg2010021108.jpg

所以,结论3就是,GET和POST方法的编码,用的是网页的编码。

五、情况4:Ajax调用的URL包含汉字

前面三种情况都是由浏览器发出HTTP请求,最后一种情况则是由Javascript生成HTTP请求,也就是Ajax调用。还是根据吕瑞麟老师的文章,在这种情况下,IE和Firefox的处理方式完全不一样。

举例来说,有这样两行代码:

  url = url + "?q=" +document.myform.elements[0].value; // 假定用户在表单中提交的值是"春节"这两个字

  http_request.open('GET', url, true);

那么,无论网页使用什么字符集,IE传送给服务器的总是"q=%B4%BA%BD%DA",而Firefox传送给服务器的总是"q=%E6%98%A5%E8%8A%82"。也就是说,在Ajax调用中,IE总是采用GB2312编码(操作系统的默认编码),而Firefox总是采用utf-8编码。这就是我们的结论4。

六、Javascript函数:escape()

好了,到此为止,四种情况都说完了。

假定前面你都看懂了,那么此时你应该会感到很头痛。因为,实在太混乱了。不同的操作系统、不同的浏览器、不同的网页字符集,将导致完全不同的编码结果。如果程序员要把每一种结果都考虑进去,是不是太恐怖了?有没有办法,能够保证客户端只用一种编码方法向服务器发出请求?

回答是有的,就是使用Javascript先对URL编码,然后再向服务器提交,不要给浏览器插手的机会。因为Javascript的输出总是一致的,所以就保证了服务器得到的数据是格式统一的。

Javascript语言用于编码的函数,一共有三个,最古老的一个就是escape()。虽然这个函数现在已经不提倡使用了,但是由于历史原因,很多地方还在使用它,所以有必要先从它讲起。

实际上,escape()不能直接用于URL编码,它的真正作用是返回一个字符的Unicode编码值。比如"春节"的返回结果是%u6625%u8282,也就是说在Unicode字符集中,"春"是第6625个(十六进制)字符,"节"是第8282个(十六进制)字符。

bg2010021110.png

它的具体规则是,除了ASCII字母、数字、标点符号"@ * _ + - . /"以外,对其他所有字符进行编码。在\u0000到\u00ff之间的符号被转成%xx的形式,其余符号被转成%uxxxx的形式。对应的解码函数是unescape()。

所以,"Hello World"的escape()编码就是"Hello%20World"。因为空格的Unicode值是20(十六进制)。

bg2010021111.png

还有两个地方需要注意。

首先,无论网页的原始编码是什么,一旦被Javascript编码,就都变为unicode字符。也就是说,Javascipt函数的输入和输出,默认都是Unicode字符。这一点对下面两个函数也适用。

bg2010021112.png

其次,escape()不对"+"编码。但是我们知道,网页在提交表单的时候,如果有空格,则会被转化为+字符。服务器处理数据的时候,会把+号处理成空格。所以,使用的时候要小心。

七、Javascript函数:encodeURI()

encodeURI()是Javascript中真正用来对URL编码的函数。

它着眼于对整个URL进行编码,因此除了常见的符号以外,对其他一些在网址中有特殊含义的符号"; / ? : @ & = + $ , #",也不进行编码。编码后,它输出符号的utf-8形式,并且在每个字节前加上%。

bg2010021113.png

它对应的解码函数是decodeURI()。

bg2010021114.png

需要注意的是,它不对单引号'编码。

八、Javascript函数:encodeURIComponent()

最后一个Javascript编码函数是encodeURIComponent()。与encodeURI()的区别是,它用于对URL的组成部分进行个别编码,而不用于对整个URL进行编码。

因此,"; / ? : @ & = + $ , #",这些在encodeURI()中不被编码的符号,在encodeURIComponent()中统统会被编码。至于具体的编码方法,两者是一样。

bg2010021115.png

它对应的解码函数是decodeURIComponent()。

(完)

留言(66条)

提前祝阮大哥虎年好啊。。。

网页里的form编码其实不完全取决于网页编码,form标记中有一个accept-charset属性,在非ie浏览器种,如果将其赋值(比如accept-charset="UTF-8"),则表单会按照这个值表示的编码方式进行提交。
在ie下,我的兼容解决办法是:
form1.onsubmit=function(){
document.charset=this.getAttribute('accept-charset');
}

拜读完毕,解我心头大惑,十分感谢。

引用Jinjiang的发言:

网页里的form编码其实不完全取决于网页编码,form标记中有一个accept-charset属性,在非ie浏览器种,如果将其赋值(比如accept-charset="UTF-8"),则表单会按照这个值表示的编码方式进行提交。

谢谢指出啊。虽然以前看到过这个属性,但是早忘了,你说了才想起来。

瀏覽器JS在解釋字符編碼時可以選擇,(不是統一按操作系統語言)瀏覽器的JS和網頁JS兩個概念.一個能調用組件,另一個不能調用組件.

參考:
[firefox] about:config 下如下選項
Network.http.accept-encoding
Network.http.accept.default
intl. accept_charsets

长知识了!

结论2的推断不严谨,你不能说某个东西和某个东西一致,它就是按照这个东西来的,小蝌蚪找妈妈呀?

写的很不错!

前面的几个情况,都和特定浏览器的特定版本、操作系统本地环境变量等情况有关系,做出结论似乎不太严谨。

补充点我的结果

情况3里,我用firefox在地址栏输入“http://www.baidu.com/s?wd=春节“访问,http header里发送的“春节”是UTF8的,然后百度就傻了,页面搜索框里显示的关键词是:鏄ヨ妭。
实际效果大概等同于 http://www.baidu.com/s?wd=%E6%98%A5%E8%8A%82,
baidu不会识别这种UTF8码的输入。

而在google,这两个地址都是可用的,等效的:
http://www.google.com/search?q=春节
http://www.google.com/search?q=%E6%98%A5%E8%8A%82

我的浏览器是Firefox 3.5.7 for ubuntu.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7 GTB6

引用M的发言:

情况3里,我用firefox在地址栏输入“http://www.baidu.com/s?wd=春节“访问

这属于情况2,不属于情况3。

引用dulao5的发言:

前面的几个情况,都和特定浏览器的特定版本、操作系统本地环境变量等情况有关系,做出结论似乎不太严谨。

接受你的批评,我的样本确实少了点。不过,最常见的情况应该都讨论到了。

阮兄noob了。。。这个是网页自己指定的charset,指定gb2312什么就提交gb2312,指定utf8就提交utf8

To est:

你说的是情况3。

情况1、情况2和情况4都与网页本身指定的charset无关。尤其是前两种情况,这时浏览器还不知道网页本身的编码呢。

引用Ruan YiFeng的发言:

谢谢指出啊。虽然以前看到过这个属性,但是早忘了,你说了才想起来。



不客气~
我也是最近写了一个可以登录各种邮箱和社区的表单时,为了应付各个站点要求不同编码方式的表单提交,才注意到这个属性的,今天看到您在此讨论编码问题,所以拿出来分享一下~ 呵呵

提前祝阮大哥虎年好啊。。。

情况1和2本质上是一样的,在web server内部会把1转换成2的形式。其实使用何种编码,都是取决与如何“约定”————服务器对客户端提交的数据使用何种编码有约定,客户端只有按约定的编码发送信息,才会被正确decode.

解决了我一直以来的困惑

太好了,编码用于争取夺走的权利

引用Ruan YiFeng的发言:

To est:

你说的是情况3。

情况1、情况2和情况4都与网页本身指定的charset无关。尤其是前两种情况,这时浏览器还不知道网页本身的编码呢。

HTTP头也可以直接指定charset的。用抓包软件看看 Content-Type: text/html; charset=utf-8

如果HTTP头也没有指定,那就和浏览器设置有关。如果浏览器也没有设置,那就和当前进程系统设置(codepage)有关。如果和当前进程无关,那么就是操作系统默认编码了。编码和URL并没有绝对关系。

这样的文章,读起来舒服!!!

新年快乐!

情况一不是很明白
情况二的话,在IE中用wireshark抓包,貌似变成了“\264\272\275\332\”并非传说中的URL“%B4%BA%BD%DA”虽然只是表示有点不一样,可就是不明白为啥没有“%”这个百分号了呢?
不吝赐教~

结论二的推论是有问题的
用一个utf-8的网站反而更有说服力

确实挺乱的,也许将来会出一个统一的标准吧!

原创否?

我是菜鸟,想请教一下你前面看他们的编码工具是什么啊?怎么查看的啊?

有一点问题:
URL编码是否正确,跟选用的服务器有关。
你可以尝试http://www.google.com.hk/search?hl=zh-CN&q=%E6%98%A5%E8%8A%82跟http://www.google.com.hk/search?hl=zh-CN&q=%B4%BA%BD%DA,均可以正常解析。
显然,Google的服务器内置了编码转换。
对目前最流行的Apache服务器来说,URL的编码跟页面的编码保持一致。你所说的第1种情况跟第2种情况,不过是由于wiki采用UTF-8,而Baidu采用GBK编码的原因。

请交一下搜索繁体字的时候浏览器是真么编码的?
比如搜索“商業網站”, 百度的搜索引擎会出现%C9%CC%98I%BEW%D5%BE这样的编码。 开头的“%C9%CC就是“商”,结尾的“%D5%BE”就是“站”,而中间的两个繁体字URL编码成了“%98I%BEW”。 一般%号后面都是两个字母,繁体怎么会有三个字母呢?

还是不懂, 那你用不同的编码,服务器是什么解析的

初学PHP,感觉很受用!

感谢阮老师,解决了一个大问题

对于结论2,我觉得有点问题,用谷歌www.google.com.hk查询时,URL的编码为UTF-8,我觉得是网站使用的编码有关的吧。

凭某个测试结果总结出来的规则是不严谨的。。。
仅我知道的,在tomcat里,结论3未必是正确的,get的编码是否和网页编码一致取决于tomcat是否设置了某个属性

结论3就是,GET和POST方法的编码,用的是网页的编码。


好文章啊 很详细!

不管结论如何,讨论问题的思路还是很清楚的。
愿意研究,依次尝试下来,都会有写收获

这个问题或许没那么简单,因为服务器端比如 IIS, APACHE 还会对 URL 中的字符进行解码处理。头疼啊,为什么这么棘手的问题很少有人深入讨论? 编码问题绝对是个毒瘤。

总结的很好,很喜欢。

url编码的确是个头痛的事

哥们,你的文章太值得读了,拜谢!

我想问一下下面这个地址中波浪线“~”在URL中起什么作用啊?
http://www.cs.tut.fi/~jkorpela/html/strict.html


p.s.请邮件告知,多谢!
chorles#sohu.com #->@

请问下怎么把URL转化为UR这类型的?
请问有工具直接转换吗?

干货,赞!
使用encodeURI输出的是UTF8编码格式的,如果是通过get方式发出请求,但请求地址是第三方GB2312的页面,可能会出现乱码情况,该如何处理?

写得很详细,受教了

关于将网页提交表单时将 空格转换为+,在哪里有比较官方的声明呢?

捐款完毕2元(汗颜)!真正帮助了我解决了实际问题。如果不捐,过去因这个问题而痛苦挣扎的我,会恨自己。

我对情况2做了练习,在地址栏里直接输入:“http://www.baidu.com/s?wd=春节”。结果在firebug中看到的是:
GET /s?wd=%E6%98%A5%E8%8A%82 HTTP/1.1
Host: www.baidu.com
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: BAIDUID=414B5AFB67FF1218D91F5FDBF032143E:FG=1
Connection: keep-alive
“春节”两个汉字被用UTF-8编码了,而不是GB2312
请问:是我做的过程有问题,还是Firefox升级,造成的?到底该怎么对待地址重写中汉字的编码?

从内容和表达都很到位。 alipay不支持pc捐款了,阮老师给个二维码吧

写的详实,很不错

"只有字母和数字[0-9a-zA-Z]、一些特殊符号"$-_.+!*'(),"[不包括双引号]、以及某些保留字,才可以不经过编码直接用于URL。"
这句话中特殊符号那里是不是有问题,难道%,/,=,这几个符号都不能直接用于url?这些都是常见的啊

我想在C中进行url编码, 解码, 搜到了这里.
根据自己的观察, 结合你文章的几个结论, 发现 *可能* 的原则是:

对于中文, 文本框的编码是GBK/Unicode/xxx, 那么URL编码用的就是GBK/Unicode/xxx.
这里的文本框可以是地址栏, 表单输入, 文件, ...


未验证.

谢谢,您的很多文章都帮我大忙了:)

chrome中情况2用的是utf-8,请阮大牛确认

解决了我的问题,非常感谢

很有用处

看了您的这篇文章还有那篇讲编码的,很受用,原来碰到的问题解决了

您好,我现在通过字符串解析的办法提取html中所有url,然后replace成编码后的形式,那么浏览器打开后其实又会对‘%’符号进行一次编码,导致html无法正常运行,请问这种情况跟您说的用js对url编码后向服务器提交有什么区别吗?

阮大大,您的博客真是太好了.今天又帮了我一个大忙!!!

引用dulao5的发言:

前面的几个情况,都和特定浏览器的特定版本、操作系统本地环境变量等情况有关系,做出结论似乎不太严谨。

是的,现在测试IE-Edge版,用的都是utf-8编码

对于encodeURI 和 encodeURIComponent 区别是什么还是说的不清楚?
encodeURI:【它着眼于对整个URL进行编码,因此除了常见的符号以外,对其他一些在网址中有特殊含义的符号"; / ? : @ & = + $ , #",也不进行编码。编码后,它输出符号的utf-8形式,并且在每个字节前加上%。】
encodeURIComponent【 与encodeURI()的区别是,它用于对URL的组成部分进行个别编码,而不用于对整个URL进行编码。】
什么是着眼于整个URL?如何理解?

最近也在研究编码这一块,看完这篇文章之后思路清晰了很多,在此表示感谢。但是还有一个疑惑没能解决,如果情况有那么多种,难道就没有一个固定字段标明准确的编码格式的吗?

@rzet:

我的理解是encodeURI可以直接对整个url进行编码
encodeURIComponent用于对参数部分编码
因为encodeURIComponent会对 / ? :编码,如果用于完整的URL编码就会把http://xx?sss的不该编码的字符编码了

2010 年3月23日,谷歌中国声明因“遭受中国黑客攻击”和“网络审查”决定退出中国市场。 Google公司将原有谷歌中国的两域名(google.cn和g.cn)中的网页、图片和资讯(后更名为“新闻”)等搜索服务重定向至Google香港(google.com.hk)。

现在已经过去十年了

@rzet:

假如现在需要在http://www.baidu.com/s后面拼接查询字符串?wd=你好&春节 ,如果你用encodeURI()对拼接后的url编码,那么特殊字符&不会被编码,服务器拿到url后将不能正确解析出查询字符串,这个时候你应该对查询字符串部分单独使用encodeURIComponent()进行编码,然后再拼接至url后面


"...Only 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."

- ed是啥意思?

引用猪头四的发言:

提前祝阮大哥虎年好啊。。。

年复一年又一轮,虎年安康

看了您的文章,豁然开朗!解决了我做的集成搜索框,对自己很有帮助!

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接