Redhat5 Weblogic9.2下部署Java程序中文乱码问题研究

我在将应用程序部署到RedHat5上的WebLogic(Websphere)时，采取的解决方案：
1.在JVM中文字符集中添加中文字体支持
在/usr/share/fonts
目录中新建zh_CN/TrueType文件目录
将zysong.ttf字库拷贝至/usr/share/fonts/zh_CN/TrueType目录下

在JAVA_HOME下找到lib/fonts目录
Websphere 6.1在linux AS5中的目录是/opt/IBM/WebSphere/AppServer/java/jre/lib/fonts
(WebLogic类似找到其使用JRE下的目录)
在/opt/IBM/WebSphere/AppServer/java/jre/lib/fonts下面新建fallback文件夹
拷贝zysong.ttf拷贝至/opt/IBM/WebSphere/AppServer/java/jre/lib/fonts/fallback下

2.在应用程序WEB-INF下添加weblogic.xml

<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "weblogic810-web-jar.dtd">
<weblogic-web-app>
  <jsp-descriptor>
    <jsp-param>
      <param-name>compileFlags</param-name>
      <param-value>-g</param-value>
    </jsp-param>
    <jsp-param>
      <param-name>compilerSupportsEncoding</param-name>
      <param-value>true</param-value>
    </jsp-param>
    <jsp-param>
      <param-name>encoding</param-name>
      <param-value>GBK</param-value>
    </jsp-param>
    <jsp-param>
      <param-name>workingDir</param-name>
      <param-value>/home/webdev/barcelona/WEB-INF/workingdir/</param-value>
    </jsp-param>
  </jsp-descriptor>
  <charset-params>
    <input-charset>
      <resource-path>/*</resource-path>
      <java-charset-name>GBK</java-charset-name>
    </input-charset>
  </charset-params>
  <context-root></context-root>
</weblogic-web-app>

3.修改RedHat5中locale编码，该编码需与你所部署应用程序采取的编码一致
将/etc/sysconfig/i18n里面的设定改为:

LANG="zh_CN.GBK"

并且在/etc/profile加入:

export LANG="zh_CN.GBK" 
export LANGUAGE="zh_CN.GBK" 
export LC_ALL="zh_CN.GBK"
export LC_CTYPE="zh_CN.GBK"

然后sh /etc/sysconfig/i18n;sh /etc/profile
重新登陆,问题解决
说明：只是简单的 export LANG="zh_CN.GBK"，重启RedHat后无效


参考
引用原文：http://piaoyaohou.iteye.com/blog/478347

摘  要：在一个项目的开发中，我用linux内核源代码和busybox源代码自己编译打造的操作系统mylinux 1.0 ，服务器是我用java语言自己编写的一个多线程的小服务器MyWebServer 2.0，其中的JSP编译器和“javax.servlet.*” API是我自己编写。本文结合我在该项目中对中文显示乱码处理的经验，论述了java语言在linux操作系统下中文乱码产生的原因和解决方法。

关键词：字符集；本地化；URL encode；URL decoder

中图分类号：TP312JA      文献标识码：A

Study on the Chinese Error Coding in the Java Programs on Linux

JIA Jin-ying1, JIA Jin-ying2

        （1.Pingdingshan City Branch Company of China Unicom ,Henan Pingdingshan 467300, 2.Manages Departyment of Hebei University 071002）

Key words:character set;locale;URL encode;URL decoder.
用java语言在微软的windows下，无论是基于awt（swing）的图形界面程序编写，还是基于B/S结构的JSP（Servlet）的系统开发，一般都不会遇到中文显示乱码，只有在URL传递中文参数时会出现乱码，但做过JSP项目的程序员都知道通过字符串的简单的重新编码就能得到原来的汉字，至于其内部原理大概所知到的人就不多了。然而在linux下做java项目的开发中文显示问题就复杂的多了，特别是在微软的windows下开发的系统直接拿到linux下运行一般就会出现中文乱码现像。一般开发人员都会通过将所有的程序源码文件别存为新的字符编码文件，或者通过在IDE中设置文档编码，然后在linux下重新编译整个项目，就能解决问题，然而为什么要这么做呢？下面就从字符编码说起来解释问题的本质。

1         字符集

字符集（CHARACTER SET），或称字集，是指字符的集合；字符集种类较多，每个字符集包含的字符个数不同，常见的字符集名称：ASCII字符集、GB2312字符集、GB18030字符集、UNICODE字符集等。

1.1ASCII字符集

上个世纪60年代，美国有关的标准化组织就出台了ASCII（AMERICAN STANDARD CODE FOR INFORMATION INTERCHANGE：美国信息交换标准码）编码，制定了一套字符编码，只能表示256个符号，主要用于显示现代英语和其他西欧语言。它是现今最通用的单字节编码系统，并等同于国际标准ISO 10646。

1.2GB系列字符集（GB2312、GB13000、GBK、GB18030）

GB2312由原中国国家标准总局发布，共收录6763个简体汉字、682个符号，由于GB2312定义的字符集太小，容纳的汉字太少，在UNICODE出台之后，我国立刻制定了完全兼容的GB13000标准，微软以技术上难以实现为理由，自己搞了一套扩展字符集，也就是GBK，在GB2312基础上定义了包括繁体字在内的更多汉字，并在WINDOWS简体中文版中加以实施。到了二十世纪末，GBK字符集也不够用了，WINDOWS操作系统将内核改为支持UNICODE字符集。UNICODE与GB系列字符集不兼容。于是我国政府于2000年3月17日发布的新的汉字编码国家标准GB18030，作为我国所有非手持/嵌入式计算机系统的强制实施标准，GB18030收录了27484个汉字，不但与UNICODE3.0版本兼容，还与以前的GB字符编码标准兼容。

2  字符编码与字库

字符集只是文字的集合，不一定适合网络传送、处理。计算机要准确的处理各种字符集文字，有时须经编码（ENCODING）后才能应用。所谓字符编码是规定每个“字符”分别用一个字节还是多个字节存储，用哪些字节来存储，这个规定就叫做“编码”。各个国家和地区在制定编码标准的时候，“字符集”和“编码”一般都是同时制定的。因此，平常我们所说的“字符集”，比如GB2312、GBK等，除了有“字符的集合”这层含义外，同时也包含了“编码”的含义。对UNICODE字符集的编码称为UTF。目前通用的编码标准有UTF-16小尾序（LITTLE ENDIAN）、UTF-16大尾序（BIG ENDIAN）和UTF-8变长编码。

字库就是字型库（FONT LIBRARY），其实计算机上显示的每个字符（不管它是哪种语言的），都是一个小的图案。字库就是把这些小的图案以图片的某种形式保存起来，需要显示的时候还原出来就可以了。在WINDOWS操作系统里的字库存放在系统盘windows\fonts文件夹下，在linux操作系统中字库存放在这/usr/share/fonts/文件夹下。

3  Java语言中产生乱码的原因及解决方法

3.1基于awt（swing）的图形界面程序中文显示乱码

基于awt（swing）的图形界面程序中，一般会出现菜单中的中文显示乱码，其原因一般是JVM找不到用来显示中文的字库，JVM在原始的安装下是没有中文字库的，而linux的发行版本又各不相同，其字库存放的路径和名字又各不相同，所以JVM一般是找不到linux操作系统内带的字库，解决方法是让JVM能找到linux操作系统内带的字库，如在Redflag 6.0下可以通过下面命令解决：

mkdir /usr/java/jdk1.6.0/jre/lib/fonts/fallback

ln -s /usr/share/fonts/chinese/TrueType/*.ttf /usr/java/jdk1.6.0/jre/lib/fonts/fallback

一般不需要修改JRE/lib/目录下的字体配置文件（fontconfig.OS.Version.properties）。

3.2 基于B/S结构的JSP（Servlet）的系统用户端浏览器中文显示乱码

3.2.1页面中的中文显示乱码

对于像HTML的静态文件，其文件的字符集只要和文件中<meta http-equiv="Content-Type" content="text/html; charset=…… ">处所设置的一样即可。

对于像JSP和Servlet动态文件由于需要经过编译，在运行是由JVM解释class文件而产生用户端浏览器所需的HTML文件，如果产生中文乱码，则一般是由编译和运行过程中产生的。如果用商用的发行版Linux和服务器，一般只要将JSP或Servlet文件保存为UTF－8字符集，将<meta http-equiv = "Content-Type" content="text/html; charset=…… ">中设置为UTF－8即可。如果还出现乱码则可以通过以下方法解决：

①如果服务器是自主研发的，可以通过修改源代码，指定JVM读文件、写文件以及生成用户端浏览器所需的HTML文件时，字符串与二进制序列流转换时的编码方式，从而从根本上解决问题，增强服务器的适应性，在MyWebServer 2.0中，我就采用了这种方法，代码如下：

new BufferedReader(new InputStreamReader(new FileInputStream(jspfile),"GBK"));

new PrintWriter(serfile,"GBK");

new PrintWriter(new OutputStreamWriter(os,"GBK"));

②当然也可以在服务器的入口文件（即含有main子函数的文件）中修改JVM的“locale”设置，代码如下：

Locale.setDefault(new Locale(“zh”,”CN”));

③当采用商用服务器时，可以修改启动服务器的shell文件，在启动服务器前设置环境变量“export LC＿ALL＝zh_CN.UTF-8”，从而改变本控制台下默认的“locale”值。

④当然也可以修改操作系统的“locale”设置，但由于修改操作系统的“locale”设置将会影响到其他应用程序，所以一般采用该方法。

采用上述方法的主要原因是，当JVM在首次起动时，将会把操作系统的“locale”设置为JVM的默认“locale”，在操作系统没有设置“locale”值时（如mylinux 1.0），JVM将会把JVM的缺省的“locale”设置为JVM的默认“locale”，当然也可以在运行应用程序时修改JVM的默认“locale”设置，在JVM进行字符串与二进制序列流相互转换时，如果指定了编码方式，将以指定的编码方式转换，否则根据JVM的默认“locale”进行转换。

3.2.2 get方法从URL获取的参数中中文显示乱码

     对于get方法来说，都是把数据串联在请求的url后面作为参数，url拼接完成后，浏览器会对url进行URL encode，然后发送给服务器，URL encode的过程就是把部分的url做为字符，按照某种编码方式（如：utf-8,gbk等）编码成二进制的字节码，然后每个字节用一个包含3个字符的字符串 "%xy" 表示，其中xy为该字节的两位十六进制表示形式。了解了URL encode的过程，我们能看到2个很重要的问题，第一：需要URL encode的字符一般都是非ASCII的字符，所以都是英文字母的url不会出现服务器得到乱码问题，出现乱码都是url里面带了中文或特殊字符造成的；第二：URL encode到底按照那种编码方式对字符编码？不同的浏览器有不同的做法，中文版的浏览器一般会默认的使用GBK，通过设置浏览器也可以使用UTF-8，完成了URL encode的url就成了ASCII范围内的字符了，然后以iso-8859-1的编码方式转换成二进制随着请求头一起发送出去。

服务器端获取到数据，第一步是先把数据用iso-8859-1进行解码，对于get方法来说，tomcat获取数据的是ASCII范围内的请求头字符，其中的请求url里面带有参数数据，如果参数中有中文等特殊字符，那么目前还是URL encode后的%XY状态，先停下，我们先说下开发人员一般获取数据的过程。通常大家都是request.getParameter("name")获取参数数据，我们在request对象或得的数据都是经过解码过的，而解码过程中程序里是无法指定，服务器tomcat默认缺省用的是iso-8859-1,这样我们就能找到为什么get请求带中文参数为什么在服务器端得到乱码了，原因是在客户端一般都是用UTF-8或GBK对数据URL encode，这里用iso-8859-1方式URL decoder显然不行，所以一般可以采用以下代码解决：

String Sname = new String(request.getParameter("name").getBytes("iso-8859-1"),"GBK");

//其中的“GBK”为用户端用浏览器URL编码方式。

也可以修改服务器的配置文件，让服务器在获取数据后用指定的方式进行URL decoder。

如果服务器是自主研发的，可以通过修改服务器的源代码，指定URL的解编码方式，从而解决问题。如在myWebServer2.0中，我采用了在程序中直接指定以"iso-8859-1"字符集组装二进制序列流，用“GBK“进行URL的解编码，从而可以使在众多的微软中文IE浏览器下JSP可以直接接收到正确的中文参数。相关代码如下：

InputStreamReader myISR=new InputStreamReader(in,"iso-8859-1");

temp=URLDecoder.decode(temp,"GBK");

然而在做开发时，不可能要求用户端用浏览器都用同样的方式进行URL编码，为了服务器能正确接收所有的用户的URL中的中文参数，通常可以通过用JavaScript角本语言先将参数进行编码，编码后参数中的中文将会转换为”ACSII”码，然后再拼装到URL的后面提交，这时在服务器端就可以用统一的方式从request中取到URL，然后再取出URL的参数进行解码。

3.2.3  post方法提交的中文参数出现乱码

在post方法里所要传送的数据也要URL编码，在form所在的html文件里如果有段<meta http-equiv="Content-Type" content="text/html; charset=gb2312 "/>，那么post就会用此处指定的编码方式编码。一般大家都认为这段代码是为了让浏览器知道用什么字符集来对网页解释，其实它还有个作用就是指定form表单的post方法提交数据的URL encode编码方式。对于get方法来数，浏览器对数据的URL encode的编码方式是有浏览器设置来决定，而post方法，开发人员可以指定。如果用tomcat默认缺省设置，也没做过滤器等编码设置，那么他也是用“iso-8859-1”解码的，也可以通过在JSP中设置request.setCharacterEncoding("…")这时服务器会以JSP中指定的字符集解码。

4  结论

Java语言在linux下中文显示产生的乱码，主要与JVM的字库、操作系统的locale设置、JVM的默认locale设置、应用程序中的locale设置以及应用程序中直接指定的二进制序列流与字符串转化的字符集有关。是由于二进制序列流和字符串相互转化过程中所采用的字符编码方式不同或者JVM找不到所需要的字库所致，可以采取不同的方法去解决，具体采用哪种方法处理还要结合具体的应用环境。