1.引言 在用JAVA进行开发时,偶尔在IO操作中会产生字符丢失现象。如在用BEA的WORKSHOP开发CMP EJB过程中,总是编译不通过,报错:
cannot resolve symbol
symbol : class Excetion
location: class eaitest.vip.firmorder.FirmOrderBean_g8ghds__WebLogic_CMP_RDBMS
} catch (Excetion ex) {
可以看到明显“Excetion”拼写错误。而这段代码是WORKSHOP自动生成。但是,在某些机器上,同样的工程文件,编译就能通过。联系BEA工程师,也不能解决此问题。
笔者查阅大量资料,很难找到相关问题的介绍。一次在偶尔查阅SUN的缺陷库[i]时,发现是由于GB18030中文编码问题所致。
2.问题分析 国家标准GB18030-2000《信息交换用汉字编码字符集基本集的扩充》是我国继GB2312-1980和GB13000-1993之后最重要的汉字编码标准,是我国计算机系统必须遵循的基础性标准之一。国家质监总局规定GB 18030过渡期(即2001年8月31日)后正式发布或出厂的产品,必须符合GB-18030相关要求。
操作系统默认内部编码一般并不是GB18030,目前已知在WINDOWS XP操作系统中,进行某些组件的升级后,会把操作系统的默认编码由GB2312变更为GB18030。
但是即便在最新发布的JDK1.4.2_06版本中,对其支持仍存在一定问题。GB18030问题主要表现是,基于java的应用,涉及GB18030编码与其它编码方案转换时,存在字符丢失现象。
问题的原因是java在处理由sun.nio.cs.ext.ExtendedCharsets提供的扩展字符集时,会进行字符缓冲。但是对于缓冲字符没有采用新的sun.nio.cs.ext包处理,而是延用原有处理方式,这种方式在多线程操作下对GB18030编码方案处理存在问题,这样导致部分字符丢失。
此问题只影响GB18030编码方案,对GB2312等中文编码方案并没有影响。
当操作系统默认编码方案为GB18030时,如果进行文件写操作,未指定编码方案情况下,java采用操作系统默认编码方案操作,这时最容易出现GB18030问题。
查看操作系统默认编码,可以运行如下java程序:
public class EchoDefaultSystemEncoding{
public static void main(String[] args){
String encoding=System.getProperty(“file.encoding”);
System.out.println(“Default System Encoding: ” + encoding);
}
}
在用WORKSHOP开发CMP EJB出现问题的操作系统默认编码即为GB18030。
由于遇到此问题的人比较少。而真正遇到时,很多人通过重新安装操作系统可以解决问题,因而这方面的资料很难找到。