jsp，servlet乱码总结

html传过来的中文在jsp或servlet中乱码，可以再server.xml中的端口(如8080)这里加属性URIEncoding=”gbk”即可。另外如果用到struts2，struts2默认编码是utf-8，则server.xml属性改URIEncoding=” utf-8”

Java的内核和class文件是基于unicode的，这使Java程序具有良好的跨平台性，但也带来了一些中文乱码问题的麻烦。原因主要有两方面，Java和JSP文件本身编译时产生的乱码问题和Java程序于其他媒介交互产生的乱码问题。  　　首先Java（包括JSP）源文件中很可能包含有中文，而Java和JSP源文件的保存方式是基于字节流的，如果Java和JSP编译成class文件过程中，使用的编码方式与源文件的编码不一致，就会出现乱码。基于这种乱码，建议在Java文件中尽量不要写中文（注释部分不参与编译，写中文没关系），如果必须写的话，尽量手动带参数－ecoding GBK或－ecoding gb2312编译；对于JSP，在文件头加上<%@ page contentType="textml;charset=GBK"%>或<%@ page contentType="textml;charset=gb2312"%>基本上就能解决这类乱码问题。  　　本文要重点讨论的是第二类乱码，即Java程序与其他存储媒介交互时产生的乱码。很多存储媒介，如数据库，文件，流等的存储方式都是基于字节流的，Java程序与这些媒介交互时就会发生字符(char)与字节(byte)之间的转换，例如从页面提交表单中提交的数据在Java程序里显示乱码等情况。     如果在以上转换过程中使用的编码方式与字节原有的编码不一致，很可能就会出现乱码。

JSP文件执行的过程  

第一阶段是jsp编译成.java，它会根据pageEncoding的设定读取jsp，结果是由指定的编码方案翻译成统一的UTF-8 JAVA源码（即.java），如果pageEncoding设定错了，或没有设定，出来的就是中文乱码。 

第二阶段是由JAVAC的JAVA源码至java byteCode的编译，不论JSP编写时候用的是什么编码方案，经过这个阶段的结果全部是UTF-8的encoding的java源码。 JAVAC用UTF-8的encoding读取java源码，编译成UTF-8 encoding的二进制码（即.class），这是JVM对常数字串在二进制码（java encoding）内表达的规范。 

第三阶段是Tomcat（或其的application container）载入和执行阶段二的来的JAVA二进制码，输出的结果，也就是在客户端见到的，这时隐藏在阶段一和阶段二的参数contentType就发挥了功效

所以表单中或传递字符串：本来输入的汉字是正常的，但是提交后再显示出来是乱码，因为提交后通过tomcat用reques.getParameter方法获取数据时，服务器的编码方式默认是 ISO8859编码，所以显示的时候要转成GB2312编码

(1) windows平台默认字符集GBK 

(2) IE浏览器默认采用UTF-8字符集

(3) Tomcat在处理请求时采用ISO-8859-1编码

可以用以下两种方法解决乱码，但只针对post传送的数据

1、request.setCharacterEncoding("gbk");

2、studentName=new String(request.getParameter("sName").getBytes("8859_1"));

针对get，可以在server.xml加属性URIEncoding=”gbk”，如不行，gbk或utf-8

另外以下代码

<%@ page language="java" contentType="textml; charset=GB2312"

    pageEncoding="GB2312"%>

如果2个属性都去除，网页有中文就会出现问题

而随便设定了其中一个, 另一个就跟着一样了

对于get方式：

setCharacterEncoding("gbk")是没用的，得在server.xml加属性URIEncoding=”gbk”

tomcat7对语句结构控制更严？ 如 "charset = gb2312" 写法在6中完全可执行，到7,由于=号多了空格，始终乱码