Jsp乱码解决,对比resin和tomcat

JSP页面声明中有pageEncoding和contentType两种属性，两者之间的区别：

  pageEncoding是jsp文件本身的编码

  contentType的charset是指服务器发送给客户端时的内容编码

 

 

从我们编写代码，到前台显示，从编码改变的角度，应该分为3个阶段：

第一阶段，jap ==> .java   这一阶段的编码改变是由pageEncoding的设定值从jsp读取，结果由pageEncoding的值指定的编码方案翻译成统一的UTF-8编码的java源码（事实上，所有的jsp都会编译成一个servlet保存在服务器段），这是一个可以导致中文乱码的地方，需要注意。

第二阶段，.java ==> .class   这一阶段的编码基本不会出现乱码，因为都是utf-8 到 utf-8的。其实就是.java文件编译成字节码的过程。

第三阶段，是容器载入和执行.class文件之后，渲染到前台页面的时候，这时候，在编写代码时候写下的contentType就有作用了，这个属性是指定执行的.class文件渲染到客户端时候用的编码方案。如果第一阶段有中文字符，建议pageEncoding采用utf-8或者gbk，两者能够很好地处理，这样就避免了在前面两个阶段出现乱码。

 

 

对比Tomcat 和 Resin

        个人一直用tomcat来作为网站容器进行调试，后来因为需求，不得不接触Resin容器，了解到Resin对乱码的解决很有效果。但是一直受困扰啊，非常无奈。终于了解了原理，经过对比，写下下面的笔记。

 

 

        个人接触tomcat的时候，一直是6.0.X版本，所以，tomcat对于pageEncoding和contentType的设定是，指定了pageEncoding，就默认把contentType的值设定为前者的值。而Resin的版本就比较多变动，因为租用的空间是用resin 3.0.23版本，个人用的是resin 4.0.23版本，得到一个比较重要的经验是4.0.X版本的，对pageEncoding和contentType的处理，和tomcat 6.0.X的处理方式相同，所以可以得到正确的值，而3.0.X版本的就需要主动指定两者，如果只指定其中一个，那另外一个会按照默认的编码方案进行编码。

 

 

摘录一段详细的解说：

jsp文件不像.java，.java在被编译器读入的时候默认采用的是操作系统所设定的locale所对应的编码，比如中国大陆就是GBK，台湾就是BIG5或者MS950。而一般我们不管是在记事本还是在ue中写代码，如果没有经过特别转码的话，写出来的都是本地编码格式的内容。所以编译器采用的方法刚好可以让虚拟机得到正确的资料。

但是jsp文件不是这样，它没有这个默认转码过程，但是指定了pageEncoding就可以实现正确转码了。

举个例子:

<%@ page contentType="text/html;charset=utf-8" %>

大都会打印出乱码，因为输入的“你好”是gbk的，但是服务器是否正确抓到“你好”不得而知。

但是如果更改为

<%@ page contentType="text/html;charset=utf-8" pageEncoding="GBK"%>

这样就服务器一定会是正确抓到“你好”了。