首先设置 eclipse 下 jsp java 文件的默认编码
window-preference 如下图1：
此时 所有 jsp java都会按照这个默认的编码进行编写。
错误排查：
1、如果一个jsp 在eclipse里面看到的就是乱码了，那么肯定是因为后面有人改了上面的eclipse里面jsp的默认编码、
查看该jsp属性 如下图2：
看到这个jsp的编码为gbk的 那么如果jsp出现乱码 那么以前jsp默认编码肯定不是gbk的编码，
2、如果客户端页面出现乱码，排查jsp生成的servlet临时文件时否正确输入 ，按照不同服务器tomcat jboss 等等响应的位置，
查看jsp-servlet是否正确如图3：
如果生成不正确 就要排查该文件的encoding,或者 web.xml内是否配置了全局的jsp encoding 的代码
例如：
<jsp-config>
<jsp-property-group>
<description>
Special property group for JSP Configuration JSP
example.
</description>
<display-name>JSPConfiguration</display-name>
<url-pattern>*.jsp</url-pattern>
<el-ignored>true</el-ignored>
<page-encoding>GBK</page-encoding>
<scripting-invalid>false</scripting-invalid>
<include-prelude></include-prelude>
<include-coda></include-coda>
</jsp-property-group>
</jsp-config>
3、测试修改 如果修改eclipse默认编码，源文件 变成了乱码
如果修改文件属性，文件也变成了乱码
4、编码转换，在windows下 进行编码转换 他都是先把源文件复制出来到内存 这时候是从文件编码charsetA 先转换成
unicode编码，然后再转换成新的编码charsetB.此操作不一定可逆。例如charsetA存在uncode没有的编码,例如
gbk -〉 unicode 0x80,0x80 unicode没有这个编码 那么就会使 /ufffff 也就是？ 这时候再转换成charsetB 永远也
会知道他原来内容到底是什么了。
5、文件属性与内置 pageencoding 不一样，这样是非常严重的，就会发生第2种情况，因为jvm在编译过程当中，他是根据
pageencoding来解析文件的例如 本来是gbk编码的文件 非要pageencoding写成utf-8 那么它就会先将文件转换成unicode
0x81,0x87 例如这个在中文gbk里面代表“高” 那么jvm会按照utf-8的标准来解析成为unicode
字符，可能就会使别的字符“ҵ”，也可能没有 “�”
所以在编译成servlet的时候就已经出错了。
6、为什么将文件乱码内容复制出来，在文本编辑器例如 ultraediter修改好了再复制回eclipse文件去就行了？
因为将乱码复制出来到内存时候他已经是unicode编码了，到Ultralediter修改成某种正确的中文编码gbk gb2312 等等
无所谓，然后再复制出来是正确内容的uncode编码，然后再复制回eclipse jsp文件转换成相应正确的字符，就是正确的
7、返回页面编码不正确，jsp charset设置的是GBK，但是setencodingfilter里面统筹设置
接受request全部变成utf-8 这样就会在action接受的时候数据都变成乱码了，因为ie会按照
服务器charset编码对提交数据进行编码，而服务器又将这些编码信息用setencodingfilter又
设置了一次，所以 如果charset与setencodingfilter编码不同，就会出现类似4那种情况了
