Java 编程技术中汉字问题的分析及解决

在基于Java 语言的编程中，我们经常碰到汉字的处理及显示的问题。

一大堆看不懂的乱码肯定不是我们愿意看到的显示效果，怎样才能够让那些汉字正确显示呢？Java语言默认的编码方式是UNICODE，而我们中国人通常使用的文件和数据库都是基于GB2312或者BIG5等方式编码的，怎样才能够恰当地选择汉字编码方式并正确地处理汉字的编码呢？本文将从汉字编码的常识入手，结合Java编程实例，分析以上两个问题并提出解决它们的方案。

现在Java 编程语言已经广泛应用于互联网世界，早在Sun 公司开发Java 语言的时候，就已经考虑到对非英文字符的支持了。

Sun 公司公布的Java 运行环境（JRE）本身就分英文版和国际版，但只有国际版才支持非英文字符。

不过在Java 编程语言的应用中，对中文字符的支持并非如同Java Soft 的标准规范中所宣称的那样完美，因为中文字符集不只一个，而且不同的操作系统对中文字符的支持也不尽相同，所以会有许多和汉字编码处理有关的问题在我们进行应用开发中困扰着我们。

有很多关于这些问题的解答，但都比较琐碎，并不能够满足大家迫切解决问题的愿望，关于Java 中文问题的系统研究并不多，本文从汉字编码常识出发，分析Java 中文问题，希望对大家解决这个问题有所帮助。

汉字编码的常识我们知道，英文字符一般是以一个字节来表示的，最常用的编码方法是ASCII 。

但一个字节最多只能区分256个字符，而汉字成千上万，所以现在都以双字节来表示汉字，为了能够与英文字符分开，每个字节的最高位一定为1，这样双字节最多可以表示64K格字符。

我们经常碰到的编码方式有GB2312、BIG5、UNICODE等。

关于具体编码方式的详细资料，有兴趣的读者可以查阅相关资料。

我肤浅谈一下和我们关系密切的GB2312 和UNICODE。

GB2312 码，中华人民共和国国家标准汉字信息交换用编码，是一个由中华人民共和国国家标准总局发布的关于简化汉字的编码，通行于中国大陆地区及新加坡，简称国标码。

两个字节中，第一个字节（高字节）的值为区号值加32（20H），第二个字节（低字节）的值为位号值加32（20H），用这两个值来表示一个汉字的编码。

UNICODE 码是微软提出的解决多国字符问题的多字节等长编码，它对英文字符采取前面加“0”字节的策略实现等长兼容。

如“A” 的ASCII 码为0x41，UNICODE就为0x00，0x41。

利用特殊的工具各种编码之间可以互相转换。

回页首Java 中文问题的初步认识我们基于Java 编程语言进行应用开发时，不可避免地要处理中文。

Java 编程语言默认的编码方式是UNICODE，而我们通常使用的数据库及文件都是基于GB2312 编码的，我们经常碰到这样的情况：浏览基于JSP技术的网站看到的是乱码，文件打开后看到的也是乱码，被Java 修改过的数据库的内容在别的场合应用时无法继续正确地提供信息。

String sE nglish = “apple”;String sChinese = “苹果”;String s = “苹果apple ”;sE nglish 的长度是5，sChinese的长度是4，而s 默认的长度是14。

对于sE nglish来说，Java 中的各个类都支持得非常好，肯定能够正确显示。

但对于sChinese 和s 来说，虽然Java Soft 声明Java 的基本类已经考虑到对多国字符的支持（默认UNICODE编码），但是如果操作系统的默认编码不是UNICODE，而是国标码等。

从Java 源代码到得到正确的结果，要经过“Java 源代码-> Java 字节码-> ;虚拟机->操作系统->显示设备”的过程。

在上述过程中的每一步骤，我们都必须正确地处理汉字的编码，才能够使最终的显示结果正确。

“ Java 源代码-> Java 字节码”，标准的Java 编译器javac 使用的字符集是系统默认的字符集，比如在中文Windows 操作系统上就是GBK ,而在Linux 操作系统上就是ISO-8859-1，所以大家会发现在Linux 操作系统上编译的类中源文件中的中文字符都出了问题，解决的办法就是在编译的时候添加encoding 参数，这样才能够与平台无关。

用法是javac ?Cencoding GBK。

“ Java 字节码->虚拟机->操作系统”，Java 运行环境（JRE）分英文版和国际版，但只有国际版才支持非英文字符。

Java 开发工具包（JDK）肯定支持多国字符，但并非所有的计算机用户都安装了JDK 。

很多操作系统及应用软件为了能够更好的支持Java ，都内嵌了JRE 的国际版本，为自己支持多国字符提供了方便。

“操作系统->显示设备”，对于汉字来说，操作系统必须支持并能够显示它。

英文操作系统如果不搭配特殊的应用软件的话，是肯定不能够显示中文的。

还有一个问题，就是在Java 编程过程中，对中文字符进行正确的编码转换。

例如，向网页输出中文字符串的时候，不论你是用out.println(string);还是用<%=string%>，都必须作UNICODE到GBK 的转换，或者手动，或者自动。

在JSP 1.0中，可以定义输出字符集，从而实现内码的自动转换。

用法是<%@page contentType=”text/html;charset=gb2312” %>但是在一些JSP 版本中并没有提供对输出字符集的支持，（例如JSP 0.92），这就需要手动编码输出了，方法非常多。

