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,由于=号多了空格,始终乱码