《Java编程技术中汉字问题的分析及解决》由会员分享，可在线阅读，更多相关《Java编程技术中汉字问题的分析及解决（12页珍藏版）》请在金锄头文库上搜索。
1、Java 编程技术中汉字问题的分析及解决编程技术中汉字问题的分析及解决 段明辉 自由撰稿人 2000 年 11 月 8 日 在基于 Java 语言的编程中我们经常碰到汉字的处理及显示的问题一大堆看不懂的乱码肯定不是我们愿意看到的显示效果怎样才能够让那些汉字正确显示呢Java 语言默认的编码方式是UNICODE 而我们中国人通常使用的文件和数据库都是基于 GB2312 或者 BIG5 等方式编码的怎样才能够恰当地选择汉字编码方式并正确地处理汉字的编码呢本文将从汉字编码的常识入手结合 Java 编程实例分析以上两个问题并提出解决它们的方案 现在 Java 编程语言已经广泛应用于互联网世界早在 Su
2、n 公司开发 Java 语言的时候就已经考虑到对非英文字符的支持了Sun 公司公布的 Java 运行环境JRE本身就分英文版和国际版但只有国际版才支持非英文字符不过在 Java 编程语言的应用中对中文字符的支持并非如同 Java Soft 的标准规范中所宣称的那样完美因为中文字符集不只一个而且不同的操作系统对中文字符的支持也不尽相同所以会有许多和汉字编码处理有关的问题在我们进行应用开发中困扰着我们有很多关于这些问题的解答但都比较琐碎并不能够满足大家迫切解决问题的愿望关于 Java 中文问题的系统研究并不多本文从汉字编码常识出发分析 Java 中文问题希望对大家解决这个问题有所帮助 汉字编码的常
3、识汉字编码的常识 我们知道英文字符一般是以一个字节来表示的最常用的编码方法是 ASCII 但一个字节最多只能区分 256 个字符而汉字成千上万所以现在都以双字节来表示汉字为了能够与英文字符分开每个字节的最高位一定为 1 这样双字节最多可以表示 64K 格字符 我们经常碰到的编码方式有 GB2312BIG5UNICODE 等关于具体编码方式的详细资料有兴趣的读者可以查阅相关资料我肤浅谈一下和我们关系密切的 GB2312 和 UNICODEGB2312 码中华人民共和国国家标准汉字信息交换用编码是一个由中华人民共和国国家标准总局发布的关于简化汉字的编码通行于中国大陆地区及新加坡简称国标码两个字节中
4、第一个字节高字节的值为区号值加 3220H第二个字节低字节的值为位号值加 3220H用这两个值来表示一个汉字的编码UNICODE 码是微软提出的解决多国字符问题的多字节等长编码它对英文字符采取前面加0字节的策略实现等长兼容如 A 的 ASCII 码为 0x41UNICODE 就为 0x000x41利用特殊的工具各种编码之间可以互相转换 Java 中文问题的初步认识中文问题的初步认识 我们基于 Java 编程语言进行应用开发时不可避免地要处理中文Java 编程语言默认的编码方式是 UNICODE而我们通常使用的数据库及文件都是基于 GB2312 编码的我们经常碰到这样的情况浏览基于 JSP 技术
5、的网站看到的是乱码文件打开后看到的也是乱码被 Java 修改过的数据库的内容在别的场合应用时无法继续正确地提供信息 String sEnglish = “apple”; String sChinese = “苹果”; String s = “苹果 apple ”; sEnglish 的长度是 5sChinese 的长度是 4而 s 默认的长度是 14对于 sEnglish 来说 Java 中的各个类都支持得非常好 肯定能够正确显示 但对于 sChinese 和 s 来说 虽然 Java Soft 声明 Java 的基本类已经考虑到对多国字符的支持默认 UNICODE 编码但是如果操作系统的默认
6、编码不是 UNICODE 而是国标码等 从 Java 源代码到得到正确的结果 要经过 Java 源代码- Java 字节码- ;虚拟机-操作系统-显示设备的过程在上述过程中的每一步骤我们都必须正确地处理汉字的编码才能够使最终的显示结果正确 Java 源代码- Java 字节码标准的 Java 编译器 javac 使用的字符集是系统默认的字符集比如在中文 Windows 操作系统上就是 GBK ,而在 Linux 操作系统上就是 ISO-8859-1所以大家会发现在 Linux 操作系统上编译的类中源文件中的中文字符都出了问题解决的办法就是在编译的时候添加 encoding 参数这样才能够与平台
7、无关用法是 javac encoding GBK Java 字节码-虚拟机-操作系统 Java 运行环境 JRE 分英文版和国际版但只有国际版才支持非英文字符 Java 开发工具包 JDK 肯定支持多国字符但并非所有的计算机用户都安装了 JDK 很多操作系统及应用软件为了能够更好的支持 Java 都内嵌了 JRE 的国际版本为自己支持多国字符提供了方便 操作系统-显示设备对于汉字来说操作系统必须支持并能够显示它英文操作系统如果不搭配特殊的应用软件的话是肯定不能够显示中文的 还有一个问题就是在 Java 编程过程中对中文字符进行正确的编码转换例如向网页输出中文字符串的时候不论你是用 out.pr
8、intln(string); / string 是含中文的字符串 还是用 都必须作 UNICODE 到 GBK 的转换或者手动或者自动在 JSP 1.0 中可以定义输出字符集从而实现内码的自动转换用法是 但是在一些 JSP 版本中并没有提供对输出字符集的支持例如 JSP 0.92这就需要手动编码输出了方法非常多最常用的方法是 String s1 = request.getParameter(“keyword”); String s2 = new String(s1.getBytes(“ISO-8859-1”),”GBK”); getBytes 方法用于将中文字符以ISO-8859-1编码方式转
9、化成字节数组而GBK 是目标编码方式 我们从以 ISO-8859-1 方式编码的数据库中读出中文字符串 s1 经过上述转换过程 在支持 GBK 字符集的操作系统和应用软件中就能够正确显示中文字符串 s2 Java 中文问题的表层分析及处理中文问题的表层分析及处理 背景 开发环境 JDK1.15 Vcafe2.0 JPadPro 服务器端 NT IIS Sybase System JconnectJDBC 客户端 IE5.0 Pwin98 .CLASS 文件存放在服务器端 由客户端的浏览器运行 APPLET APPLET 只起调入 FRAME 类等主程序的作用界面包括 Textfield Tex
10、tAreaListChoice 等 I. 取中文 用 JDBC 执行 SELECT 语句从服务器端读取数据中文后将数据用 APPEND 方法加到 TextAreaTA 不能正确显示但加到 List 中时大部分汉字却可正确显示 将数据按ISO-8859-1 编码方式转化为字节数组再按系统缺省编码方式 Default Character Encoding 转化为 STRING 即可在 TA 和 List 中正确显示 程序段如下 dbstr2 = results.getString(1); /After reading the result from DB serverconverting it t
11、o string. dbbyte1 = dbstr2.getBytes(“iso-8859-1”); dbstr1 = new String(dbbyte1); 在转换字符串时不采用系统默认编码方式 而直接采用 GBK 或者 GB2312 ,在 A 和 B 两种情况下从数据库取数据都没有问题 II. 写中文到数据库 处理方式与取中文相逆先将 SQL 语句按系统缺省编码方式转化为字节数组再按ISO-8859-1编码方式转化为 STRING 最后送去执行则中文信息可正确写入数据库 程序段如下 sqlstmt = tf_input.getText(); /Before sending stateme
12、nt to DB serverconverting it to sql statement. dbbyte1 = sqlstmt.getBytes(); sqlstmt = newString(dbbyte1,”iso-8859-1”); _stmt = _con.createStatement(); _stmt.executeUpdate(sqlstmt); 问题如果客户机上存在 CLASSPATH 指向 JDK 的 CLASSES.ZIP 时称为 A 情况上述程序代码可正确执行 但是如果客户机只有浏览器 而没有 JDK 和 CLASSPATH 时 称为 B 情况则汉字无法正确转换 我们的分
13、析 1.经过测试 在 A 情况下 程序运行时系统的缺省编码方式为 GBK 或者 GB2312 在 B 情况下程序启动时浏览器的 JAVA 控制台中出现如下错误信息 Cant find resource for sun.awt.windows.awtLocalization_zh_CN 然后系统的缺省编码方式为8859-1 2.如果在转换字符串时不采用系统缺省编码方式而是直接采用 GBK 或GB2312则在 A 情况下程序仍然可正常运行在 B 情况下系统出现错误 UnsupportedEncodingException 3.在客户机上把 JDK 的 CLASSES.ZIP 解压后放在另一个目录中
14、 CLASSPATH 只包含该目录然后一边逐步删除该目录中的 .CLASS 文件另一边运行测试程序最后发现在一千多个 CLASS 文件中只有一个是必不可少的该文件是 sun.io.CharToByteDoubleByte.class 将该文件拷到服务器端和其它的类放在一起并在程序的开头 IMPORT 它在 B 情况下程序仍然无法正常运行 4.在 A 情况下如果在 CLASSPTH 中去掉 sun.io.CharToByteDoubleByte.class 则程序运行时测得默认编码方式为8859-1否则为 GBK 或 GB2312 如果 JDK 的版本为 1.2 以上的话在 B 情况下遇到的问题
15、得到了很好的解决测试的步骤同上有兴趣的读者可以尝试一下 Java 中文问题的根源分析及解决中文问题的根源分析及解决 在简体中文 MS Windows 98 + JDK 1.3 下可以用 System.getProperties() 得到 Java 运行环境的一些基本属性类 PoorChinese 可以帮助我们得到这些属性 类 PoorChinese 的源代码 public class PoorChinese public static void main(String args) System.getProperties().list(System.out); 执行 java PoorChin
16、ese 后我们会得到: 系统变量 file.encoding 的值为 GBK user.language 的值为 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) Sys
