之前看过很多关于jsp编码问题的资料，自己也实际去研究过，正好网上看到一篇文章讲得很详细，我也就借花献佛，拿来与大家分享。
一、问题：
编码问题是JAVA初学者在web开发过程中经常会遇到问题，网上也有大量相关的文章介绍，但其中很多文章并没有对URL中使用了中文等非ASCII的字 符造成服务器后台程序解析出现乱码的问题作出准确的解释和说明。本文将详细介绍由于在URL中使用了中文等非ASCII的字符造成乱码的问题。
1、在URL中中文字符通常出现在以下两个地方：
(1)、Query String中的参数值，比如http://search.china.alibaba.com/search/offer_search.htm?keywords=中国
(2)、servlet path，比如：http://search.china.alibaba.com/selloffer/中国.html
2、出现乱码问题的原因主要是以下几方面：
(1)、浏览器：我们的客户端（浏览器）本身并没有遵循URI编码的规范（http://www.w3.org/International/O-URL-code.html）。
(2)、Servlet服务器：Servlet服务器的没有正确配置。
(3)、开发人员并不了解Servlet的规范和API的含义。
二、基础知识：
1、一个http请求经过的几个环节：
浏览器(ie firefox)【get/post】------------>Servlet服务器------------------------------->浏览器显示
编码 解码成unicode，然后将显示的内容编码 解码
(1) 浏览器把URL(以及post提交的内容)经过编码后发送给服务器。
(2) 这里的Servlet服务器实际上指的是由Servlet服务器提供的servlet实现ServletRequestWrapper，不同应用服务器的 servlet实现不同，这些servlet的实现把这些内容解码转换为unicode，处理完毕后，然后再把结果(即网页)编码返回给浏览器。
(3) 浏览器按照指定的编码显示该网页。
当对字符串进行编码和解码的时候都涉及到字符集，通常使用的字符集为ISO8859-1、GBK、UTF-8、UNICODE。
2、URL的组成:
域名:端口/contextPath/servletPath/pathInfo?queryString
说明：
1、ContextPath是在Servlet服务器的配置文件中指定的。
对于weblogic：
contextPath是在应用的weblogic.xml中配置。
<context-root>/</context-root>
对于tomcat：
contextPath是在server.xml中配置。
<Context path="/" docBase="D:/server/blog.war" debug="5" reloadable="true" crossContext="true"/>
对于jboos：
contextPath是在应用的jboss-web.xml中配置。
<jboss-web>
<context-root>/</context-root>
</jboss-web>
2、ServletPath是在应用的web.xml中配置。
<servlet-mapping>
<servlet-name>Example</servlet-name>
<url-pattern>/example/*</url-pattern>
</servlet-mapping>
2、Servlet API
我们使用以下servlet API获得URL的值及参数。
request.getParameter("name"); // 获得queryString的参数值(来自于get和post)，其值经过Servlet服务器URL Decode过的
request.getPathInfo(); // 注意：pathinfo返回的字符串是经过Servlet服务器URL Decode过的。
requestURI = request.getRequestURI(); // 内容为：contextPath/servletPath/pathinfo 浏览器提交过来的原始数据，未被Servlet服务器URL Decode过。
3、开发人员必须清楚的servlet规范：
(1) HttpServletRequest.setCharacterEncoding()方法 仅仅只适用于设置post提交的request body的编码而不是设置get方法提交的queryString的编码。该方法告诉应用服务器应该采用什么编码解析post传过来的内容。很多文章并没 有说明这一点。
(2) HttpServletRequest.getPathInfo()返回的结果是由Servlet服务器解码(decode)过的。
(3) HttpServletRequest.getRequestURI()返回的字符串没有被Servlet服务器decoded过。
(4) POST提交的数据是作为request body的一部分。
(5) 网页的Http头中ContentType("text/html; charset=GBK")的作用：
(a) 告诉浏览器网页中数据是什么编码；
(b) 表单提交时，通常浏览器会根据ContentType指定的charset对表单中的数据编码，然后发送给服务器的。
这里需要注意的是：这里所说的ContentType是指http头的ContentType，而不是在网页中meta中的ContentType。
如果没有设置charset的话，post默认是iso8859-1编码，get默认和浏览器设置有关，如果有charset的话，form表单会用charset设置的编码。
三、下面我们分别从浏览器和应用服务器来举例说明：
URL：http://localhost:8080/example/中国?name=中国
汉字 编码 二进制表示
中国 UTF-8 0xe4 0xb8 0xad 0xe5 0x9b 0xbd[-28, -72, -83, -27, -101, -67]
中国 GBK 0xd6 0xd0 0xb9 0xfa[-42, -48, -71, -6]
中国 ISO8859-1 0x3f,0x3f[63, 63]信息失去
(一)、浏览器
1、GET方式提交，浏览器会对URL进行URL encode，然后发送给服务器。
(1) 对于中文IE,如果在高级选项中选中总以UTF-8发送(默认方式)，则PathInfo是URL Encode是按照UTF-8编码,QueryString是按照GBK编码。
http://localhost:8080/example/中国?name=中国
实际上提交是：
GET /example/%E4%B8%AD%E5%9B%BD?name=%D6%D0%B9%FA
(1) 对于中文IE,如果在高级选项中取消总以UTF-8发送，则PathInfo和QueryString是URL encode按照GBK编码。
实际上提交是：
GET /example/%D6%D0%B9%FA?name=%D6%D0%B9%FA
(3) 对于中文firefox，则pathInfo和queryString都是URL encode按照GBK编码。
实际上提交是：
GET /example/%D6%D0%B9%FA?name=%D6%D0%B9%FA
很显然，不同的浏览器以及同一浏览器的不同设置，会影响最终URL中PathInfo的编码。对于中文的IE和FIREFOX都是采用GBK编码QueryString。
小结：解决方案：
1、URL中如果含有中文等非ASCII字符，则浏览器会对它们进行URLEncode。为了避免浏览器采用了我们不希望的编码，所以最好不要在URL中直接使用非ASCII字符，而采用URL Encode编码过的字符串%.
比如：
URL：http://localhost:8080/example/中国?name=中国
建议：
URL：http://localhost:8080/example/%D6%D0%B9%FA?name=%D6%D0%B9%FA
2、我们建议URL中PathInfo和QueryString采用相同的编码，这样对服务器端处理的时候会更加简单。
2、还有一个问题，我发现很多程序员并不明白URL Encode是需要指定字符集的。不明白的人可以看看这篇文档：http://gceclub.sun.com.cn/Java_Docs/html/zh_CN/api/java/net/URLEncoder.html
2、 POST提交
对于POST方式，表单中的参数值对是通过request body发送给服务器，此时浏览器会根据网页的ContentType("text/html; charset=GBK")中指定的编码进行对表单中的数据进行编码，然后发给服务器。
在服务器端的程序中我们可以通过Request.setCharacterEncoding() 设置编码，然后通过request.getParameter获得正确的数据。
解决方案：
1、从最简单，所需代价最小来看，我们对URL以及网页中的编码使用统一的编码对我们来说是比较合适的。
如果不使用统一编码的话，我们就需要在程序中做一些编码转换的事情。这也是我们为什么看到有网络上大量的资料介绍如何对乱码进行处理，其中很多解决方案都只是一时的权宜之计，没有从根本上解决问题。
(二)、Servlet服务器
Servlet服务器实现的Servlet遇到URL和POST提交的数据中含有%的字符串，它会按照指定的字符集解码。下面两个Servlet方法返回的结果都是经过解码的：
request.getParameter("name");
request.getPathInfo();
这里所说的"指定的字符集"是在应用服务器的配置文件中配置。
(1) tomcat服务器
对于tomcat服务器，该文件是server.xml
<Connector port="8080" protocol="HTTP/1.1"
maxThreads="150" connectionTimeout="20000"
redirectPort="8443" URIEncoding="GBK"/>
URIEncoding告诉服务器servlet解码URL时采用的编码。
<Connector port="8080" ... useBodyEncodingForURI="true" />
useBodyEncodingForURI告诉服务器解码URL时候需要采用request body指定的编码。
(2) weblogic服务器
对于weblogic服务器，该文件是weblogic.xml
<input-charset>
<java-charset-name>GBK</java-charset-name>
</input-charset>
(三)浏览器显示
浏览器根据http头中的ContentType("text/html; charset=GBK")，指定的字符集来解码服务器发送过来的字节流。我们可以调用 HttpServletResponse.setContentType()设置http头的ContentType。
总结：
1、URL中的PathInfo和QueryString字符串的编码和解码是由浏览器和应用服务器的配置决定的，我们的程序不能设置，不要期望用request.setCharacterEncoding()方法能设置URL中参数值解码时的字符集。
所以我们建议URL中不要使用中文等非ASCII字符，如果含有非ASCII字符的话要使用URLEncode编码一下，比如：
http://localhost:8080/example1/example/中国
正确的写法：
http://localhost:8080/example1/example/%E4%B8%AD%E5%9B%BD
并且我们建议URL中不要在PathInfo和QueryString同时使用非ASCII字符，比如
http://localhost:8080/example1/example/中国?name=中国
原因很简单：不同浏览器对URL中PathInfo和QueryString编码时采用的字符集不同，但应用服务器对URL通常会采用相同的字符集来解码。
-----自己的一些总结：
jsp编码相关-----------------------------
1. pageEncoding: 只是指明了 JSP 页面本身的编码格式，跟页面显示的编码没有关系;
容器在读取(文件)或者(数据库)或者(字符串常量)时将起转化为内部使用的 Unicode,而页面显示的时候将
内部的Unicode转换为contentType指定的编码后显示页面内容;
如果pageEncoding属性存在，那么JSP页面的字符编码方式就由pageEncoding决定，
否则就由contentType属性中的charset决定，如果charset也不存在，JSP页面的字符编码方式就采用
默认的ISO-8859-1。
2. contentType: 指定了MIME类型和JSP页面回应时的字符编码方式。MIME类型的默认值是“text/html”;
字符编码方式的默认值是“ISO-8859-1”. MIME类型和字符编码方式由分号隔开;
3. pageEncoding和contentType的关系:
1. pageEncoding的内容只是用于jsp输出时的编码，不会作为header发出去的; 是告诉web Server
jsp页面按照什么编码输出,即web服务器输出的响应流的编码;
2. 第一阶段是jsp编译成.java，它会根据pageEncoding的设定读取jsp，结果是由指定的编码方案翻译
成统一的UTF-8 JAVA源码（即.java）.
3. 第二阶段是由JAVAC的JAVA源码至java byteCode的编译，不论JSP编写时候用的是什么编码方案，
经过这个阶段的结果全部是UTF-8的encoding的java源码.JAVAC用UTF-8的encoding读取
java源码，编译成UTF-8 encoding的二进制码（即.class），这是JVM对常数字串在二进制码
（java encoding）内表达的规范.
4. 第三阶段是Tomcat（或其的application container）载入和执行阶段二的来的JAVA二进制码，
输出的结果，也就是在客户端见到的，这时隐藏在阶段一和阶段二的参数contentType就发挥了功效
4. 和contentType效果一样的设置方式还有 html页面charset, response.setCharacterEncoding(),
response.setContentType(),response.setHeader(); response.setContentType(),
response.setHeader();优先级最好,其次是response.setCharacterEncoding();再者是
<%@page contentType="text/html; chareset=gbk"%>,最后是<meta http-equiv="content-type"
content="text/html; charset=gb2312" />.
5. web页面输入编码: 在设置页面编码<%@page contentType="text/html; chareset=gbk"%>的同时，也就指定了页面的输入编码;
如果页面的显示被设置为UTF-8，那么用户所有的页面输入都会按照 UTF-8 编码; 服务器端程序在读
取表单输入之前要设定输入编码;
表单被提交后，浏览器会将表单字段值转换为指定字符集对应的字节值，然后根据 HTTP 标准 URL
编码方案对结果字节进行编码.但是页面需要告诉服务器当前页面的编码方式;
request.setCharacterEncoding(),能修改Serverlet获取请求的编码,response.setCharacterEncoding(),
能修改Serverlet返回结果的编码.
6;对于get方法表单通过设置 response.setCharacterEncoding(), 和request.setCharacterEncoding("utf-8")无效，
get有长度限制，最长不超过2048字节（1024个汉字）
注意编码要在获取写通道之前设置：
response.setContentType("text/html;charset=gbk");
PrintWriter out = response.getWriter();
如果写成如下将导致编码设置无效：
PrintWriter out = response.getWriter();
response.setContentType("text/html;charset=gbk");
在设置编码之前获取度通道将导致后期设置编码无效
System.out.println("997:"+request.getParameter("ta"));
request.setCharacterEncoding("utf-8");
System.out.println("999:"+request.getParameter("ta"));
正确如下：
request.setCharacterEncoding("utf-8");
System.out.println("999:"+request.getParameter("ta"));
-----------------------------2--
我补充一点：
为什么我们以前在servlet里面会用new String(request.getParameter("aaa").getBytes("ISO8859-1"),"gbk"); 这样来得到正确的中文呢？这是因为对于get传参，如果我们没有在tomcat里面配置编码格式，那么默认是用ISO8859-1来解码，但是我们的中文在传过来的时候是用gbk编码的，所以我们需要用ISO8859-1再编码一次，再用gbk解码，这个过程就是
gbk编码 -> servlet用ISO8859-1解码 -> 我们再用ISO8859-1编码，接着再gbk解码
这样我们就得到了正确的中文，不过这是不怎么好的解决方案。
另外还有一种情况就是JQuery的ajax使用post提交数据的时候，默认会调用encodeURIComponent对数据进行编码，而这个编码是utf-8的，所以当你的页面使用gbk，后台也使用gbk的时候，ajax传上来的参数会是乱码，这时候有两种解决方法
1. 在后台用上面的二次解码的方法进行解码
2. 在jquery.post调用时增加参数contentType: "application/json; charset=gbk"
最好的就是建议统一使用utf-8国际编码方式。
另补充一种情况：
使用jQuery(form).ajaxSubmit 提交的时候，默认都是UTF-8编码，这个不受jsp页面的ContentType的限制，例如我设置的是GBK，可是form提交还是UTF-8，这是因为contentType默认是 "application/x-www-form-urlencoded; charset=utf-8",但是如果我的form设置了enctype="multipart/form-data" 并且有提交文件的话，这个时候请求的编码就和ContentType配置的一样了。
最终总结：
1. Form表单提交，如果设置了ContentType,则不管是POST还是GET都按这个配置编码，如果没有配置，则POST默认是 ISO-8859-1,GET则和当前环境有关，一般是GBK.
2. 如果是Ajax，默认是UTF-8,这个可以通过设置Ajax属性contentType来改变，但是如果设置了enctype="multipart/form-data", 则没有办法改变编码方式 ，提交时将和上面form表单提交一样。
3. 服务器端的编码方式默认是ISO-8859-1,改通过修改服务器的配置文件来修改get的编码方式。
可能过设置request.setCharacterEncoding("utf-8");或是struts的xml配置文件里面配置来改变post的编码方式。
4. 设置JSP源文件字符集时,优先级为pageEncoding>contentType。如果都没有设置，默认ISO-8859-1。
设置响应输出的字符集时,优先级为contentType>pageEncoding>meta。如果都没有设置，默认ISO-8859-1。
post提交的字符集，contentType>meta
5. 补充最近遇到的一个问题，页面设置了contentType="text/html; charset=utf-8" pageEncoding="utf-8"，tomcat端设置了编码是utf-8，也就是说页面提交不管post还是get肯定都是utf-8，服务器端对于get请求也是用utf-8. 对于post我也没配置，前端开始只有两种提交方式，一种是form表单，采用ajaxSubmit提交，中文正常，一种是ajax通过get提交，中文也正常，后来增加了一种方式：form表单直接提交，结果服务端获取中文乱码。在过滤器中增加了request.setCharacterEncoding("utf-8");后就正常了。分析发现，get是肯定正常的，因为客户端和服务端都是utf-8，而通过ajaxSubmit提交的时候在request header里面会有一个contentType参数指定为utf-8，服务器就会按utf-8解码，而form表单直接提交的时候，request header 里面没有相应的参数，这时候如果服务端设置了request.setCharacterEncoding就会按设置的编码解码，如果没有设置 就会按默认的ISO-8859-1解码，这时候就乱码了。
3348
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
