JSP/Servlet 中的汉字编码问题(转）
作者：UB 时间：2002-06-14 10:51:10
JSP/Servlet中的汉字编码问题(1)
[作者:不详添加时间:2001-9-68:12:47>
网上就JSP/Servlet中DBCS字符编码问题有许多优秀的文章和讨论，本文对它们作一些整理，并结合IBMWebSphereApplicationServer3.5（WAS）的解决方法作一些说明，希望它不是多余的。
内容：
问题的起源
GB2312-80，GBK，GB18030-2000汉字字符集及Encoding
中文转码时'?'、乱码的由来
JSP/Servlet汉字编码问题及在WAS中的解决办法
结束语
1.问题的起源
每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的扩展ASCII码,中国的GB2312-80，日本的JIS等，作为该国家/区域内信息处理的基础，有着统一编码的重要作用。字符编码集按长度分为SBCS（单字节字符集），DBCS（双字节字符集）两大类。早期的软件（尤其是操作系统），为了解决本地字符信息的计算机处理，出现了各种本地化版本（L10N），为了区分，引进了LANG,Codepage等概念。但是由于各个本地字符集代码范围重叠，相互间信息交换困难；软件各个本地化版本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理内容降低到最少。这也就是所谓的国际化（I18N）。各种语言信息被进一步规范为Locale信息。处理的底层字符集变成了几乎包含了所有字形的Unicode。
现在大部分具有国际化特征的软件核心字符处理都是以Unicode为基础的，在软件运行时根据当时的Locale/Lang/Codepage设置确定相应的本地字符编码设置，并依此处理本地字符。在处理过程中需要实现Unicode和本地字符集的相互转换，甚或以Unicode为中间的两个不同本地字符集的相互转换。这种方式在网络环境下被进一步延伸，任何网络两端的字符信息也需要根据字符集的设置转换成可接受的内容。
Java语言内部是用Unicode表示字符的，遵守UnicodeV2.0。Java程序无论是从/往文件系统以字符流读/写文件，还是往URL连接写HTML信息，或从URL连接读取参数值，都会有字符编码的转换。这样做虽然增加了编程的复杂度，容易引起混淆，但却是符合国际化的思想的。
从理论上来说，这些根据字符集设置而进行的字符转换不应该产生太多问题。而事实是由于应用程序的实际运行环境不同，Unicode和各个本地字符集的补充、完善，以及系统或应用程序实现的不规范，转码时出现的问题时时困扰着程序员和用户。
2.GB2312-80，GBK，GB18030-2000汉字字符集及Encoding
其实解决JAVA程序中的汉字编码问题的方法往往很简单，但理解其背后的原因，定位问题，还需要了解现有的汉字编码和编码转换。
GB2312-80是在国内计算机汉字信息技术发展初始阶段制定的，其中包含了大部分常用的一、二级汉字，和9区的符号。该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集，这也是最基本的中文字符集。其编码范围是高位0xa1－0xfe，低位也是0xa1-0xfe；汉字从0xb0a1开始，结束于0xf7fe；
GBK是GB2312-80的扩展，是向上兼容的。它包含了20902个汉字，其编码范围是0x8140-0xfefe，剔除高位0x80的字位。其所有字符都可以一对一映射到Unicode2.0，也就是说JAVA实际上提供了GBK字符集的支持。这是现阶段Windows和其它一些中文操作系统的缺省字符集，但并不是所有的国际化软件都支持该字符集，感觉是他们并不完全知道GBK是怎么回事。值得注意的是它不是国家标准，而只是规范。随着GB18030-2000国标的发布，它将在不久的将来完成它的历史使命。
GB18030-2000(GBK2K)在GBK的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。GBK2K从根本上解决了字位不够，字形不足的问题。它有几个特点，
它并没有确定所有的字形，只是规定了编码范围，留待以后扩充。
编码是变长的，其二字节部分与GBK兼容；四字节部分是扩充的字形、字位，其编码范围是首字节0x81-0xfe、二字节0x30-0x39、三字节0x81-0xfe、四字节0x30-0x39。
它的推广是分阶段的，首先要求实现的是能够完全映射到Unicode3.0标准的所有字形。
它是国家标准，是强制性的。
现在还没有任何一个操作系统或软件实现了GBK2K的支持，这是现阶段和将来汉化的工作内容。
Unicode的介绍......就免了吧。
JAVA支持的encoding中与中文编程相关的有：(有几个在JDK文档中未列出)ASCII7-bit,同ascii7
ISO8859-18-bit,同8859_1,ISO-8859-1,ISO_8859-1,latin1...
GB2312-80同gb2312,gb2312-1980,EUC_CN,euccn,1381,Cp1381,1383,Cp1383,ISO2022CN,ISO2022CN_GB......
GBK(注意大小写),同MS936
UTF8UTF-8
GB18030(现在只有IBMJDK1.3.?有支持),同Cp1392,1392
JAVA语言采用Unicode处理字符.但从另一个角度来说，在java程序中也可以采用非Unicode的转码，重要的是保证程序入口和出口的汉字信息不失真。如完全采用ISO-8859-1来处理汉字也能达到正确的结果。网络上流行的许多解决方法，都属于这种类型。为了不致引起混淆，本文不对这种方法作讨论。
3.中文转码时'?'、乱码的由来
两个方向转换都有可能得到错误的结果：
Unicode-->Byte,如果目标代码集不存在对应的代码，则得到的结果是0x3f.
如：
"\u00d6\u00ec\u00e9\u0046\u00bb\u00f9".getBytes("GBK")的结果是"?ìéF?ù",Hex值是3fa8aca8a6463fa8b4.
仔细看一下上面的结果，你会发现\u00ec被转换为0xa8ac,\u00e9被转换为\xa8a6...它的实际有效位变长了！这是因为GB2312符号区中的一些符号被映射到一些公共的符号编码，由于这些符号出现在ISO-8859-1或其它一些SBCS字符集中，故它们在Unicode中编码比较靠前，有一些其有效位只有8位，和汉字的编码重叠(其实这种映射只是编码的映射，在显示时仔细不是一样的。Unicode中的符号是单字节宽，汉字中的符号是双字节宽).在Unicode\u00a0--\u00ff之间这样的符号有20个。了解这个特征非常重要！由此就不难理解为什么JAVA编程中，汉字编码的错误结果中常常会出现一些乱码(其实是符号字符),而不全是'?'字符,就比如上面的例子。
Byte-->Unicode,如果Byte标识的字符在源代码集不存在，则得到的结果是0xfffd.
如：
Byteba[>={(byte)0x81,(byte)0x40,(byte)0xb0,(byte)0xa1};newString(ba,"gb2312");
结果是"?啊",hex值是"\ufffd\u554a".0x8140是GBK字符，按GB2312转换表没有对应的值，取\ufffd.(请注意：在显示该uniCode时，因为没有对应的本地字符，所以也适用上一种情况，显示为一个"?".)
实际编程中，JSP/Servlet程序得到错误的汉字信息，往往是这两个过程的叠加，有时甚至是两个过程叠加后反复作用的结果.
4.JSP/Servlet汉字编码问题及在WAS中的解决办法
4.1常见的encoding问题的现象
网上常出现的JSP/Servletencoding问题一般都表现在browser或应用程序端，如:
浏览器中看到的Jsp/Servlet页面中的汉字怎么都成了’?’?
浏览器中看到的Servlet页面中的汉字怎么都成了乱码？
JAVA应用程序界面中的汉字怎么都成了方块？
Jsp/Servlet页面无法显示GBK汉字。
JSP页面中内嵌在<%...%>,<%=...%>等Tag包含的JAVAcode中的中文成了乱码，但页面的其它汉字是对的。
Jsp/Servlet不能接收form提交的汉字。
JSP/Servlet数据库读写无法获得正确的内容。
隐藏在这些问题后面的是各种错误的字符转换和处理（除第3个外，是因为Javafont设置错误引起的）。解决类似的字符encoding问题，需要了解Jsp/Servlet的运行过程，检查可能出现问题的各个点。
4.2JSP/Servletweb编程时的encoding问题
运行于Java应用服务器的JSP/Servlet为Browser提供HTML内容，其过程如下图所示：
其中有字符编码转换的地方有:
JSP编译。Java应用服务器将根据JVM的file.encoding值读取JSP源文件，编译生成JAVA源文件，再根据file.encoding值写回文件系统。如果当前系统语言支持GBK，那么这时候不会出现encoding问题。如果是英文的系统，如LANG是en_US的Linux,AIX或Solaris，则要将JVM的file.encoding值置成GBK。系统语言如果是GB2312，则根据需要，确定要不要设置file.encoding，将file.encoding设为GBK可以解决潜在的GBK字符乱码问题
Java需要被编译为.class才能在JVM中执行，这个过程存在与a.同样的file.encoding问题。从这里开始servlet和jsp的运行就类似了，只不过Servlet的编译不是自动进行的。对于JSP程序,对产生的JAVA中间文件的编译是自动进行的(在程序中直接调用sun.tools.javac.Main类).因此如果在这一步出现问题的话,也要检查encoding和OS的语言环境，或者将内嵌在JSPJAVACode中的静态汉字转为Unicode,要么静态文本输出不要放在JAVAcode中。对于Servlet,javac编译时手工指定-encoding参数就可以了。
Servlet需要将HTML页面内容转换为browser可接受的encoding内容发送出去。依赖于各JAVAAppServer的实现方式，有的将查询Browser的accept-charset和accept-language参数或以其它猜的方式确定encoding值，有的则不管。因此采用固定encoding也许是最好的解决方法。对于中文网页，可在JSP或Servlet中设置contentType="text/html;charset=GB2312"；如果页面中有GBK字符，则设置为contentType="text/html;charset=GBK"，由于IE和Netscape对GBK的支持程度不一样，作这种设置时需要测试一下。
因为16位JAVAchar在网络传送时高8位会被丢弃，也为了确保Servlet页面中的汉字（包括内嵌的和servlet运行过程中得到的）是期望的内码，可以用PrintWriterout=res.getWriter()取代ServletOutputStreamout=res.getOutputStream().PrinterWriter将根据contentType中指定的charset作转换(ContentType需在此之前指定！);也可以用OutputStreamWriter封装ServletOutputStream类并用write(String)输出汉字字符串。
对于JSP，JAVAApplicationServer应当能够确保在这个阶段将嵌入的汉字正确传送出去。
这是解释URL字符encoding问题。如果通过get/post方式从browser返回的参数值中包含汉字信息，servlet将无法得到正确的值。SUN的J2SDK中，HttpUtils.parseName在解析参数时根本没有考虑browser的语言设置，而是将得到的值按byte方式解析。这是网上讨论得最多的encoding问题。因为这是设计缺陷，只能以bin方式重新解析得到的字符串；或者以hackHttpUtils类的方式解决。参考文章2均有介绍，不过最好将其中的中文encodingGB2312、CP1381都改为GBK，否则遇到GBK汉字时，还是会有问题。
ServletAPI2.3提供一个新的函数HttpServeletRequest.setCharacterEncoding用于在调用request.getParameter(“param_name”)前指定应用程序希望的encoding，这将有助于彻底解决这个问题。
4.3IBMWebsphereApplicationServer中的解决方法
WebSphereApplicationServer对标准的ServletAPI2.x作了扩展，提供较好的多语言支持。运行在中文的操作系统中，可以不作任何设置就可以很好地处理汉字。下面的说明只是对WAS是运行在英文的系统中，或者需要有GBK支持时有效。
上述c,d情况，WAS都要查询Browser的语言设置，在缺省状况下，zh,zh-cn等均被映射为JAVAencodingCP1381（注意：CP1381只是等同于GB2312的一个codepage，没有GBK支持）。这样做我想是因为无法确认Browser运行的操作系统是支持GB2312,还是GBK，所以取其小。但是实际的应用系统还是要求页面中出现GBK汉字，最著名的是朱总理名字中的“镕"(rong2，0xe946，\u9555)，所以有时还是需要将Encoding/Charset指定为GBK。当然WAS中变更缺省的encoding没有上面说的那么麻烦，针对a,b，参考文章5，在ApplicationServer的命令行参数中指定-Dfile.encoding=GBK即可；针对d，在ApplicationServer的命令行参数中指定-Ddefault.client.encoding=GBK。如果指定了-Ddefault.client.encoding=GBK，那么c情况下可以不再指定charset。
上面列出的问题中还有一个关于Tag<%...%>,<%=...%>中的JAVA代码里包含的静态文本未能正确显示的问题，在WAS中的解决方法是除了设置正确的file.encoding,还需要以相同方法设置-Duser.language=zh-Duser.region=CN。这与JAVAlocale的设置有关。
4.4数据库读写时的encoding问题
JSP/Servlet编程中经常出现encoding问题的另一个地方是读写数据库中的数据。
流行的关系数据库系统都支持数据库encoding，也就是说在创建数据库时可以指定它自己的字符集设置，数据库的数据以指定的编码形式存储。当应用程序访问数据时，在入口和出口处都会有encoding转换。对于中文数据，数据库字符编码的设置应当保证数据的完整性.GB2312，GBK，UTF-8等都是可选的数据库encoding；也可以选择ISO8859-1(8-bit)，那么应用程序在写数据之前须将16Bit的一个汉字或Unicode拆分成两个8-bit的字符，读数据之后则需将两个字节合并起来，同时还要判别其中的SBCS字符。没有充分利用数据库encoding的作用，反而增加了编程的复杂度，ISO8859-1不是推荐的数据库encoding。JSP/Servlet编程时，可以先用数据库管理系统提供的管理功能检查其中的中文数据是否正确。
然后应当注意的是读出来的数据的encoding，JAVA程序中一般得到的是Unicode。写数据时则相反。
4.5定位问题时常用的技巧
定位中文encoding问题通常采用最笨的也是最有效的办法——在你认为有嫌疑的程序处理后打印字符串的内码。通过打印字符串的内码，你可以发现什么时候中文字符被转换成Unicode，什么时候Unicode被转回中文内码，什么时候一个中文字成了两个Unicode字符，什么时候中文字符串被转成了一串问号，什么时候中文字符串的高位被截掉了……
取用合适的样本字符串也有助于区分问题的类型。如：”aa啊aa丂aa”等中英相间、GB、GBK特征字符均有的字符串。一般来说，英文字符无论怎么转换或处理，都不会失真（如果遇到了，可以尝试着增加连续的英文字母长度）。
5.结束语
其实JSP/Servlet的中文encoding并没有想像的那么复杂，虽然定位和解决问题没有定规，各种运行环境也各不尽然，但后面的原理是一样的。了解字符集的知识是解决字符问题的基础。不过，随着中文字符集的变化，不仅仅是java编程，中文信息处理中的问题还是会存在一段时间的。
...........................UB修改于2002-06-14 10:52:07
RE:JAVA编程技术中汉字问题的分析及解决(转)
作者：UB 时间：2002-07-22 17:04:00 [修改] [回复] [删除]
JAVA编程技术中汉字问题的分析及解决
文章来源：www.ibm.com
在基于Java语言的编程中，我们经常碰到汉字的处理及显示的问题。一大堆看不懂的乱码肯定不是我们愿意看到的显示效果，怎样才能够让那些汉字正确显示呢？Java语言默认的编码方式是UNICODE，而我们中国人通常使用的文件和数据库都是基于GB2312或者BIG5等方式编码的，怎样才能够恰当地选择汉字编码方式并正确地处理汉字的编码呢？本文将从汉字编码的常识入手，结合Java编程实例，分析以上两个问题并提出解决它们的方案。
现在Java编程语言已经广泛应用于互联网世界，早在Sun公司开发Java语言的时候，就已经考虑到对非英文字符的支持了。Sun公司公布的Java运行环境（JRE）本身就分英文版和国际版，但只有国际版才支持非英文字符。不过在Java编程语言的应用中，对中文字符的支持并非如同JavaSoft的标准规范中所宣称的那样完美，因为中文字符集不只一个，而且不同的操作系统对中文字符的支持也不尽相同，所以会有许多和汉字编码处理有关的问题在我们进行应用开发中困扰着我们。有很多关于这些问题的解答，但都比较琐碎，并不能够满足大家迫切解决问题的愿望，关于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修改过的数据库的内容在别的场合应用时无法继续正确地提供信息。
StringsEnglish=“apple”;
StringsChinese=“苹果”;
Strings=“苹果apple”;
sEnglish的长度是5，sChinese的长度是4，而s默认的长度是14。对于sEnglish来说，Java中的各个类都支持得非常好，肯定能够正确显示。但对于sChinese和s来说，虽然JavaSoft声明Java的基本类已经考虑到对多国字符的支持（默认UNICODE编码），但是如果操作系统的默认编码不是UNICODE，而是国标码等。从Java源代码到得到正确的结果，要经过“Java源代码->Java字节码->;虚拟机->操作系统->显示设备”的过程。在上述过程中的每一步骤，我们都必须正确地处理汉字的编码，才能够使最终的显示结果正确。
“Java源代码->Java字节码”，标准的Java编译器javac使用的字符集是系统默认的字符集，比如在中文Windows操作系统上就是GBK,而在Linux操作系统上就是ISO-8859-1，所以大家会发现在Linux操作系统上编译的类中源文件中的中文字符都出了问题，解决的办法就是在编译的时候添加encoding参数，这样才能够与平台无关。用法是
javac–encodingGBK。
“Java字节码->虚拟机->操作系统”，Java运行环境（JRE）分英文版和国际版，但只有国际版才支持非英文字符。Java开发工具包（JDK）肯定支持多国字符，但并非所有的计算机用户都安装了JDK。很多操作系统及应用软件为了能够更好的支持Java，都内嵌了JRE的国际版本，为自己支持多国字符提供了方便。
“操作系统->显示设备”，对于汉字来说，操作系统必须支持并能够显示它。英文操作系统如果不搭配特殊的应用软件的话，是肯定不能够显示中文的。
还有一个问题，就是在Java编程过程中，对中文字符进行正确的编码转换。例如，向网页输出中文字符串的时候，不论你是用
out.println(string);//string是含中文的字符串
还是用
<%=string%>，都必须作UNICODE到GBK的转换，或者手动，或者自动。在JSP1.0中，可以定义输出字符集，从而实现内码的自动转换。用法是
<%@pageContentType=”text/html;charset=gb2312”%>
但是在一些JSP版本中并没有提供对输出字符集的支持，（例如JSP0.92），这就需要手动编码输出了，方法非常多。最常用的方法是
Strings1=request.getParameter(“keyword”);
Strings2=newString(s1.getBytes(“ISO-8859-1”),”GBK”);
getBytes方法用于将中文字符以“ISO-8859-1”编码方式转化成字节数组，而“GBK”是目标编码方式。我们从以ISO-8859-1方式编码的数据库中读出中文字符串s1，经过上述转换过程，在支持GBK字符集的操作系统和应用软件中就能够正确显示中文字符串s2。
Java中文问题的表层分析及处理
背景
开发环境JDK1.15Vcafe2.0JPadPro
服务器端NTIISSybaseSystemJconnect（JDBC）
客户端IE5.0Pwin98
CLASS文件存放在服务器端，由客户端的浏览器运行APPLET，APPLET只起调入FRAME类等主程序的作用。界面包括Textfield，TextArea，List，Choice等。
I.取中文
用JDBC执行SELECT语句从服务器端读取数据（中文）后，将数据用APPEND方法加到TextArea（TA），不能正确显示。但加到List中时，大部分汉字却可正确显示。
将数据按“ISO-8859-1”编码方式转化为字节数组，再按系统缺省编码方式（DefaultCharacterEncoding）转化为STRING，即可在TA和List中正确显示。
程序段如下：
dbstr2=results.getString(1);
//AfterreadingtheresultfromDBserver，convertingittostring.
dbbyte1=dbstr2.getBytes(“iso-8859-1”);
dbstr1=newString(dbbyte1);
在转换字符串时不采用系统默认编码方式，而直接采用“GBK”或者“GB2312”,在A和B两种情况下，从数据库取数据都没有问题。
II.写中文到数据库
处理方式与“取中文”相逆，先将SQL语句按系统缺省编码方式转化为字节数组，再按“ISO-8859-1”编码方式转化为STRING，最后送去执行，则中文信息可正确写入数据库。
程序段如下：
sqlstmt=tf_input.getText();
//BeforesendingstatementtoDBserver，convertingittosqlstatement.
dbbyte1=sqlstmt.getBytes();
sqlstmt=newString(dbbyte1,”iso-8859-1”);
_stmt=_con.createStatement();
_stmt.executeUpdate(sqlstmt);
……
问题：如果客户机上存在CLASSPATH指向JDK的CLASSES.ZIP时（称为A情况），上述程序代码可正确执行。但是如果客户机只有浏览器，而没有JDK和CLASSPATH时（称为B情况），则汉字无法正确转换。
我们的分析：
1.经过测试，在A情况下，程序运行时系统的缺省编码方式为GBK或者GB2312。在B情况下，程序启动时浏览器的JAVA控制台中出现如下错误信息：
Can'tfindresourceforsun.awt.windows.awtLocalization_zh_CN
然后系统的缺省编码方式为“8859-1”。
2.如果在转换字符串时不采用系统缺省编码方式，而是直接采用“GBK”或“GB2312”，则在A情况下程序仍然可正常运行，在B情况下，系统出现错误：
UnsupportedEncodingException。
3.在客户机上，把JDK的CLASSES.ZIP解压后，放在另一个目录中，CLASSPATH只包含该目录。然后一边逐步删除该目录中的.CLASS文件，另一边运行测试程序，最后发现在一千多个CLASS文件中，只有一个是必不可少的，该文件是：sun.io.CharToByteDoubleByte.class。
将该文件拷到服务器端和其它的类放在一起，并在程序的开头IMPORT它，在B情况下程序仍然无法正常运行。
4.在A情况下，如果在CLASSPTH中去掉sun.io.CharToByteDoubleByte.class，则程序运行时测得默认编码方式为“8859-1”，否则为“GBK”或“GB2312”。
如果JDK的版本为1.2以上的话，在B情况下遇到的问题得到了很好的解决，测试的步骤同上，有兴趣的读者可以尝试一下。
Java中文问题的根源分析及解决
在简体中文MSWindows98+JDK1.3下，可以用System.getProperties()得到Java运行环境的一些基本属性，类PoorChinese可以帮助我们得到这些属性。
类PoorChinese的源代码：
publicclassPoorChinese{
publicstaticvoidmain(String[>args){
System.getProperties().list(System.out);
}
}
执行javaPoorChinese后，我们会得到:
系统变量file.encoding的值为GBK，user.language的值为zh，user.region的值为CN，这些系统变量的值决定了系统默认的编码方式是GBK。
在上述系统中，下面的代码将GB2312文件转换成Big5文件，它们能够帮助我们理解Java中汉字编码的转化:
importjava.io.*;
importjava.util.*;
publicclassgb2big5{
staticintiCharNum=0;
publicstaticvoidmain(String[>args){
System.out.println("InputGB2312file,outputBig5file.");
if(args.length!=2){
System.err.println("Usage:jviewgb2big5gbfilebig5file");
System.exit(1);
}
StringinputString=readInput(args[0>);
writeOutput(inputString,args[1>);
System.out.println("NumberofCharactersinfile:"+iCharNum+".");
}
staticvoidwriteOutput(Stringstr,StringstrOutFile){
try{
FileOutputStreamfos=newFileOutputStream(strOutFile);
Writerout=newOutputStreamWriter(fos,"Big5");
out.write(str);
out.close();
}
catch(IOExceptione){
e.printStackTrace();
e.printStackTrace();
}
}
staticStringreadInput(StringstrInFile){
StringBufferbuffer=newStringBuffer();
try{
FileInputStreamfis=newFileInputStream(strInFile);
InputStreamReaderisr=newInputStreamReader(fis,"GB2312");
Readerin=newBufferedReader(isr);
intch;
while((ch=in.read())>-1){
iCharNum+=1;
buffer.append((char)ch);
}
in.close();
returnbuffer.toString();
}
catch(IOExceptione){
e.printStackTrace();
returnnull;
}
}
}
编码转化的过程如下：
ByteToCharGB2312CharToByteBig5
GB2312------------------>Unicode------------->Big5
执行javagb2big5gb.txtbig5.txt，如果gb.txt的内容是“今天星期三”，则得到的文件big5.txt中的字符能够正确显示；而如果gb.txt的内容是“情人节快乐”，则得到的文件big5.txt中对应于“节”和“乐”的字符都是符号“？”（0x3F），可见sun.io.ByteToCharGB2312和sun.io.CharToByteBig5这两个基本类并没有编好。
正如上例一样，Java的基本类也可能存在问题。由于国际化的工作并不是在国内完成的，所以在这些基本类发布之前，没有经过严格的测试，所以对中文字符的支持并不像JavaSoft所声称的那样完美。前不久，我的一位技术上的朋友发信给我说，他终于找到了JavaServlet中文问题的根源。两周以来，他一直为JavaServlet的中文问题所困扰，因为每面对一个含有中文字符的字符串都必须进行强制转换才能够得到正确的结果（这好象是大家公认的唯一的解决办法）。后来，他确实不想如此继续安分下去了，因为这样的事情确实不应该是高级程序员所要做的工作，他就找出Servlet解码的源代码进行分析，因为他怀疑问题就出在解码这部分。经过四个小时的奋斗，他终于找到了问题的根源所在。原来他的怀疑是正确的，Servlet的解码部分完全没有考虑双字节，直接把%XX当作一个字符。（原来JavaSoft也会犯这幺低级的错误！）
如果你对这个问题有兴趣或者遇到了同样的烦恼的话，你可以按照他的步骤对Servlet.jar进行修改：
找到源代码HttpUtils中的staticprivateStringparseName，在返回前将sb（StringBuffer）复制成bytebs[>，然后returnnewString(bs,”GB2312”)。作上述修改后就需要自己解码了：
HashTableform=HttpUtils.parseQueryString(request.getQueryString())或者
form=HttpUtils.parsePostData(……)
千万别忘了编译后放到Servlet.jar里面。
五、关于Java中文问题的总结
Java编程语言成长于网络世界，这就要求Java对多国字符有很好的支持。Java编程语言适应了计算的网络化的需求，为它能够在网络世界迅速成长奠定了坚实的基础。Java的缔造者（JavaSoft）已经考虑到Java编程语言对多国字符的支持，只是现在的解决方案有很多缺陷在里面，需要我们付诸一些补偿性的措施。而世界标准化组织也在努力把人类所有的文字统一在一种编码之中，其中一种方案是ISO10646，它用四个字节来表示一个字符。当然，在这种方案未被采用之前，还是希望JavaSoft能够严格地测试它的产品，为用户带来更多的方便。
附一个用于从数据库和网络中取出中文乱码的处理函数，入参是有问题的字符串，出参是问题已经解决了的字符串。
StringparseChinese(Stringin)
{
Strings=null;
bytetemp[>;
if(in==null)
{
System.out.println("Warn:Chinesenullfounded!");
returnnewString("");
}
try
{
temp=in.getBytes("iso-8859-1");
s=newString(temp);
}
catch(UnsupportedEncodingExceptione)
{
System.out.println(e.toString());
}
returns;
}
|