JSP页面提交后中文字符出现乱码

JSP页面提交后中文字符出现乱码-tomcat下中文乱码问题项目和页面都已设成了UTF-8编码形式；
解决方法：1） 设定请求的字符编码request.setCharacterEncoding("UTF-8");
2） 指定过滤类
这些天开发一个项目，服务器是tomcat,操作系统是xp,采用的是MVC架构，模式是采用 Facade模式，总是出现乱码，自己也解决了好多天，同事也帮忙解决，也参考了网上众多网友的文章和意见，总算是搞定。但是好记性不如烂笔杆，所以特意记下，以防止自己遗忘，同时也给那些遇到同样问题的人提供一个好的参考途径：

(一) JSP页面上是中文，但是看的是后是乱码：
解决的办法就是在JSP页面的编码的地方<%@ page language="java" contentType="text/html;charset=GBK" %>，因为Jsp转成Java文件时的编码问题，默认的话有的服务器是ISO-8859-1，如果一个JSP中直接输入了中文，Jsp把它当作 ISO8859-1来处理是肯定有问题的，这一点，我们可以通过查看Jasper所生成的Java中间文件来确认

(二) 当用Request对象获取客户提交的汉字代码的时候，会出现乱码：
解决的办法是：要配置一个filter,也就是一个Servelet的过滤器，代码如下：
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.UnavailableException;

/**
* Example filter that sets the character encoding to be used in parsing the
* incoming request
*/
public class SetCharacterEncodingFilter implements Filter {

/**
* Take this filter out of service.
*/
public void destroy() {
}
/**
* Select and set (if specified) the character encoding to be used to
* interpret request parameters for this request.
*/
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)throws IOException, ServletException {

request.setCharacterEncoding("GBK");

// 传递控制到下一个过滤器
chain.doFilter(request, response);
}

public void init(FilterConfig filterConfig) throws ServletException {
}
}
配置web.xml
<filter>
<filter-name>Set Character Encoding</filter-name>
<filter-class>SetCharacterEncodingFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>Set Character Encoding</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
如果你的还是出现这种情况的话你就往下看看是不是你出现了第四中情况，你的Form提交的数据是不是用get提交的，一般来说用post提交的话是没有问题的，如果是的话，你就看看第四中解决的办法。
还有就是对含有汉字字符的信息进行处理，处理的代码是：
package dbJavaBean;

public class CodingConvert
{
public CodingConvert()
{
//
}
public String toGb(String uniStr){
String gbStr = "";
if(uniStr == null){
uniStr = "";
}
try{
byte[] tempByte = uniStr.getBytes("ISO8859_1");
gbStr = new String(tempByte,"GB2312");
}
catch(Exception ex){
}
return gbStr;
}

public String toUni(String gbStr){
String uniStr = "";
if(gbStr == null){
gbStr = "";
}
try{
byte[] tempByte = gbStr.getBytes("GB2312");
uniStr = new String(tempByte,"ISO8859_1");
}catch(Exception ex){
}
return uniStr;
}
}
你也可以在直接的转换，首先你将获取的字符串用ISO-8859-1进行编码，然后将这个编码存放到一个字节数组中，然后将这个数组转化成字符串对象就可以了，例如：
String str=request.getParameter(“girl”);
Byte B[]=str.getBytes(“ISO-8859-1”);
Str=new String(B);
通过上述转换的话，提交的任何信息都能正确的显示。
(三) 在Formget请求在服务端用request. getParameter(“name”)时返回的是乱码；按tomcat的做法设置Filter也没有用或者用 request.setCharacterEncoding("GBK");也不管用问题是出在处理参数传递的方法上：如果在servlet中用 doGet(HttpServletRequest request, HttpServletResponse response)方法进行处理的话前面即使是写了：
request.setCharacterEncoding("GBK");
response.setContentType("text/html;charset=GBK");
也是不起作用的，返回的中文还是乱码！！！如果把这个函数改成doPost(HttpServletRequest request, HttpServletResponse response)一切就OK了。
同样，在用两个JSP页面处理表单输入之所以能显示中文是因为用的是post方法传递的，改成get方法依旧不行。
由此可见在servlet中用doGet()方法或是在JSP中用get方法进行处理要注意。这毕竟涉及到要通过浏览器传递参数信息，很有可能引起常用字符集的冲突或是不匹配。
解决的办法是：
1) 打开tomcat的server.xml文件，找到区块，加入如下一行：
URIEncoding=”GBK”
完整的应如下：
<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8443" acceptCount="100" debug="0" connectionTimeout="20000" disableUploadTimeout="true" URIEncoding="GBK"/>

2)重启tomcat,一切OK。
需要加入的原因大家可以去研究 $TOMCAT_HOME/webapps/tomcat-docs/config/http.html下的这个文件就可以知道原因了。需要注意的是：这个地方如果你要是用UTF-8的时候在传递的过程中在Tomcat中也是要出现乱码的情况，如果不行的话就换别的字符集。

(四) JSP页面上有中文，按钮上面也有中文，但是通过服务器查看页面的时候出现乱码：
解决的办法是：首先在JSP文件中不应该直接包含本地化的消息文本，而是应该通过<bean:message>标签从Resource Bundle中获得文本。应该把你的中文文本放到Application.properties文件中，这个文件放在WEB-INF/classes/* 下，例如我在页面里有姓名，年龄两个label,我首先就是要建一个Application.properties，里面的内容应该是name=”姓名” age=”年龄”,然后我把这个文件放到WEB-INF/classes/properties/下，接下来根据 Application.properties文件，对他进行编码转化，创建一个中文资源文件，假定名字是 Application_cn.properties。在JDK中提供

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/taochenpfj/archive/2009/07/24/4375751.aspx