误导性文章太多了，干脆自己写一个。没有历史沿革纯内容
 
url编码：对于超出ascii范围的字符，使用utf-8对其进行编码（utf-8兼容ascii），然后对每个结果进行百分号编码；除此之外，还会将空格替换为加号
 
百分号编码：十六进制下的一个字节，如0xE4，将E4看成字符串再进行ascii编码，即会从一个字节变成两个字节，然后再添加百分号%，此时变成三个字节。
 
所以，一个汉字如果经由utf-8编码结果是三个字节，url编码这个汉字结果是九个字节。当然，有些url编码实现中不一定用utf-8，有些url编码实现中，对于utf-8得到的可以用ascii解码的字节，不用再进行百分号编码。但都无所谓

 
一、直接在地址栏中输入URL的情况
 
在中文Windows环境下，本地编码为GB2312：
 
 
 
 
 
假如在浏览器地址栏中直接输入以下URL：
 
http://localhost:8080/servletTest/中国.do?name=中国
 
1、IE浏览器
 
版本：
 
 
 
默认情况下，总是以UTF-8发送URL:
 
 
 
这里要用到一个抓包工具Fiddler，安装后启动就行。
 
打开IE，输入URL:
 
 
 
此时，Fiddler中会抓取到数据：
 

 
会发现，pathInfo中的“中国”两个字被编码为：%E4%B8%AD%E5%9B%BD。这个是UTF-8编码。而queryString中的‘中国’两个字是乱码：name=�й�。在Fiddler中切换到十六进制可以看到真实的编码：
 

 
这个十六进制编码D6 D0 B9 FA，就是‘中国’两个字的GB2312编码。
 
现在将默认修改为不以UTF-8发送：
 
 
 
再次在IE的地址栏中输入请求URL：
 
 
 
发现pathInfo部分的”中国”两个字的编码是%D6%D0%B9%FA。但是queryString部分依旧是乱码，按照十六进制查看，也是按照GB2312。
 
小结：IE9 中的编码方式
 

 
二、利用FireFox浏览器直接在地址栏输入URL进行访问
 
浏览器版本：
 

 
在默认的情况下，输入URL：
 
http://localhost:8080/servletTest/中国.do?name=中国
 

 
发现URL中pathInfo和queryString中“中国”两个字的编码是：%E4%B8%AD%E5%9B%BD，这是UTF-8编码。
 
小结：火狐浏览器默认utf-8编码(浏览器版本可能会有差异)
 

 
3、Chrome浏览器直接访问URL
 
 
 

 
发现URL中pathInfo和queryString中“中国”两个字的编码是：%E4%B8%AD%E5%9B%BD，这是UTF-8编码。
 
小结：Chrome浏览器默认utf-8编码(浏览器版本可能会有差异)
 

 
二、根据页面的编码，各种浏览器的URL编码
 
1、使用Get请求,页面设置为：
 
姓名
年龄

 
1.1 firefox浏览器(默认设置)
 
 
 
输入以下内容，提交：
 
 
 
 
 
火狐浏览器在页面是GBK编码的情况下，采用GET提交，发现pathInfo部分是UTF-8编码，但是queryString是GBK编码(也就是页面数据部分)。
 
1.2、将页面编码修改为UTF-8：
 
重新提交 GET请求：
 
 
 
火狐浏览器在页面是UTF-8编码的情况下，采用GET提交，发现pathInfo部分是UTF-8编码，但是queryString是UTF-8编码(也就是页面数据部分)。
 
1.3、用Chrome浏览器(默认)
 
 
 
Chrome浏览器在页面是GBK编码的情况下，发现pathInfo部分是UTF-8编码，但是queryString是GBK编码(也就是页面数据部分)。
 
1.4、采用Chrome浏览器采用PostT提交：
 
 
 
Chrome浏览器在页面是UTF-8编码的情况下，采用GET提交，发现pathInfo部分是UTF-8编码，但是queryString是UTF-8编码(也就是页面数据部分)。
 
小结：1、页面编码是GBK,提交是GET 的情况下：
 

 
2、页面编码是UTF-8,提交是GET的情况下：
 

 
2、采用Post提交，但是页面还是设置GBK：
 
姓名
年龄

 
2.1、火狐浏览器
 
 
 
 
 
火狐浏览器在页面是GBK编码的情况下，采用POST提交，发现pathInfo部分是UTF-8编码，但是queryString是GBK编码(也就是页面数据部分)。
 
2.2、修改页面编码格式为UTF-8，:
 
 
 
