java中文字符编码3

在网上找了一些代码想自己运行出来看看效果,但是一直因为有中文编码所以保存不成功,在jsp页面最上边加上

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>

后问题解决。

顺便找了些java中文编码问题的整理,以防再遇见此类问题。

http://www.chinajavaworld.net/doc/lang/74.html 

汉字问题深入谈  
   
一、主题:关于JAVA的中文问题  
        JAVA的中文问题比较突出,主要表现在控制面板输出,JSP页面输出和数据库访问上。  
本文尽量避开字体问题,而只谈编码。通过本文,你可以了解JAVA中文问题的由来,问题  
的解决方法,其中提了一下用JDBC访问数据库的方法。  
   
二、问题描述:  
1)在中文W2000中文窗口编译和运行,用的是国际版的JDK,连接的是中文W2000下的Cp936  
编码的SQL   SERVER数据库:  
   
J:\exercise\demo\encode\HelloWorld> make  
      Created   by   XCompiler.   PhiloSoft   All   Rights   Reserved.  
      Wed   May   30   02:54:45   CST   2001  
   
J:\exercise\demo\encode\HelloWorld> run  
      Created   by   XRunner.   PhiloSoft   All   Rights   Reserved.  
      Wed   May   30   02:51:33   CST   2001  
中文  
[B@7bc8b569  
[B@7b08b569  
[B@7860b569  
中文  
中文  
????  
中文  
中文  
????  
??  
??  
??  
   
2)如果在中文W2000的西文窗口(编码为437)下编译,用JAVA运行则由于无字体而无法正  
常显示,如果象上面一样在中文W2000的中文窗口运行,输出为:  
   
J:\exercise\demo\encode\HelloWorld> run  
      Created   by   XRunner.   PhiloSoft   All   Rights   Reserved.  
      Wed   May   30   02:51:33   CST   2001  
????  
[B@7bc0b66a  
[B@7b04b66a  
[B@7818b66a  
????  
????  
????  
????  
????  
????  
中文  
中文  
????  
   
三)分析  
   
1)出现有乱码(也就是?)。由于只出现?而没出现小方框,说明只是编码有问题,而不  
是字体问题。   在编码中,如果从一种字符集转换到别一种字符集,比较典型的是从GB2312  
转换到ISO8859_1(即ASCII),那么很多汉字(半个汉字)是无法映射到西文字符中去的  
,在这种情形下,系统就把这些字符用?代替。同样,也存在小字符集无法到大字符集的  
情况,具体原因这里就不详谈了。  
   
2)出现了中文环境编译,中文环境运行时汉字显示有正确也有不正确的地方,同样,在西  
文环境下编译,在中文环境下运行时也出现类似情况。这是由于自动(默认)或手工(也  
就new   String(bytes[,encode])和bytes   getBytes([encode]))转码的结果。  
   
2.1)在JAVA源文件--> JAVAC--> Class--> Java--> getBytes()--> new   String()--> 显示的过  
程中,每一步都有编码的转换过程,这个过程总是存在的,只是有的时候用默认的参数进  
行。下面我们一步一步分析为什么出现上面的情形。  
   
2.2)这里是源代码:  
   
HelloWorld.java:  
------------------------  
public   class   HelloWorld  
{  
public   static   void   main(String[]   argv){  
        try{  
System.out.println( "中文 ");//1  
System.out.println( "中文 ".getBytes());//2  
System.out.println( "中文 ".getBytes( "GB2312 "));//3  
System.out.println( "中文 ".getBytes( "ISO8859_1 "));//4  
   
System.out.println(new   String( "中文 ".getBytes()));//5  
System.out.println(new   String( "中文 ".getBytes(), "GB2312 "));//6  
System.out.println(new   String( "中文 ".getBytes(), "ISO8859_1 "));//7  
   
System.out.println(new   String( "中文 ".getBytes( "GB2312 ")));//8  
System.out.println(new   String( "中文 ".getBytes( "GB2312 "), "GB2312 "));//9  
System.out.println(new  
   
String( "中文 ".getBytes( "GB2312 "), "ISO8859_1 "));//10  
   
System.out.println(new   String( "中文 ".getBytes( "ISO8859_1 ")));//11  
System.out.println(new  
   
String( "中文 ".getBytes( "ISO8859_1 "), "GB2312 "));//12  
System.out.println(new  
   
String( "中文 ".getBytes( "ISO8859_1 "), "ISO8859_1 "));//13  
}  
catch(Exception   e){  
e.printStackTrace();  
}  
    }  
}  
   
