Java编程中的中文问题

1、深入剖析 Java 编程中的中文问题及建议最优解决方法 Abstract ：本文深入分析了Java 程序设计中Java 编译器对 java 源文件和 JVM对 class 类文件的编码 /解码过程， 通过此过程的解析透视出了Java 编程中中文问题产生的根本原因，最后给出了建议的最优化的解决 Java 中文问题的方法。 1、中文问题的来源 计算机最初的操作系统支持的编码是单字节的字符编码，于是，在计算机中一切处理程序最初都是以单字节编码的英文为准进行处理。随着计算机的发展，为了适应世界其它民族的语言（当然包括我们的汉字） ，人们提出了UNICODE 编码，它采用双字节编码，兼容英文字符和其它民族的双字节字符编码，所以，目前，大多数国际性的软件内部均采用UNICODE 编码，在软件运行时，它获得本地支持系统（多数时间是操作系统） 默认支持的编码格式，然后再将软件内部的UNICODE 转化为本地系统默认支持的格式显示出来。Java 的 JDK和 JVM即是如此， 我这里说的JDK是指国际版的JDK ，我们大多数程序员使用的是国际化的JDK版本，以下所有的JDK均指国际化的JDK版本。 我们

2、的汉字是双字节编码语言，为了能让计算机处理中文，我们自己制定的gb2312、GBK 、GBK2K等标准以适应计算机处理的需求。所以，大部分的操作系统为了适应我们处理中文的需求， 均定制有中文操作系统， 它们采用的是GBK,GB2312 编码格式以正确显示我们的汉字。如：中文 Win2K 默认采用的是GBK编码显示，在中文WIN2k中保存文件时默认采用的保存文件的编码格式也是 GBK 的， 即， 所有在中文WIN2K中保存的文件它的内部编码默认均采用GBK编码，注意：GBK 是在 GB2312基础上扩充来的。 由于 Java 语言内部采用UNICODE 编码，所以在JAVA程序运行时，就存在着一个从UNICODE 编码和对应的操作系统及浏览器支持的编码格式转换输入、输出的问题，这个转换过程有着一系列的步骤，如果其中任何一步出错，则显示出来的汉字就会出是乱码，这就是我们常见的JAVA中文问题。 同时，Java 是一个跨平台的编程语言，也即我们编写的程序不仅能在中文windows 上运行，也能在中文 Linux 等系统上运行，同时也要求能在英文等系统上运行（我们经常看到有人把在中文win2k

3、 上编写的JAVA程序，移植到英文Linux 上运行）。这种移植操作也会带来中文问题。 还有， 有人使用英文的操作系统和英文的IE 等浏览器， 来运行带中文字符的程序和浏览中文网页，它们本身就不支持中文，也会带来中文问题。 有，几乎所有的浏览器默认在传递参数时都是以UTF-8 编码格式来传递，而不是按中文编码传递，所以，传递中文参数时也会有问题，从而带来乱码现象。 总之， 以上几个方面是JAVA中的中文问题的主要来源，我们把以上原因造成的程序不能正确运行而产生的问题称作： JAVA 中文问题。 2、JAVA 编码转换的详细过程 我们常见的JAVA程序包括以下类别： *直接在console 上运行的类 (包括可视化界面的类 ) *JSP代码类（注： JSP 是 Servlets类的变型） *Servelets类 *EJB类 *其它不可以直接运行的支持类 这些类文件中，都有可能含有中文字符串，并且我们常用前三类JAVA程序和用户直接交互，用于输出和输入字符，如：我们在JSP和 Servlet中得到客户端送来的字符，这些字符也包括中文字符。无论这些JAVA类的作用如何，这些JAVA程序的生命