火狐浏览器在页面是UTF-8编码的情况下，采用POST提交，发现pathInfo部分是UTF-8编码，但是queryString是UTF-8编码(也就是页面数据部分)。
 
2.3、Chrome浏览器
 
 
 
Chrome浏览器在页面是GBK编码的情况下，采用POST提交，发现pathInfo部分是UTF-8编码，但是queryString是GBK编码(也就是页面数据部分)。
 
2.4、页面也修改为UTF-8编码：
 
 
 
Chrome浏览器在页面是UTF-8编码的情况下，采用POST提交，发现pathInfo部分是UTF-8编码，但是queryString是UTF-8编码(也就是页面数据部分)。
 
小结：1、页面编码是GBK，提交是POST 的情况下：
 

 
2、页面编码是UTF-8，提交是POST 的情况下：
 

由于URL编码的一些混乱情况，曾经困扰着无数的程序员，本文将捋一捋URL编码相关的一些知识点，希望看望之后能给人恍然大悟的感觉。
 
本文将从如下几个方面进行介绍：
 
什么是URL编码
为什么进行URL编码
对哪些字符进行URL编码
怎么编码
实施URL编码的主体是谁
URL编码后都长什么样子
 
什么是URL编码
 
首先什么是编码，现实世界中的事务，比如字符和数字要想在计算机中进行展示，必须经过一定形式的转换，也就是要转换成为0,1串的表示方式，这就是编码。在计算机中，编码的本质是为了存储，和传输。比如说字符G使用ASCII 0x47进行编号，并使用一个字节进行存储。一般的，在计算机中对于英文和数字采用的是ASCII来进行存储和传输。如下图1：
 
 图1
 在早期，URL编码，则是将scope限定在URL中，对URL中的一些字符进行编码。但是在实际的使用中，你会看到HTTP的body以及header等其他部分，也都有URL编码的身影。由于这些特殊字符出现在了HTTP body以及header等部分，为了方便传输，直接将URL编码的方法拿来使用，但是在使用的过程中仍然称之为URL编码。
 
为什么进行URL编码
 
在计算机发展的早期，使用ASCII来表示已经能够满足要求。随着网络的普及以及网络所承载应用的复杂化，在URL出现了越来越多的非字母和数字，比如说汉字等非英文字符，空格，大括号，大于号小于号，甚至是一些不可见字符等特殊字符。由于软件的异构性，操作系统的异构性等各方面的差异，导致各系统在解码数据的时候存在着不同，举例如下：
 
场景一：当A向B传输的URL中包含空格20的时候，这个空额究竟是URL的一部分，还是分隔符呢？如下：
 
GET /32k.html HTTP/1.1
 
可以看出空格在HTTP协议中是各个字段的分隔符，将请求方法GET，请求的路径/32k.html，以及请求的协议HTTP/1.1进行分割，因此如果在请求的路径中出现空格，势必对于解码会造成影响。因此如果请求路径中包含空格，则需要特殊的处理，即URL编码。
 
场景二：汉字无法使用ASCII进行表示，可以是使用UTF-8或者GBK编码表示，例如汉字村的GBK编码为B4E5，当甲向乙请求的URL包含汉字村的时候，在URL没有任何任何标识的情况下，乙是将B4E5当作B4和E5两个单独的字节进行处理还是将其当作B4E5进行处理呢？此处存在着歧义性。
 
对于上述两种场景，URL中出现的字符已经使得URL本身解析出现歧义。URL编码正是为了解决这种歧义而来，对于汉字等非英文字符，以及空格等特殊字符进行编码。
 
对URL哪些字符进行编码
 
究竟哪些字符需要编码，哪些字符不需要呢。可以知道，常见的英文字符以及数字直接使用ASCII的形式表示就可以了，不需要进行URL编码，对于特殊的字符以及非英文字符是否都需要URL编码呢？这是在网络通信协议是有响应的规定和建议的，对应的RFC为rfc1738，如下：
 
 
 