为了方便起见,在每个转换的后面加了操作序号,分别为1,2,...,13。  
   
2.3)需要说明的是,JAVAC是以系统默认编码读入源文件,然后按UNICODE进行编码的。在  
JAVA运行的时候,JAVA也是采用UNICODE编码的,并且默认输入和输出的都是操作系统的默  
认编码,也就是说在new   String(bytes[,encode])中,系统认为输入的是编码为encode的  
字节流,换句话说,如果按encode来翻译bytes才能得到正确的结果,这个结果最后要在JA  
VA中保存,它还是要从这个encode转换成Unicode,也就是说有bytes--> encode字符--> Uni  
code字符的转换;而在String.getBytes([encode])中,系统要做一个Unicode字符--> enco  
de字符--> bytes的转换。  
   
在这个例子中,除那个英文窗口编码的时候除外,其实情形下默认编码都是GBK(在本例中  
,我们暂且把GBK和GB2312等同看待)。  
   
2.4)由于在未指明在上面的两个用代码实现的转换中,如果未指定encode,系统将采用默  
认的编码(这里为GBK),我们认为上面的5,6,7和8,9,10是一样的,8和9、11和12也是一  
样的,所以我们在讨论中将只讨论1,9,10,12,13。其中的2,3,4只是用于测试,不在我们的  
讨论范围之内。  
   
2.5)下面我们来跟踪程序中的“中”字的转换历程,我们先说在中文窗口下作的编译和运  
行过程,注意在下面的字母下标中,我有意识地使用了一些数字,以表示相同,相异还是  
相关2.5.1)我们先以上面的13个代码段中的的代码9为例:  
   
步骤   内容   地点   说明  
01:   C1   HelloWorld.java   C1泛指一个GBK字符  
02:   U1   JAVAC读取   U1泛指一个Unicode字符  
03:   C1   getBytes()第一步   JAVA先和操作系统交流  
04:   B1,B2   getBytes()第二步   然后返回字节数组  
05:   C1   new   String()第一步   JAVA先和操作系统交流  
06:   U1   new   String()第二步   然后返回字符  
07:   C1   println(String)   能显示“中”字,内容和原来的相同  
   
2.5.2)然后再以代码段10为例,我们注意到只是:  
   
步骤   内容   地点   说明  
01:   C1   HelloWorld.java   C1泛指一个GBK字符  
02:   U1   JAVAC读取   U1泛指一个Unicode字符  
03:   C1   getBytes()第一步   JAVA先和操作系统交流  
04:   B1,B2   getBytes()第二步   然后返回字节数组  
05:   C3,C4   new   String()第一步   JAVA先和操作系统交流,这时解析错误  
06:   U5,U6   new   String()第二步   然后返回字符  
07:   C3,C4   println(String)   由于中字给分成了两半,在ISO8859_1中刚好也没有字符  
   
能映射上,所以显示为“??”。在上面的示例中,  
“中文”两个字就显示为“????”  
2.5.3)在完全中文模式下的其它情形类似,我就不多说了  
   
2.6)我们接着看为什么在西文DOS窗口下编译出来的类在中文窗口下也出现类似情形,特  
别是为什么居然有的情形下还能正确显示汉字。  
   
2.6.1)我们还是先以代码段9为例:  
   
步骤   内容   地点   说明  
01:   C1C2   HelloWorld.java   C1C2分别泛指一个ISO8859_1字符,“中”字被拆开  
02:   U3U4   JAVAC读取   U1U2泛指一个Unicode字符  
03:   C5C6   getBytes()第一步   JAVA先和操作系统交流,这时解析错误  
04:   B5B6B7B8   getBytes()第二步   然后返回字节数组  
05:   C5C6   new   String()第一步   JAVA先和操作系统交流  
06:   U3U4   new   String()第二步   然后返回字符  
07:   C5C6   println(String)   虽然同是两个字符,但已不是最初的“两个ISO8859_1字  
   
