《response传值乱码问题.doc》由会员分享，可在线阅读，更多相关《response传值乱码问题.doc（3页珍藏版）》请在金锄头文库上搜索。
1、Charset in J2EE Web Application运行环境：Win2K Pro日文版，SUN J2SDK 1.4.2_04, Tomcat 4.1.27，JSPs由于在Tomcat下，从request中(比如通过request.getParameter(String)方法)取得的数据都是ISO8859_1对应的Unicode字符串（我猜想整个过程应该是这样的：假设HTML的Encoding为Shift_JIS，那么IE将form中的Shift_JIS编码的各input控件的值转换成ISO8859_1编码的数据流发送给Tomcat，然后Tomcat再将这些以ISO8859_1编码的数
2、据转换成ISO8859_1对应的Unicode数据并通过request对象传递给我们的JSPs；JSPs完成了自己的处理后，最后将Shift_JIS对应的Unicode通过response对象传递给Tomcat，然后Tomcat再将这些数据转换成ISO8859_1的数据流传回给客户端的IE，然后IE再将接收到的ISO8859_1编码的数据转换成Shift_JIS编码的数据并最终显示成HTML页面。之所以要在客户端与服务器端之间用ISO8859_1编码来进行通信，可能是为了防止双字节字符的高8位被某些网络服务器忽略从而造成数据丢失，因为ISO8859_1编码的字符只有8位长，而Shift_JIS
3、等双字节字符集中的字符的高8位是有值的），所以我们在JSPs中取得请求数据后，一般要将该数据转换后才不会出现乱码情况。我们需要在JSPs中做类似下面的转换：String reqParamA = new String(request.getParameter(txt_a).getBytes(ISO8859_1), Shift_JIS);但是在向客户端输出数据时，则不需要再做转换，直接将Shift_JIS对应的Unicode字符串向客户端输出即可。上面描述的是从客户端向服务器发出请求到服务器端向客户端发回响应，客户端接收到响应并最终显示HTML页面的典型流程，但是也有些例外需要注意：通过调用res
4、ponse.sendRedirect(str_url)，在服务器端直接重定向到另一个URL时。假如str_url中包含了queryString(比如someUrl?paramA=包含双字节字符的字符串mB=包含双字节字符的字符串.)，那么必须对str_url做类似下面的转换，否则映射到目的URL的JSPs取得的请求数据就都是乱码（因为就像上面所说的，它们所期望的请求数据应该是ISO8859_1所对应的Unicode字符串）：response.sendRediret(str_url.getBytes(Shift_JIS), ISO8859_1)；文件上传。此时服务器端的JSPs所获取的数据流的编
5、码形式就是该文件的字符集所对应的Unicode数据流。比如在Win2K Pro日文版下，一个.csv文件的编码就是MS932，那么当它被上传到服务器端时，JSPs所获取的数据流就是MS932对应的Unicode数据流。假设此时的运行环境为Win2K Pro日文版 + VOBSEnhydra 5.1SE，当在客户端JavaScript里通过window.showModalDialog()(该ModalDialog内的HTML的Encoding为Shift_JIS)向服务器端发出请求时，服务器端接收到的请求数据却是MS932对应的Unicode字符串；但是假如使用Tomcat 4.1.27，则服务
6、器端接收到的就是正常的ISO8859_1对应的Unicode字符串），一直未能查出原因。我有一个建议，那就是在进行字符集转换时，最好明确地写出源字符集和目的字符集，因为如果省略不写的话，Java会采用系统默认字符集来处理，而不同的OS的默认字符集通常都是不一样的，这样就很可能会出现同一个J2EE Web App在WinNT/2K/XP下运行正常，但是一移植到Unix/Linux下就出乱码的问题。推荐的写法 ：String str = new String(str.getBytes(GB2312), ISO8859_1); /假设str的原始编码就是GB2312，与OS无关不推荐的写法：String str = new String(str.getBytes(), ISO8859_1); /假设str的原始编码就是GB2312，与OS无关愿仍在被J2EE Web Application的乱码问题折磨的朋友们能从这篇文章中得到一些启示。
