antonlan998

J2EE 的中文问题的出现纠其原因是因为从源到目标的字符集或者编码的不一致造成的。要实现字符集或者编码的一致，源（即动作的发起者）的字符集要大于或者等于目标的字符集。例如，如果数据库的字符集是 gb2312 ，那么 JSP 的字符集可以是 gb2312 、 gbk 或者是 UTF8 ，这里 UTF8 的字符集最大，可以认为它包含 gbk 和 gb2312 ，而 gbk 包含 gb2312 。相反是不可以的，即如果源是 gb2312 ，目标是 gbk 或者 UTF8 ，但经过笔者测试， gb2312 和 gbk 是可以通用的。

由于 J2EE 是三层架构体系，所以字符集的设置在客户端、中间层以及数据库都是必要的，只不过有些软件在安装的时候就已经设置了默认的中文字符集，所以我们有时不需要修改字符集设置就可以实现中文字符在前后台的交互。而有些软件默认的不是中文字符集，那就需要我们自己来进行设置。下面就介绍一下在三个层次上设置字符集需要注意的地方。

一、 数据库层

现在主流的数据库大部分的默认安装都会将字符集设为 GBK ，这样从该数据库提供的命令行工具或者其他第三方的 sql 工具对中文操作就都不会有问题。需要提一点的是 mysql ，它的默认字符集并不是 GBK ，这就需要修改配置，可以修改 my.ini 也可以使用 mysql 提供的配置工具进行修改，需要注意的是在建表的时候，还要将字符集在建表语句中写入。

还要注意的是，如果是使用第三方的 sql 工具，该工具支持的字符集也要和数据库匹配的，很可能是用该工具对中文的操作都是正常的，但到 java 程序中或者用数据库的命令行工具中却是乱码。

笔者还遇到一个情况，如果数据库的字符集设置为 UTF8 ，用 sql 是插入不了中文的，只能通过 java 程序运行的 sql 才可以。

二、 中间层

这里笔者把中间层广泛定义为应用服务器和编程上下文环境，有些应用服务器需要配置正确的字符集才可以传输中文（ WAS 、 Tomcat 等），而编程环境又分为 IDE （ Jbuilder 、 Elicpse 、 WSAD 等）、开源框架（ WebWork 、 Hibernate 等）和 JDBC 的字符集设置。

三、 客户端

这里主要指的是 JSP ，每个 JSP 都要字符集设置，在 JSP 头部

<%@ page contentType="text/html;charset=GBK"%> ；在 HTML 头部

<meta http-equiv="Content-Type" content="text/html; charset=GBK">

所以中文问题的出现很可能是上述某个环节没有正确配置导致的，我们要根据中文问题出现的情况具体问题具体分析。

1、              如果是页面本身的中文元素在浏览器中显示为乱码，那应该是没有在 JSP 加相应的字符集设置；

2、              页面传入程序上下文环境的初始数据为乱码，这步可以用调试和输出控制台的方式来检查数据进入到程序上下文环境是否发生了变化。如果出现乱码，很可能是开发框架或者是 IDE 的字符集需要设置，比如 webwork ，就需要在源程序的根目录的 webwork.propertites 文件中做如下的修改 webwork.locale=zh_CN webwork.i18n.encoding=GBK ，这个字体要与传入的字符集一致。有些 IDE 使用的操作系统的字符集，这样的话还有一种方式是经常采用的，就是加字符集转化的 Filter 。

3、              如果是从数据库中读出的中文数据在页面中显示为乱码，那很可能是 JDBC 的连接串需要字符集设置，这里需要重点指出的是用 xml 配置 url 时 & 符号在 xml 中用 &amp; 表示。也可能是数据库字符集没有正确设置，还有可能使通过其他途径插入数据库的数据的字符集不正确；

4、              如果以上情况都做了修改后仍不能解决中文问题，那就很可能是要在应用服务器上加字符集参数了。