符”,而是“两个BGK字符”,“中”显示成了“??”  
而“中文”就显示成了“????”  
   
2.6.2)下面我们以代码段12为例,因为它能正确显示汉字  
   
步骤   内容   地点   说明  
   
01:   C1C2   HelloWorld.java   C1C2分别泛指一个ISO8859_1字符,“中”字被拆开  
02:   U3U4   JAVAC读取   U1U2泛指一个Unicode字符  
03:   C1C2   getBytes()第一步   JAVA先和操作系统交流(注意还是正确的哦!)  
04:   B5B6   getBytes()第二步   然后返回字节数组(这是很关键的一步!)  
05:   C12   new   String()第一步   JAVA先和操作系统交流(这是更关键的一步,JAVA已经知  
道B5B6要解析成一个汉字!)  
06:   U7   new   String()第二步   然后返回字符(真是一个项两!U7包含了U3U4的信息)  
07:   C12   println(String)   这就原来的“中”字,很委屈被JAVAC冤枉了一回,不过被程  
序员拨乱反正了一下!当然,“中文”两个字都能正确显示了!  
   
3)那为什么有的时候用JDBC的  
new   String(Recordset.getBytes(int)[,encode])  
Recordset.getSting(int)  
Recordset.setBytes(String.getBytes([encode]))  
和  
Recordset.setString(String)  
的时候会出现乱码了呢?  
   
其实问题就出现在编写JDBC的的也考虑了编码问题,它从数据库读取数据后,可能自作主  
张做了一个从GB2312(默认编码)到Unicode的转换,我的这个WebLogic   For   SQL   Server  

的JDBC   Driver就是这样的,当我读字串的时候,发出读到的不是正确的汉字,可恨的是我  
却可以直接写汉字字串,这让人多少有点难以接受!  
也就是说,我们不得不在读或写的时候进行转码,尽管这个转码有的时候不是那么明显,  
这是因为我们使用了默认的编码进行转码。JDBC   Driver所做的操作,我们只有进入到源代  
码内部才能清楚,不是吗?

Java   编程技术中汉字问题的分析及解决   (一)
                                                                                  段明辉  
                                                                                自由撰稿人  
                                                                                2000   年   11月   8日  
   
        在基于   Java   语言的编程中,我们经常碰到汉字的处理及显示的问题。  
一大堆看不懂的乱码肯定不是我们愿意看到的显示效果,怎样才能够让那些  
汉字正确显示呢?Java   语言默认的编码方式是UNICODE,而我们中国人通常  
使用的文件和数据库都是基于   GB2312   或者   BIG5   等方式编码的,怎样才能  
够恰当地选择汉字编码方式并正确地处理汉字的编码呢?本文将从汉字编码  
的常识入手,结合   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   –encoding   GBK。  
   
“   Java   字节码-> 虚拟机-> 操作系统”,   Java   运行环境   (JRE)     分英文  
版和国际版,但只有国际版才支持非英文字符。   Java   开发工具包   (JDK)  
肯定支持多国字符,但并非所有的计算机用户都安装了   JDK   。   很多操作系  
统及应用软件为了能够更好的支持   Java   ,都内嵌了   JRE   的国际版本,   为  
自己支持多国字符提供了方便。  
   
“操作系统-> 显示设备”,对于汉字来说,操作系统必须支持并能够显示它。  
英文操作系统如果不搭配特殊的应用软件的话,是肯定不能够显示中文的。  
   
还有一个问题,就是在   Java   编程过程中,对中文字符进行正确的编码转换。  
例如,向网页输出中文字符串的时候,不论你是用  
   
out.println(string);还是用  
   
< %=string%> ,都必须作   UNICODE   到   GBK   的转换,或者手动,或者自动。  
在   JSP   1.0中,可以定义输出字符集,从而实现内码的自动转换。用法是  
   
< %@page   ContentType=”text/html;charset=gb2312”   %>  
   
但是在一些   JSP   版本中并没有提供对输出字符集的支持,(例如JSP   0.92),  
这就需要手动编码输出了,方法非常多。最常用的方法是  
   
