运行环境：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”编码的数据转换成“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”等双字节字符集中的字符的高8位是有值的），所以我们在JSPs中取得请求数据后，一般要将该数据转换后才不会出现乱码情况。我们需要在JSPs中做类似下面的转换：
String reqParamA = new String((request.getParameter(“txt_a“)).getBytes(“ISO8859_1“), “Shift_JIS“);
但是在向客户端输出数据时，则不需要再做转换，直接将“Shift_JIS”对应的Unicode字符串向客户端输出即可。
上面描述的是从客户端向服务器发出请求到服务器端向客户端发回响应，客户端接收到响应并最终显示HTML页面的典型流程，但是也有些例外需要注意：
通过调用response.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所获取的数据流的编码形式就是该文件的字符集所对应的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，则服务器端接收到的就是正常的“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的乱码问题折磨的朋友们能从这篇文章中得到一些启示。