4、周期都是这样的： *编程人员在一定的操作系统上选择一个合适的编辑软件来实现源程序代码并以.java扩展名保存在操作系统中，例如我们在中文win2k 中用记事本编辑一个java 源程序； *编程人员用JDK中的 javac.exe来编译这些源代码， 形成.class类(JSP 文件是由容器调用JDK来编译的)； *直接运行这些类或将这些类布署到WEB 容器中去运行，并输出结果。 那么，在这些过程中， JDK 和 JVM是如何将这些文件如何编码和解码并运行的呢？ 这里，我们以中文win2k 操作系统为例说明JAVA类是如何来编码和被解码的。 第一步，我们在中文win2k 中用编辑软件如记事本编写一个Java 源程序文件 (包括以上五类JAVA程序)，程序文件在保存时默认采用了操作系统默认支持GBK编码格式 (操作系统默认支持的格式为file.encoding格式)形成了一个 .java文件，也即， java程序在被编译前，我们的JAVA源程序文件是采用操作系统默认支持的file.encoding编码格式保存的， java 源程序中含有中文信息字符和英文程序代码；要查看系统的file.enc

5、oding参数，可以用以下代码： public class ShowSystemDefaultEncoding public static void main(String args) String encoding = System.getProperty(file.encoding); System.out.println(encoding); 第二步， 我们用 JDK的 javac.exe文件编译我们的Java 源程序，由于 JDK是国际版的， 在编译的时候，如果我们没有用 -encoding参数指定我们的JAVA源程序的编码格式，则javac.exe首先获得我们操作系统默认采用的编码格式，也即在编译java 程序时，若我们不指定源程序文件的编码格式，JDK首先获得操作系统的 file.encoding参数(它保存的就是操作系统默认的编码格式，如WIN2k ，它的值为GBK) ，然后 JDK就把我们的java 源程序从 file.encoding编码格式转化为JAVA内部默认的UNICODE 格式放入内存中。然后，javac把转换后的 unicode 格式的文件进行编译成 .cl

6、ass类文件，此时.class文件是 UNICODE 编码的，它暂放在内存中，紧接着，JDK 将此以 UNICODE 编码的编译后的class文件保存到我们的操作系统中形成我们见到的 .class文件。对我们来说， 我们最终获得的 .class文件是内容以UNICODE 编码格式保存的类文件，它内部包含我们源程序中的中文字符串，只不过此时它己经由file.encoding格式转化为UNICODE 格式了。 这一步中，对于JSP 源程序文件是不同的，对于JSP ，这个过程是这样的：即WEB 容器调用 JSP编译器，JSP 编译器先查看JSP文件中是否设置有文件编码格式，如果JSP文件中没有设置JSP文件的编码格式，则 JSP编译器调用JDK先把 JSP文件用 JVM默认的字符编码格式 (也即WEB 容器所在的操作系统的默认的 file.encoding)转化为临时的Servlet类，然后再把它编译成UNICODE 格式的 class 类，并保存在临时文件夹中。如：在中文win2k 上，WEB容器就把 JSP 文件从 GBK编码格式转化为UNICODE 格式，然后编译成临时保存的Servl

7、et类，以响应用户的请求。 第三步，运行第二步编译出来的类，分为三种情况： A、 直接在console 上运行的类 B、 EJB 类和不可以直接运行的支持类(如JavaBean 类) C 、 JSP 代码和 Servlet类 D 、 JAVA 程序和数据库之间 下面我们分这四种情况来看。 A、直接在console 上运行的类 这种情况， 运行该类首先需要JVM支持，即操作系统中必须安装有JRE 。运行过程是这样的： 首先 java启动 JVM ，此时 JVM读出操作系统中保存的class文件并把内容读入内存中，此时内存中为UNICODE 格式的 class 类，然后 JVM运行它，如果此时此类需要接收用户输入，则类会默认用file.encoding编码格式对用户输入的串进行编码并转化为unicode 保存入内存（用户可以设置输入流的编码格式）。程序运行后，产生的字符串（ UNICODE编码的）再回交给JVM ，最后 JRE把此字符串再转化为file.encoding格式(用户可以设置输出流的编码格式)传递给操作系统显示接口并输出到界面上。 对于这种直接在console 上运行的类，它的

