Java字符丟失與中文編碼

2019-11-18 13:57:49

字體：大中小

來源：轉載

供稿：網友

　　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。

由于碰到此問題的人比較少。而真正碰到時，很多人通過重新安裝操作系統可以解決問題，因而這方面的資料很難找到。

3. 解決辦法
最理想的解決辦法就是由SUN修正此BUG。此問題早在2003年11月即提出，但是直到目前（2004/12/30），問題狀態仍為“In process, bug”。

替代的解決方案主要思路是避開GB18030編碼，主要有兩種方法

改變操作系統默認編碼方案

對于unix/linux平臺，修改操作系統編碼方案很簡單。如在solaris平臺下，運行如下命令即可改變系統編碼：

LANG=zh.GBK;export LANG

對于windows平臺，修改操作系統中文默認編碼比較復雜。嘗試把操作系統的“區域和語言選項”更改為其它地區，選用其它語言，都沒有效果。與微軟客戶服務聯系，也不能提供相應解決方案。

運行java應用時指定默認編碼

在運行基于JAVA的應用時，加上參數：

java ?CDfile.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代碼即可完成上述功能：

#include "string.h"

#include "stdlib.h"

int main(int argc, char* argv[])

{

char arg[100000] = "javabak.exe -Dfile.encoding=GB2312 ";

for(int i=1; i<argc; i++){

strcat(arg,argv[i]);

strcat(arg, " ");

}

system(arg);

return 0;

}

編譯后（注重修改arg值），生成的文件命名為java.exe和javaw.exe，放置在<JAVA_HOME>/bin和<JAVA_HOME>/jre/bin目錄下，即可。

經實踐，此辦法可以解決GB18030問題，并且不會帶來其它隱患。唯一的缺點是在運行JAVA應用時，會有一個額外的DOS窗口打開，此窗口可以關閉，不會對應用運行帶來影響。

4. 總結
在應用開發中，中文編碼一直是一個比較麻煩的問題。盡管目前GB18030是國家強制性標準，有著各種各樣的優點，但由于其推出時間尚短，在應用方面對其支持還不夠完善，還是應盡可能采用GB2312等兼容性比較強的中文編碼方案。

本文給出的解決方案，不僅適用于解決JAVA平臺對GB18030支持問題，而且，也為指定通用JAVA運行默認參數，提供了另一種思路。

--------------------------------------------------------------------------------

參考文獻

[i] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4954023

上一篇：JAVA專業術語集

下一篇：Java縱橫談