站内搜索: 请输入搜索关键词

当前页面: 开发资料首页J2EE 专题Charset in J2EE Web Application

Charset in J2EE Web Application

摘要: 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”编码的数据转换成“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.sendRediret(str_url.getBytes(“Shift_JIS“), “ISO8859_1“);

我有一个建议,那就是在进行字符集转换时,最好明确地写出源字符集和目的字符集,因为如果省略不写的话,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的乱码问题折磨的朋友们能从这篇文章中得到一些启示。



↑返回目录
前一篇: J2EE设计模式学习笔记之--用实体组件进行数据存取
后一篇: Oracle9iAS下J2EE应用程序部署