uage=“Java” contentType=“text/html; charset=gb2312”%>,而页面中的
语句起了作用,此时可以正常显示。相反,如果加上<%@ page language=“java” contentType=“text/html; charset=gb2312”%>系统会报错,说明Tomcat 4以上版本的引擎在处理JSP时还是有差别的。
另外,对于不同的数据库如SQL Server,Oracle,Mysql,Sybase等,字符集的选择很重要。如果考虑多语言版本,数据库的字符集就应该统一采用ISO8859-1,需要输出的时候在不同的字符集之间做转换就可以了。
以下是针对不同平台的总结:
(1) JSWDK只适合于普通开发,稳定性和其他问题可能不如商业软件。 由于JDK 1.3版性能要好于JDK 1.2.2很多,并且对中文的支持也较好,所以应该尽量采用。
(2) 作为免费的商业
软件,Resin不仅速度快、稳定、自动编译,还可以指出出错行,并可在服务器端支持使用JavaScript等,而且对中文的支持也很好。
(3) Tomcat仅仅是一个对JSP 1.1、Servlet 2.2标准的实现, 我们不应该要求这个
免费软件在细节和性能上都面面俱到, 它主要考虑英文用户, 这也是为什么不做特殊转换,汉字用URL方法传递就有问题的原因。大部分IE浏览器缺省始终以UTF-8发送, 这似乎是Tomcat的一个不足, 另外Tomcat不管当前的操作系统是什么语言, 都按ISO8859去编译
JSP, 似乎也欠妥。
JSP代码的中文处理
在JSP代码中以下几处经常需要涉及到中文处理:
1. 在URL中附带中文参数。这里中文参数通常可以直接读取,例如: <%= request.getParameter(“showword”)%>
2. 在JSWDK中读取
HTML表单提交的中文值这时需要加以编
码,较为简洁的写法是:
String name1=new String(request.getParameter(“user_id”).getBytes(“ISO8859_1”))。
另外,在JDK 1.3的支持下,不需加入<%@ page contentType=“text/html;charset=gb2312”%> ,而在JDK 1.2.2 以下,即使以上两种方法同时运用也很不稳定。但在Resin平台,情况较好,只要在页面第一行加入:<%@ page contentType=“text/html;charset=gb2312”%>即可正确处理中文,如果再加代码则反而不对。
3.在JSWDK中Session包含的中文,如果从表单中读出的值经过编码可正确显示,但直接赋予中文值则不行,而Resin平台则很好。
4. 在编译Servlet和JSP时加入代码选项。在编译Servlet时使用Java-Encoding ISO8859-1 myservlet.java;在JSP的ZONE配置文件中,修改编译参数为:Compiler=builtin - javac- encoding ISO8859-1。使用这种方法后,不需要做其他的改动就可以正常显示中文了。
另外,流行的关系数据库系统都支持数据库Encoding,也就是说在创建数据库时可以指定它自己的字符集设置,数据库的数据以指定的编码形式存储。当应用
程序访问数据时,在入口和出口处都会有 Encoding 转换。对于中文数据,数据库字符编码的设置应当保证数据的完整性。 GB2312、GBK、UTF-8 等都是可选的数据库 Encoding,也可以选择 ISO8859-1 (8-bit), 但会增加了编程的复杂度,ISO8859-1不是推荐的数据库 Encoding。在JSP/Servlet编程时,可以先用数据库
管理系统提供的管理功能检查其中的中文数据是否正确。
处理方法实例
下面是两个具体的中文乱码解决实例,读者仔细研究后可能会有所收获。
1.常见的字符转换方法
将Form 中 的 值 传 送 到 数 据 库 中 再 取 出 来 后 全 变 成 了“?”。Form用POST提交数据,代码中使用了语句:String st=new(request.getParameter(“name”).getBytes(“ISO8859_1”)), 而且也声明了charset=gb2312。
要处理Form中传递的中文参数,应该在JSP中加入下面的代码,另外定义一个专门解决这个问题的getStr类,然后对接收到的参数进行转换:
String