则程序运行时测得默认编码方式为“8859-1”,否则为 “GBK” 或 “GB2312” 。
如果 JDK 的版本为1.2以上的话,在 B 情况下遇到的问题得到了很好的解决,测试的步骤
同上,有兴趣的读者可以尝试一下。
Java 中文问题的根源分析及解决
在简体中文 MS Windows 98 + JDK 1.3 下,可以用 System.getProperties() 得到 Java 运行环境的一些基本属性,类 PoorChinese 可以帮助我们得到这些属性。
类 PoorChinese 的
源代码:
执行 java PoorChinese 后,我们会得到: 系统变量 file.encoding 的值为 GBK ,user.language 的值为 zh , user.region 的值 为 CN ,这些系统变量的值决定了系统默认的编码方式是 GBK 。 在上述系统中, 下面的代码将 GB2312 文件转换成 Big5 文件, 它们能够帮助我们理解 Java
编码转化的过程如下:
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 能够严格地测试它的产品,为用户带来更多的方便。
附一个用于从数据库和网络中取出 中文乱码的处理函数,入参是有问题的字符串,出参是问题已经解决了的字符串。