1回顶部 1.引言
可以看到明显“Excetion”拼写错误。而这段代码是WORKSHOP自动生成。但是,在某些机器上,同样的工程文件,编译就能通过。联系BEA工程师,也不能解决此问题。 笔者查阅大量资料,很难找到相关问题的介绍。一次在偶尔查阅SUN的缺陷库[i]时,发现是由于GB18030中文编码问题所致。 2. 问题分析 操作系统默认内部编码一般并不是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程序:
在用WORKSHOP开发CMP EJB出现问题的操作系统默认编码即为GB18030。 由于遇到此问题的人比较少。而真正遇到时,很多人通过重新安装操作系统可以解决问题,因而这方面的资料很难找到。
2回顶部 3. 解决办法 替代的解决方案主要思路是避开GB18030编码,主要有两种方法 改变操作系统默认编码方案 对于unix/linux平台,修改操作系统编码方案很简单。如在solaris平台下,运行如下命令即可改变系统编码: LANG=zh.GBK;export LANG 对于windows平台,修改操作系统中文默认编码比较复杂。尝试把操作系统的“区域和语言选项”更改为其它地区,选用其它语言,都没有效果。与微软客户服务联系,也不能提供相应解决方案。 运行java应用时指定默认编码 在运行基于JAVA的应用时,加上参数: java –Dfile.encoding=GB2312 把java应用的默认编码方案与GB2312硬绑定,即在未指明编码方案时,采用GB2312编码。 如果针对每个应用,进行上述修改,工作量很大。有些应用里面又隐式调用外部JAVA应用,更增加修正的难度。比较可行的办法是对java的运行文件进行修正,令其在运行时自动加上“-Dfile.encoding=GB2312”参数。 建议windows平台采用本方法进行修正。方案如下: 1、改名原java.exe,javaw.exe,如改为javabak.exe,javawbak.exe 2、重写java.exe和javaw.exe,令其运行时调用javabak.exe,javawbak.exe,并在运行时加上“-Dfile.encoding”参数。 如下c代码即可完成上述功能:
3回顶部
编译后(注意修改arg值),生成的文件命名为java.exe和javaw.exe,放置在<JAVA_HOME>/bin和<JAVA_HOME>/jre/bin目录下,即可。 经实践,此办法可以解决GB18030问题,并且不会带来其它隐患。唯一的缺点是在运行JAVA应用时,会有一个额外的DOS窗口打开,此窗口可以关闭,不会对应用运行带来影响。 4.总结 本文给出的解决方案,不仅适用于解决JAVA平台对GB18030支持问题,而且,也为指定通用JAVA运行默认参数,提供了另一种思路。
|
正在阅读:开动脑筋:Java字符丢失的解决办法开动脑筋:Java字符丢失的解决办法
2004-12-31 15:04
出处:
责任编辑:linjixiong