String   s1   =   request.getParameter(“keyword”);  
   
String   s2   =   new   String(s1.getBytes(“ISO-8859-1”),”GBK”);  
   
getBytes   方法用于将中文字符以“ISO-8859-1”编码方式转化成字节数组,  
而“GBK”   是目标编码方式。我们从以ISO-8859-1方式编码的数据库中读出  
中文字符串   s1   ,经过上述转换过程,在支持   GBK     字符集的操作系统和应  
用软件中就能够正确显示中文字符串   s2   。  
   
Java   中文问题的表层分析及处理  
   
背景  
┏━━━━┳━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━┓  
┃开发环境┃JDK   1.15┃     Vcafe2.0             ┃   JPadPro                                         ┃  
┣━━━━╋━━━━╋━━━━━━━━╋━━━━━━━━━━━━━━┫  
┃服务器端┃   NT   IIS   ┃     Sybase   System   ┃   Jconnect(JDBC)                       ┃  
┣━━━━╋━━━━╋━━━━━━━━╋━━━━━━━━━━━━━━┫  
┃客户端     ┃     IE5.0   ┃         Pwin98             ┃?span   lang= "EN-US "                     ┃  
┃                 ┃                 ┃                                 ┃style= "font-family:宋体;         ┃  
┃                 ┃                 ┃                                 ┃mso-hansi-font-family:Times   ┃  
┃                 ┃                 ┃                                 ┃New   Roman ">                                   ┃  
┗━━━━┻━━━━┻━━━━━━━━┻━━━━━━━━━━━━━━┛  
.CLASS   文件存放在服务器端,由客户端的浏览器运行   APPLET   ,   APPLET  
只起调入   FRAME   类等主程序的作用。界面包括   Textfield   ,TextArea,  
List,Choice   等。  
   
I.用   JDBC   执行   SELECT   语句从服务器端读取数据(中文)后,   将数据用  
APPEND   方法加到   TextArea(TA)   ,不能正确显示。但加到   List   中时,大  
部分汉字却可正确显示。  
   
将数据按“ISO-8859-1”   编码方式转化为字节数组,再按系统缺省编码方式  
(Default   Character   Encoding)   转化为   STRING   ,即可在   TA   和   List   中  
正确显示。  
   
程序段如下:  
   
dbstr2   =   results.getString(1);  
   
//After   reading   the   result   from   DB   server,converting   it   to   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   statement   to   DB   server,converting   it   to   sql   statement.  
   
   
dbbyte1   =   sqlstmt.getBytes();  
   
sqlstmt   =   newString(dbbyte1,”iso-8859-1”);  
   
_stmt   =   _con.createStatement();  
   
_stmt.executeUpdate(sqlstmt);  
   
……

Java   编程技术中汉字问题的分析及解决   (二)    
问题:如果客户机上存在   CLASSPATH   指向   JDK   的   CLASSES.ZIP   时(称为A  
情况),上述程序代码可正确执行。但是如果客户机只有浏览器,而没有  
JDK   和   CLASSPATH   时(称为   B   情况),则汉字无法正确转换。  
   
我们的分析:  
   
1.经过测试,在   A   情况下,程序运行时系统的缺省编码方式为   GBK   或者  
GB2312   。在   B   情况下,程序启动时浏览器的   JAVA   控制台中出现如下错  
误信息:  
   
Can 't   find   resource   for   sun.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   中文问题的根源分析及解决  
   
在简体中文   MS   Windows   98   +   JDK   1.3   下可以用System.getProperties()  
得到   Java   运行环境的一些基本属性,类   PoorChinese   可以帮助我们得到  
这些属性。  
   
类   PoorChinese   的源代码:  
   
public   class   PoorChinese   {  
   
}  
   
执行   java   PoorChinese   后,我们会得到:  
   
系统变量   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)   {  
    System.err.println( "Usage:   jview   gb2big5   gbfile   big5file ");  
    System.exit(1);  
    String   inputString   =   readInput(args[0]);  
    writeOutput(inputString,args[1]);  
    System.out.println( "Number   of   Characters   in   file:   "+iCharNum+ ". ");  
  }  