8、转化过程可用图1 更加明确的表示出来： 图 1 以上每一步的转化都需要正确的编码格式转化，才能最终不出现乱码现象。 B、EJB 类和不可以直接运行的支持类(如JavaBean 类) 由于 EJB类和不可以直接运行的支持类，它们一般不与用户直接交互输入和输出，它们常常与其它的类进行交互输入和输出，所以它们在第二步被编译后，就形成了内容是UNICODE 编码的类保存在操作系统中了，以后只要它与其它的类之间的交互在参数传递过程中没有丢失，则它就会正确的运行。 这种 EJB类和不可以直接运行的支持类, 它的转化过程可用图2 更加明确的表示出来： 图 2 C 、JSP 代码和 Servlet类 经过第二步后， JSP文件也被转化为Servlets类文件，只不过它不像标准的Servlets一校存在于classes目录中，它存在于WEB 容器的临时目录中，故这一步中我们也把它做为Servlets来看。 对于Servlets ，客户端请求它时， WEB 容器调用它的JVM来运行 Servlet ，首先， JVM 把 Servlet的class类从系统中读出并装入内存中，内存中是以UNICODE 编码的

9、 Servlet类的代码，然后JVM在内存中运行该 Servlet类，如果 Servlet在运行的过程中， 需要接受从客户端传来的字符如：表单输入的值和URL中传入的值， 此时如果程序中没有设定接受参数时采用的编码格式，则 WEB 容器会默认采用ISO-8859-1 编码格式来接受传入的值并在JVM中转化为 UNICODE 格式的保存在WEB 容器的内存中。 Servlet运行后生成输出，输出的字符串是UNICODE 格式的，紧接着，容器将Servlet运行产生的UNICODE 格式的串（如html语法，用户输出的串等）直接发送到客户端浏览器上并输出给用户，如果此时指定了发送时输出的编码格式，则按指定的编码格式输出到浏览器上，如果没有指定，则默认按ISO-8859-1 编码发送到客户的浏览器上。这种 JSP代码和 Servlet类，它的转化过程可用图3 更加明确地表示出来： 图 3 D 、Java 程序和数据库之间 对于几乎所有数据库的JDBC驱动程序，默认的在JAVA程序和数据库之间传递数据都是以ISO-8859-1为默认编码格式的，所以，我们的程序在向数据库内存储包含中文的数据时，

10、JDBC首先是把程序内部的UNICODE 编码格式的数据转化为ISO-8859-1 的格式，然后传递到数据库中，在数据库保存数据时，它默认即以 ISO-8859-1 保存，所以，这是为什么我们常常在数据库中读出的中文数据是乱码。 对于 JAVA程序和数据库之间的数据传递，我们可以用图4 清晰地表示出来 图 4 3、分析常见的JAVA中文问题几个必须清楚的原则 首先，经过上面的详细分析，我们可以清晰地看到，任何JAVA程序的生命期中，其编码转换的关键过程是在于：最初编译成class 文件的转码和最终向用户输出的转码过程。 其次，我们必须了解JAVA在编译时支持的、常用的编码格式有以下几种： *ISO-8859-1，8-bit, 同8859_1,ISO-8859-1,ISO_8859_1等编码 *Cp1252，美国英语编码，同ANSI标准编码 *UTF-8，同 unicode 编码 *GB2312 ，同 gb2312-80,gb2312-1980等编码 *GBK , 同 MS936 ，它是 gb2312 的扩充 及其它的编码，如韩文、日文、繁体中文等。同时，我们要注意这些编码间的兼容关体系

《Java编程中的中文问题》由会员海****n分享，可在线阅读，更多相关《Java编程中的中文问题》请在金锄头文库上搜索。