中文乱码问题的解决.doc

中文乱码问题的解决在基于 Java 语言的编程中,我们经常碰到汉字的处理及显示的问题。一大堆看不懂的乱码肯定不是我们愿意看到的显示效果, 怎样才能够让那些汉字正确显示呢? Java 语言默认的编码方式是 UNICODE , 而我们中国人通常使用的文件和数据库都是基于 GB231 2或者 BIG 5等方式编码的, 怎样才能够恰当地选择汉字编码方式并正确地处理汉字的编码呢?本文将从汉字编码的常识入手,结合 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 sEnglish =“ apple ”; String sChinese =“苹果”; String s=“苹果 apple ”; sEnglish 的长度是 5, sChinese 的长度是 4,而s 默认的长度是 14 。对于 sEnglish 来说, 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 )