Java程序员都曾遇到过这样的问题:输入的中文不能正确显示在界面上,保存在数据库中的也是一堆乱码,或者数据库或数据文件中存放的是正确的中文,可是在Java程序中看到的却是一大串的“?”。
Java程序员都曾遇到过这样的问题:输入的中文不能正确显示在界面上,保存在数据库中的也是一堆乱码,或者数据库或数据文件中存放的是正确的中文,可是在Java程序中看到的却是一大串的“?”。 这就是通常所说的“中文问题”。 Java中与中文相关的编码 在JDK中,提供了对大多数常用语言的支持。在解决“中文问题”时,表1中的编码是最常用,或者就是最有关系的。 表1 JDK中与中文相关的编码列表 在实际编程时,接触得比较多的是GB2312(GBK)和ISO8859-1。 注:UTF是Unicode Transformation Format的缩写,意为Unicode转换格式。可以这么描述JAVA程序中Unicode与UTF的关系,虽然不绝对。字符串在内存中运行时,表现为Unicode代码,而当要保存到文件或其它介质中去时,用的是UTF。这个转化过程是由writeUTF和readUTF来完成得。 Servlet/JSP对中文的处理过程 总体流程 把问题想成是一个黑匣子。先看黑匣子的一级表示(如图1所示): 图1 IPO模型 这就是一个IPO模型,即输入、处理和输出。同样的内容要经过“从charsetA到Unicode再到charsetB”的转化。 再看二级表示(如图2所示): 图2 JSP、Java输出模型 在这个图中,输入的是JSP和Java源文件。在处理过程中,以Class文件为载体,然后输出。再细化到三级(如图3所示): 图3 IPO模型 JSP文件先生成中间的Java文件,再生成Class。而Servlet和普通App则直接编译生成Class,然后,从Class再输出到浏览器、控制台或数据库等。 JSP:从源文件到Class的过程 JSP源文件是以“.jsp”结尾的文本文件。在本节中,将阐述JSP文件的解释和编译过程,并跟踪其中中文内容的变化。 一般地,JSP源文件经过如下步骤后变成可被引擎执行的Class文件: 1. JSP/Servlet引擎提供的JSP转换工具(JSPC)搜索JSP文件中用中指定的charset。如果在JSP文件中未指定,则默认为ISO8859-1(或者说是Latin-1)。 2. JSPC用相当于“Javac -encoding ”解释JSP文件中出现的所有字符,包括中文字符和ASCII字符。然后把这些字符转换成Unicode字符,再转化成UTF格式,存为Java文件。ASCII码字符转化为Unicode字符时只是简单地在前面加“00”,如“A”,转化为“\u0041”。然后,经过了UTF的转换,又变回“41”了。这也就是可以使用普通文本编辑器查看由JSP生成的Java文件的原因。 3. 引擎用相当于“Javac -encoding UTF-8”的命令,把Java文件编译成Class文件。 先看一下这些过程中中文字符的转换情况。有如下源代码: 这段代码是在UltraEdit for Windows上编写的。保存后,“中文”两个字的16进制编码为“D6 D0 CE C4”(GB2312编码)。经查表,“中文”两字的Unicode编码为“\u4E2D\u6587”,用 UTF表示就是“E4 B8 AD E6 96 87”。打开引擎生成的由JSP文件转变成的Java文件,发现其中的“中文”两个字的位置确实被“E4 B8 AD E6 96 87”替代了,再查看由Java文件编译生成的Class文件,发现结果与Java文件中的完全一样,也是“E4 B8 AD E6 96 87”。 再看JSP中指定的CharSet为ISO-8859-1的情况: 同样,该文件是用UltraEdit编写的。“中文”这两个字也是存为GB2312编码“D6 D0 CE C4”。先模拟一下生成的Java文件和Class文件的过程:JSPC用ISO-8859-1来解释“中文”,并把它映射到Unicode。由于ISO-8859-1是8位的,且是拉丁语系,其映射规则就是在每个字节前加“00”。所以,映射后的Unicode编码应为“\u00D6\u00D0\ u00CE\u00C4”,转化成UTF后应该是“C3 96 C3 90 C3 8E C3 84”。好,打开文件Java文件和CLASS文件,“中文”两个字的位置果然都表示为“C3 96 C3 90 C3 8E C3 84”。 如果上述代码中不指定,即把第一行写成“”,JSPC会使用默认的“ISO8859-1”来解释JSP文件。 到现在为止,已经解释了从JSP文件到Class文件的转变过程中中文字符的映射过程。一句话,从“Jsp-CharSet到Unicode再到UTF”。表2总结了这个过程: 表2 “中文”从JSP到Class的转化过程 Servlet:从源文件到Class的过程 Servlet源文件是以“.Java”结尾的文本文件。我们将讨论Servlet的编译过程并跟踪其中的中文变化。 用“Javac”编译Servlet源文件。Javac可以带“-encoding ”参数,意思是“用< Compile-charset >中指定的编码来解释Serlvet源文件”。 源文件在编译时,用来解释所有字符,包括中文字符和ASCII字符。然后把字符常量转变成Unicode字符。最后,把Unicode转变成UTF。 在Servlet中,还有一个地方设置输出流的CharSet。通常在输出结果前,调用HttpServletResponse的setContent Type方法来达到与在JSP中设置一样的效果,称之为。 注意:文中一共提到了三个变量:、和。其中,JSP文件只与有关,而和只与Servlet有关。 看下例: import Javax.servlet.*; import Javax.servlet.http.*; Class testServlet extends HttpServlet { public void doGet(HttpServletRequest req,HttpServletResponse resp) throws ServletException,Java.io.IOException { resp.setContentType("text/html; charset=GB2312"); Java.io.PrintWriter out=resp.getWriter(); out.println(""); out.println("#中文#"); out.println(""); } } 该文件也是用UltraEdit for Windows编写的,其中的“中文”两个字保存为字节流“D6 D0 CE C4”(GB2312编码)。 开始编译。表3是不同时,Class文件中“中文”两字的十六进制码。在编译过程中,不起任何作用。只对Class文件的输出产生影响,可以说和一起,达到与JSP文件中的相同的效果,因为对编译过程和Class文件的输出都会产生影响。 表3 “中文”从Servlet源文件到Class的转变过程 注意:普通Java程序的编译过程与Servlet完全一样。 截止现在,从JSP或Servlet的源文件到Class文件的过程中中文内容的蜕变历程是不是昭然若揭了?OK,接下来看看Class文件中的中文又是怎样被输出的呢? Class:输出字符串 Class文件是Java程序的一种存储载体。当Class文件被虚拟机执行时,通过readUTF把Class文件中的内容读入内存中。字符串在内存中表示为Unicode编码。当要把内存中的内容输出到别的程序或是外围设备(如终端)上去时,问题就来了(为了简单起见,把“别的程序或外围设备”称之为“输出对象”)。 1.如果输出对象能处理Unicode字符,则一切都很简单,只要把Unicode字符直接传给输出对象即可。 2.事实是,大多数输出对象不能直接处理Unicode,它们只能处理ISO8859-1和GB2312等。在往输出对象输出字符串时,需要做一定的转换才行。 看看下面的例子,给定一个有四个字符的Unicode字符串“00D6 00D0 00CE 00C4”,如果输出到只能识别“ISO8859-1”的程序中去,则直接去掉前面的“00”即可得到目的字符串“D6 D0 CE C4”。假如把它们输出到GB2312的程序中去,得到的结果很可能是一大堆乱码。因为在GB2312中可能没有(也有可能有)字符与00D6等字符对应(如果对应不上,将得到0x3f,也就是问号,如果对应上了,由于00D6等字符太靠前,估计也是一些特殊符号,真正的汉字在Unicode中的编码从4E00开始)。 同样的Unicode字符,输出到不同编码的对象中去时,结果是不同的。当然,这其中有一种是我们期望的结果。对于能处理中文的输出对象而言,自然希望输入的内容(也就是Java程序输出的内容)是基于GB2312编码有意义的中文字符串。 以上例而论,“D6 D0 CE C4”应该是我们所想要的。当把“D6 D0 CE C4”输出到IE中时,用“简体中文”方式查看,就能看到清楚的“中文”两个字了。 得出如下结论: Java程序在输出字符串前,必须先把Unicode的字符串按照某一种内码重新生成字节流,然后把字节流输出给“输出对象”,相当于进行了一步“String.getBytes(???)”操作,其中???代表一种字符集的名字。 1.如果是Servlet,这种字符集是在HttpServlet Response.setContentType()方法中指定的,也就是上文定义的。