最常用的方法是String s1 = request.getP arameter(“keyword”);String s2 = new String(s1.getBytes(“ISO-8859-1”),”GBK”);getBytes 方法用于将中文字符以“ISO-8859-1”编码方式转化成字节数组，而“GBK” 是目标编码方式。

我们从以ISO-8859-1方式编码的数据库中读出中文字符串 s1 ，经过上述转换过程，在支持GBK 字符集的操作系统和应用软件中就能够正确显示中文字符串s2 。

回页首Java 中文问题的表层分析及处理.CLASS 文件存放在服务器端，由客户端的浏览器运行 AP P LET ，A PP LE T 只起调入FRAME类等主程序的作用。

界面包括Textfield ，TextArea，List，Choice 等。

I.用JDBC 执行SE LECT 语句从服务器端读取数据（中文）后，将数据用 AP PEND 方法加到TextArea（TA），不能正确显示。

但加到List 中时，大部分汉字却可正确显示。

将数据按“ISO-8859-1” 编码方式转化为字节数组，再按系统缺省编码方式（Default Character E ncoding）转化为STRING ，即可在TA 和List 中正确显示。

在转换字符串时不采用系统默认编码方式，而直接采用“ GBK” 或者“GB2312” ,在A 和B 两种情况下，从数据库取数据都没有问题。

II.处理方式与“取中文”相逆，先将SQL 语句按系统缺省编码方式转化为字节数组，再按“ISO-8859-1”编码方式转化为STRING ，最后送去执行，则中文信息可正确写入数据库。

问题：如果客户机上存在CLASSP ATH 指向JDK 的CLASSES.ZIP时（称为A 情况），上述程序代码可正确执行。

但是如果客户机只有浏览器，而没有JDK 和CLASSP ATH 时（称为B 情况），则汉字无法正确转换。

我们的分析：1.经过测试，在 A 情况下，程序运行时系统的缺省编码方式为GBK 或者GB2312 。

在B 情况下，程序启动时浏览然后系统的缺省编码方式为“8859-1”。

2.如果在转换字符串时不采用系统缺省编码方式，而是直接采用“GBK” 或“GB2312”，则在A 情况下程序仍然可正常3.在客户机上，把JDK 的CLASSE S.ZIP解压后，放在另一个目录中，CLASSP ATH 只包含该目录。

然后一边逐步删除该目录中的 .CLASS 文件，另一边运行测试程序，最后发现在一千多个CLASS 文件中，只有一个是必不可少的，将该文件拷到服务器端和其它的类放在一起，并在程序的开头IMPORT 它，在B 情况下程序仍然无法正常运行。

4.在A 情况下，如果在CLASSP TH 中去掉sun.io.CharToByteDoubleByte.class ，则程序运行时测得默认编码方式为“8859-1”，否则为“GBK” 或“GB2312” 。

如果JDK 的版本为1.2以上的话，在B 情况下遇到的问题得到了很好的解决，测试的步骤同上，有兴趣的读者可以尝试一下。

回页首Java 中文问题的根源分析及解决在简体中文MS Window s 98 + JDK 1.3 下，可以用System.getP roperties() 得到Java 运行环境的一些基本属性，类P oorChinese 可以帮助我们得到这些属性。

类P oorChinese 的源代码：执行java P oorChinese 后，我们会得到:系统变量 file.encoding 的值为GBK ，nguage 的值为 zh ，user.region 的值为CN ，这些系统变量的值决定了系统默认的编码方式是GBK 。

在上述系统中，下面的代码将GB2312 文件转换成Big5 文件，它们能够帮助我们理解Java 中汉字编码的转化:?import java.io.*;import java.util.*;?public class gb2big5 {?static int iCharNum=0;?public static void main(String[] args) {System.out.println("Input GB2312 file, output Big5 file.");if (args.length!=2) {System.err.println("Usage: jview gb2big5 gbfile big5file");System.exit(1);String inputString = readInput(args[0]);writeOutput(inputString,args[1]);System.out.println("Number of Characters in file: "+iCharNum+"."); }?static void writeOutput(String str, String strOutFile) {try {FileOutputStream fos = new FileOutputStream(strOutFile);Writer out = new OutputStreamWriter(fos, "Big5");out.write(str);out.close();}catch (IOException e) {e.printStackTrace();e.printStackTrace();}}?static String readInput(String strInFile) {StringBuffer buffer = new StringBuffer();try {FileInputStream fis = new FileInputStream(strInFile); InputStreamReader isr = new InputStreamReader(fis, "GB2312"); Reader in = new BufferedReader(isr);int ch;while ((ch = in.read()) > -1) {iCharNum += 1;buffer.append((char)ch);}in.close();return buffer.toString();}catch (IOException e) {e.printStackTrace();return null;}}}?编码转化的过程如下：GB2312------------------>Unicode------------->Big5执行java gb2big5 gb.txt big5.txt ，如果gb.txt 的内容是“今天星期三”，则得到的文件big5.txt 中的字符能够正确显示；而如果gb.txt 的内容是“情人节快乐”，则得到的文件big5.txt 中对应于“节”和“乐”的字符都是符号“？”（0x3F），可见sun.io.ByteToCharGB2312 和sun.io.CharToByteBig5 这两个基本类并没有编好。