汉字问题深入谈

热门软件: QQ 瑞星 pplive e话通木马克星千千静听 office2000 五笔字根 Photoshop 视频分割

返回文章教程首页 >> 文章首页 >> 编程技术 >> JAVA教程 >> 汉字问题深入谈

汉字问题深入谈

添加时间: 2006-2-19 6:27:27 作者: JAVA教程阅读次数:187 来源: http://www.d9soft.com

　　一、主题：关于JAVA的中文问题
JAVA的中文问题比较突出，主要表现在控制面板输出，JSP页面输出和数据库访问上。本文尽量避开字体问题，而只谈编码。通过本文，你可以了解JAVA中文问题的由来，问题的解决方法，其中提了一下用JDBC访问数据库的方法。

　　二、问题描述：
　　1）在中文W2000中文窗口编译和运行，用的是国际版的JDK，连接的是中文W2000下的Cp936编码的SQL SERVER数据库：

　　J:exercisedemoencodeHelloWorld>make
Created by XCompiler. PhiloSoft All Rights Reserved.
Wed May 30 02:54:45 CST 2001

　　J:exercisedemoencodeHelloWorld>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:exercisedemoencodeHelloWorld>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("2:"+"中文".getBytes());
System.out.println("3:"+"中文".getBytes("GB2312"));
System.out.println("4:"+"中文".getBytes("ISO8859_1"));

System.out.println("5:"+new String("中文".getBytes()));//5
System.out.println("6:"+new String("中文".getBytes(),"GB2312"));
System.out.println("7:"+new String("中文".getBytes(),"ISO8859_1"));

System.out.println("8:"+new String("中文".getBytes("GB2312")));//8
System.out.println("9:"+new String("中文".getBytes("GB2312"),"GB2312"));
System.out.println("10:"+new String("中文".getBytes("GB2312"),"ISO8859_1"));

System.out.println("11:"+new String("中文".getBytes("ISO8859_1")));//11
System.out.println("12:"+new String("中文".getBytes("ISO8859_1"),"GB2312"));
System.out.println("13:"+new String("中文".getBytes("ISO8859_1"),"ISO8859_1"));
}
catch(Exception e)
{
e.printStackTrace();
}
}
}

　　为了方便起见，在每个转换的后面加了操作序号，分别为1,2,...,13。

　　2.3）需要说明的是，JAVAC是以系统默认编码读入源文件，然后按UNICODE进行编码的。在JAVA运行的时候，JAVA也是采用UNICODE编码的，并且默认输入和输出的都是操作系统的默认编码，也就是说在new String(bytes[,encode])中，系统认为输入的是编码为encode的字节流，换句话说，如果按encode来翻译bytes才能得到正确的结果，这个结果最后要在JAVA中保存，它还是要从这个encode转换成Unicode，也就是说有bytes-->encode字符-->Unicode字符的转换；而在String.getBytes([encode])中，系统要做一个Unicode字符-->encode字符-->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开发中的中文处理问题

相关文章:

相关软件:

字母检索 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 回到顶部