专家讲述J2EE中的多字节字符的处理 （5）

服务器配置阶段

在运行J2EE应用之前，一般会根据特定的需要对应用进行配置。在上一节中，我们发现不同的语言设置会导致文字字符串显示出问题。实际上配置存在于不同的层面，它们都可能会引发多字节字符问题。

操作系统层

操作系统对语言的支持非常重要。前面提到服务器端对语言的支持会影响JVM默认的编码设置，而在客户端的语言支持（如字体）也能直接影响字符的显示，但这不是本文要讨论的重点。

J2EE应用服务器层

大多数服务器都有一个基本服务器设置，可用来配置默认的字符编码处理方式。清单2就是Tomcat配置文件的一部分（位于$TOMCAT_HOME/conf/web.xml）。

清单2 web.xml

<servlet>        
<servlet-name>jsp</servlet-name>        <servlet-class>org.apache.jasper.
servlet.JspServlet</servlet-class>        
<init-param>            
<param-name>fork</param-name>            <param-value>false</param-value>        
</init-param>        
<init-param>            
<strong>           
<param-name>javaEncoding</param-name>>            <param-value>>UTF8</param-value>            
</strong>        
</init-param>        
<load-on-startup>3</load-on-startup>  
</servlet>

Tomcat以参数javaEncoding来确定从JSP文件生成Java源文件的Java文件编码方式。这里的默认值是UTF-8，这意味着如果JSP文件中的中文字符以GBK编码保存，将会以UTF-8编码（浏览器端设置）显示，在这种情况下就可能会出问题。

JVM层

大多数服务器都允许同时运行多个实例，且每个服务器实例都能有自己的JVM实例。此外，还可对每一个JVM实例分别设置。大多数服务器用本地设置来为每个实例定义默认的语言支持。

图5显示的是Sun ONE（开放网络环境）应用服务器的一个本地单个实例设置。该设置给出了登录系统和标准输出的默认字符编码方式。

此外，不同的服务器使用的JVM版本可能会不同，而不同的JDK版本支持的编码标准各异，所有这些都会导致迁移问题。例如Sun ONE应用服务器与Tomcat都支持J2SE 1.4，而有些服务器只支持到J2SE 1.3。J2SE 1.4支持Unicode 3.1，它具有许多早期版本所没有的新特性。

单个应用层

每个部署在服务器上的应用在运行前都可以为其配置独立的编码设置，这就使得在同一个服务器实例上能够运行多个采用不同语言的应用。一些服务器用以下的字符编码设置为每个部署的应用指定其应使用的编码方式：

<locale-charset-info default-locale="en_US">      
</locale-charset-map locale="zh_CN" 
agent="Mozilla/4.77 
[en] (Windows NT 5.0; U)"  
charset="GBK"></locale-charset-info>

这种分层配置的目的是为了灵活性和可维护性。但不幸的是，当在服务器间迁移时这种做法就可能导致出问题，因为并非所有的服务器配置都遵循标准。比如说，如果在一个支持本地字符集设置的服务器上开发了应用，那么当把该应用迁移到另一个不支持这种编码设置的服务器上时就可能会遇到问题。