?  
static   void   writeOutput(String   str,   String   strOutFile)   {  
  try   {  
    FileOutputStream   fos   =   new   FileOutputStream(strOutFile);  
    Writer   out   =   new   OutputStreamWriter(fos,   "Big5 ");  
    out.write(str);  
    out.close();  
  }  
  catch   (IOException   e)   {  
    e.printStackTrace();  
    e.printStackTrace();  
  }  
}  
?  
static   String   readInput(String   strInFile)   {  
  StringBuffer   buffer   =   new   StringBuffer();  
  try   {  
    FileInputStream   fis   =   new   FileInputStream(strInFile);  
    InputStreamReader   isr   =   new   InputStreamReader(fis,   "GB2312 ");  
    Reader   in   =   new   BufferedReader(isr);  
    int   ch;  
    while   ((ch   =   in.read())   >   -1)   {  
      iCharNum   +=   1;  
      buffer.append((char)ch);  
    }  
    in.close();  
    return   buffer.toString();  
  }  
  catch   (IOException   e)   {  
    e.printStackTrace();  
    return   null;  
  }  
}  
}  
   
?  
   
编码转化的过程如下:  
   
GB2312------------------> Unicode-------------> Big5  
   
执行   java   gb2big5   gb.txt   big5.txt   ,如果   gb.txt   的内容是“今天星期  
三”,则得到的文件   big5.txt   中的字符能够正确显示;而如果   gb.txt   的  
内容是“情人节快乐”,则得到的文件   big5.txt   中对应于“节”和“乐”  
的字符都是符号“?”(0x3F),可见   sun.io.ByteToCharGB2312       和  
sun.io.CharToByteBig5   这两个基本类并没有编好。  
   
正如上例一样,   Java   的基本类也可能存在问题。由于国际化的工作并不是  
在国内完成的,所以在这些基本类发布之前,没有经过严格的测试,所以对  
中文字符的支持并不像   Java   Soft   所声称的那样完美。前不久,   我的一位  
技术上的朋友发信给我说,他终于找到了   Java   Servlet   中文问题的根源。  
两周以来,他一直为   Java   Servlet   的中文问题所困扰,因为每面对一个含  
有中文字符的字符串都必须进行强制转换才能够得到正确的结果(这好象是  
大家公认的唯一的解决办法)。后来,他确实不想如此继续安分下去了,因  
为这样的事情确实不应该是高级程序员所要做的工作,他就找出   Servlet  
解码的源代码进行分析,因为他怀疑问题就出在解码这部分。经过四个小时  
的奋斗,他终于找到了问题的根源所在。原来他的怀疑是正确的,   Servlet  
的解码部分完全没有考虑双字节,直接把   %XX   当作一个字符。(原来   Java  
Soft   也会犯这幺低级的错误!)  
   
如果你对这个问题有兴趣或者遇到了同样的烦恼的话,你可以按照他的步骤  
对   Servlet.jar   进行修改:  
   
找到源代码   HttpUtils   中的   static   private   String   parseName   ,在返回  
前将   sb(StringBuffer)   复制成   byte   bs[]   ,然后   return   new   String  
(bs,”GB2312”)。作上述修改后就需要自己解码了:  
   
HashTable   form=HttpUtils.parseQueryString(request.getQueryString())  
或者   form=HttpUtils.parsePostData(……)  
千万别忘了编译后放到   Servlet.jar   里面。  
   
五、   关于   Java   中文问题的总结  
   
Java   编程语言成长于网络世界,这就要求   Java   对多国字符有很好的支持。  
Java   编程语言适应了计算的网络化的需求,为它能够在网络世界迅速成长  
奠定了坚实的基础。   Java   的缔造者   (Java   Soft)   已经考虑到   Java   编  
程语言对多国字符的支持,只是现在的解决方案有很多缺陷在里面,   需要  
我们付诸一些补偿性的措施。   而世界标准化组织也在努力把人类所有的文  
字统一在一种编码之中,其中一种方案是   ISO10646   ,   它用四个字节来表  
示一个字符。当然,在这种方案未被采用之前,还是希望   Java   Soft   能够  
严格地测试它的产品,为用户带来更多的方便。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值