Thus, only alphanumerics, the special characters “$-_.+!*’(),”, and reserved characters used for their reserved purposes may be used unencoded within a URL.
 
 
可以看到对于不需要编码的字符包括数字，字母以及常见的特殊字符和保留字符，当然关于保留字符的定义RFC使用了关键词may，即可能，这就导致可程序员在实现URL编码的过程中出现了步调不一致的情况。当然RFC中针对为啥大于号以及中括号等是需要编码的也给出了解释，如下：
 
 
 
Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs. The characters “<” and “>” are unsafe because they are used as the delimiters around URLs in free text; the quote mark (""") is used to delimit URLs in some systems. The character “#” is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it. The character “%” is unsafe because it is used for encodings of other characters. Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters. These characters are “{”, “}”, “|”, “”, “^”, “~”, “[”, “]”, and “`”.
 All unsafe characters must always be encoded within a URL. For example, the character “#” must be encoded within URLs even in systems that do not normally deal with fragment or anchor identifiers, so that if the URL is copied into another system that does use them, it will not be necessary to change the URL encoding.
 
 
主要是出于系统异构性的考虑，比如大于号，小于号以及引号在某些系统中被当做分隔符进行使用。但是RFC同时也提到字母和数字也可以编码，如下：
 
 
 
On the other hand, characters that are not required to be encoded (including alphanumerics) may be encoded within the scheme-specific part of a URL, as long as they are not being used for a reserved purpose.
 
 
其实RFC就是这样，只是给出了一个指导性的大纲，有的地方并没有定的很绝对，除了must的字段，对于may,should等表述，在最终工程落地来看，不同的实现人员是存在不同的思路的。这也就导致到了后续究竟是对那些字符进行编码，哪些不进行编码，其实并没有统一。因此现实中的不同语言，不同软件对于URL编码处理并不一致，程序员也会不断的遇到URL编码的各种奇怪的状况。
 
怎么编码
 
总的来说，对URL中需要编码的字符，使用%加上该字符对应的编码值。例如空格对应的ASCII值是20，对于URL出现的空格需要使用%20进行替换，即传输的实际值为0x25 0x32 0x30，如图3所示：
 
 图3
 汉字存在多种编码方式，例如GBK以及UTF-8等，汉字村中少年的GBK编码是B4E5（46309）、D6D0（54992）、C9D9（51673）、C4EA（50410），村UTF8编码是E69D91。因此如果村采用的是GBK编码，实际传输的字符是%B4%E5;如果传输使用的是UTF8编码，实际传输的字符是%E6%9D%91，如图4所示：
 
 
图4
 对于标准的ASCII范围内的值，由于基本上所有的编码方式，都是向前兼容，因此这些字符对应的URL编码存在差异的情况不多。但是对于汉字来说，URL编码中使用的具体编码方式采用的是GBK或者GB2312还是UTF-8能，或者是其他的编码方式呢？这就要看那个主体对于传输的字符进行URL编码。
 
实施URL编码的主体是谁
 
总的来说，对于传输字符进行URL编码既可以是网页服务的提供者，例如百度和Google，也可以是浏览器的开发商，例如IE和chrome等。对于汉字来说因为GBK是国标编码方式，是为汉字编码方式而生，因此在涉及到汉字或者中国软件公司的地方，采用GBK的情况居多，但是越来越多的程序员开始使用UTF-8的方式。UTF-8是为了全球字符能够在计算机中存储和传输指定的编码方式，因此在以美国为代表的软件公司中使用UTF-8的编码方式居多。同样的日本的一些软件，可能会采用日文特有的编码方式。
 
网页提供者规定URL的编码方式
 
如下图5，6是google和百度搜索引擎在搜索服务中，搜索框中对于汉字的编码采用了UTF-8的编码方式：
 

 图5
 
 图6
 可以看到，搜索引擎本身规定了汉字在URL中的编码方式，因为百度的表单提交中显示的表明了编码方式为UTF-8。因为表单提交服务是网页供应商的功能，因此其可以决定客户提交数据采用何种编码方式。在客户端用户发送请求的时候，通过调用搜索引擎对应的js脚本进行编码实现，如下图7：
 
 图7
 之前百度的搜索服务也是采用过GB2312方式，现在可能统一了。但是对于国内的网页服务提供商来说，国标的编码方式仍然是一种普遍现象。
 
浏览器等软件规定URL的编码方式
 
由于表单提交服务本质是网页提供商提供的，其有解释权，因此可以规定汉字编码方式。当客户端用户并没有提交表单的行为，在初始访问的时候，在地址栏输入了汉字，这个时候浏览器或则和具体的UA会将该汉字进行编码。采用的是UTF-8还是GBK，不同的浏览器可能选择不同，如图8就是IE采用GBK的方式：
 

 图8
 可以看到IE对于汉字，直接采用GBK编码，甚至都没有使用%形式的URL编码。但是对于百度这种比较强大的网页服务提供上来说，他的服务端是能够识别这种方式，并在后续的请求中要求客户端采用%+GBK的方式进行访问，如图9：
 
 
图9
 由于UTF-8是国际标准，因此采用UTF-8的居多。比如chrome浏览器，以及采用chrome内核的edge多采用UTF-8方式。由于在汉化的软件中，对于URL的编码也有可能使用GB2312的，例如早期的IE。但是一个URL对于服务端的解析来说一定是固定的，要么采用GBK，要么是UTF-8。如果服务端采用的是UTF-8进行解码，客户端传输的是GBK方式，可能会导致网页无法访问，因此通信双方需要保持编解码一致。
 
URL编码后都长什么样子
 
URL编码可以采用公开的组件，例如js中提供的函数，以及Python等语言中的函数，但是要注意这些URL编解码函数存在着一定的差异。有的时候你可能会注意到，实际传输的汉字即不是UTF-8编码方式也不是GBK编码方式，而是一种非常奇怪的方式%u6751，这是什么原因造成的呢？这种情况主要是网页的提供者在对URL进行编码的时候采用的JS函数不同所导致的。例如baidu的js采用的编码函数为encodeURIComponent，如上图7，在js中出了encodeURIComponent进行URL的编码。除此之外js可提供的编码函数还包括encodeURI以及escape函数。因此不同的网页提供者采用的URL编码函数的不同，也就导致可能出现的编码内容的不同。
 
escape函数作用是返回对应的字符的unicode编号（注意编号和编码的区别，编码有存储的概念，因此存在字节长度），服务端使用unescape解码即可。早期阶段使用该函数完成URL编码的功能，如下图10:
 
 图10
 \u的编码方式目前已经不被提倡使用，因此在如今程序员编写的js中基本很少使用escape。我的猜测是当年escape函数本身的编写人员对于编码并没有理解到位，采用的是unicode编号，同时以四字节对齐来强加存储的概念，这个事情在py2中也是有所体现的。
 
encodeURI以及encodeURIComponent是当前经常被使用的URL编码函数，这两个函数的区别在于对于特殊字符的编码处理的不太一致，这与前面提到的。对RFC1738的实现，不同的人出现了不同的理解。由js的三个函数可以看出URL编码在实现层面，不同工程师的思路还是有较大的差异。当然关于三个函数的详细区别，可以产看对应的js手册。
 
前面也曾提到，URL编码最初是为了解决URL中的特殊字符传输问题。但是特殊字符可能会存在任何地方，因此在实际的网络传输中你会发现很多的协议内容为了传输特殊字符，都有采用URL编码的方式进行数据的编解码。因此URL编码只是一种称呼，其应用可以在HTTP的header或者body中，甚至是其他协议中。
 
本文为CSDN村中少年原创文章，未经允许不得转载，博主链接这里。

 
地址栏中出现汉字的情况有两种，一种是汉字出现在URL的路径部分，一种是汉字出现在URL的传参的部分，第二种情况的时候必须采用编码后传参，接受时解码的方式完成传参。js中编码有escape(),encodeURI(),encodeURIComponent()三个常用的方法，escape()常常用在提交页面和处理页面的编码格式相同的情况下(比如它们都是GB2312)，encodeURI()和encodeURIComponent()的用法基本相同，区别在于encodeURIComponent()也对"?"等特殊字符进行编码。
 
一开始遇到中文参数的时候，使用encodeURI()进行了一遍编码，传过去后，发现解码出现问题，于是想到可能是编码方法使用错误，于是使用escape()方法，这时发现解码时抛出isHexDigit异常。借助百度搜索isHexDigit异常，
 
发现原来，是escape()方法造成了异常，同时了解了浏览器传递地址的一些原理，在浏览器地址栏里，浏览器认为%是个转义字符，浏览器会把%与%之间的编码，两位两位取出后进行解码,然后再传递给处理页面，
 
然后由处理页面进行再次解码。由此我想到一直使用encodeURI方法是正确的，只是需要使用两次encodeURI方法，例如encodeURI(encodeURI("中文"));第一次是把中文编码成%xy的格式，
 
第二次是对%xy中的%进行编码,%编码成%25。整个传参过程大体应该是：提交页面使用encodeURI(encodeURI("中文"))编码,把最后的编码结果%25xy传递给处理页面的过程中，浏览器获取URL地址
 
(注意openModelDialog方法，浏览器获取不到参数编码)后解码成%xy，然后把%xy传递给处理页面,处理页面使用URLDecoder.decode(request.getParameter("参数名"),"UTF-8");完成解码。
 
总结：
 
1、汉字出现在URL路径部分的时候不需要编码解码;
 
2、使用encodeURI进行2次编码;
 
3、在openModelDialog()打开的模式窗体里没办法用request.getParameter正确获取参数;
 
参考http://www.javaeye.com/topic/358078