java字符丟失與中文編碼 警告：編碼 utf8 的不可映射字符 獲得ConnectionManager，設置相關參數(shù) 警告：編碼 utf8 的不可映射字符 標志初始化是否完成的flag
關鍵字: java字符丟失與中文編碼
1. 引言
在用JAVA進行開發(fā)時，偶爾在IO操作中會產(chǎn)生字符丟失現(xiàn)象。如在用BEA的WORKSHOP開發(fā)CMP EJB過程中，總是編譯不通過，報錯：
cannot resolve symbol
symbol : class Excetion
location: class eaitest.vip.firmorder.FirmOrderBean_g8ghds__WebLogic_CMP_RDBMS
} catch (Excetion ex) {
可以看到明顯“Excetion”拼寫錯誤。而這段代碼是WORKSHOP自動生成。但是，在某些機器上，同樣的工程文件，編譯就能通過。聯(lián)系BEA工程師，也不能解決此問題。
筆者查閱大量資料，很難找到相關問題的介紹。一次在偶爾查閱SUN的缺陷庫[i]時，發(fā)現(xiàn)是由于GB18030中文編碼問題所致。
2. 問題分析
國家標準GB18030-2000《信息交換用漢字編碼字符集基本集的擴充》是我國繼GB2312-1980和GB13000-1993之后最重
要的漢字編碼標準，是我國計算機系統(tǒng)必須遵循的基礎性標準之一。國家質(zhì)監(jiān)總局規(guī)定GB
18030過渡期(即2001年8月31日)后正式發(fā)布或出廠的產(chǎn)品，必須符合GB-18030相關要求。
操作系統(tǒng)默認內(nèi)部編碼一般并不是GB18030，目前已知在WINDOWS XP操作系統(tǒng)中，進行某些組件的升級后，會把操作系統(tǒng)的默認編碼由GB2312變更為GB18030。
但是即便在最新發(fā)布的JDK1.4.2_06版本中，對其支持仍存在一定問題。GB18030問題主要表現(xiàn)是，基于java的應用，涉及GB18030編碼與其它編碼方案轉(zhuǎn)換時，存在字符丟失現(xiàn)象。
問題的原因是java在處理由sun.nio.cs.ext.ExtendedCharsets提供的擴展字符集時，會進行字符緩沖。但是對于緩
沖字符沒有采用新的sun.nio.cs.ext包處理，而是延用原有處理方式，這種方式在多線程操作下對GB18030編碼方案處理存在問題，這樣導致
部分字符丟失。
此問題只影響GB18030編碼方案，對GB2312等中文編碼方案并沒有影響。
當操作系統(tǒng)默認編碼方案為GB18030時，如果進行文件寫操作，未指定編碼方案情況下，java采用操作系統(tǒng)默認編碼方案操作，這時最容易出現(xiàn)GB18030問題。
查看操作系統(tǒng)默認編碼，可以運行如下java程序：
public class EchoDefaultSystemEncoding{
public static void main(String[] args){
String encoding=System.getProperty(“file.encoding”);
System.out.println(“Default System Encoding: ” + encoding);
}
}
在用WORKSHOP開發(fā)CMP EJB出現(xiàn)問題的操作系統(tǒng)默認編碼即為GB18030。
由于遇到此問題的人比較少。而真正遇到時，很多人通過重新安裝操作系統(tǒng)可以解決問題，因而這方面的資料很難找到。
3. 解決辦法
最理想的解決辦法就是由SUN修正此BUG。此問題早在2003年11月即提出，但是直到目前（2004/12/30），問題狀態(tài)仍為“In process, bug”。
替代的解決方案主要思路是避開GB18030編碼，主要有兩種方法
改變操作系統(tǒng)默認編碼方案
對于unix/linux平臺，修改操作系統(tǒng)編碼方案很簡單。如在solaris平臺下，運行如下命令即可改變系統(tǒng)編碼：
LANG=zh.GBK;export LANG
對于windows平臺，修改操作系統(tǒng)中文默認編碼比較復雜。嘗試把操作系統(tǒng)的“區(qū)域和語言選項”更改為其它地區(qū)，選用其它語言，都沒有效果。與微軟客戶服務聯(lián)系，也不能提供相應解決方案。
運行java應用時指定默認編碼
在運行基于JAVA的應用時，加上參數(shù)：
java –Dfile.encoding=GB2312
把java應用的默認編碼方案與GB2312硬綁定，即在未指明編碼方案時，采用GB2312編碼。
如果針對每個應用，進行上述修改，工作量很大。有些應用里面又隱式調(diào)用外部JAVA應用，更增加修正的難度。比較可行的辦法是對java的運行文件進行修正，令其在運行時自動加上“-Dfile.encoding=GB2312”參數(shù)。
建議windows平臺采用本方法進行修正。方案如下：
1、改名原java.exe，javaw.exe，如改為javabak.exe，javawbak.exe
2、重寫java.exe和javaw.exe，令其運行時調(diào)用javabak.exe，javawbak.exe，并在運行時加上“-Dfile.encoding”參數(shù)。
如下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目錄下，即可。
經(jīng)實踐，此辦法可以解決GB18030問題，并且不會帶來其它隱患。唯一的缺點是在運行JAVA應用時，會有一個額外的DOS窗口打開，此窗口可以關閉，不會對應用運行帶來影響。
4. 總結
在應用開發(fā)中，中文編碼一直是一個比較麻煩的問題。盡管目前GB18030是國家強制性標準，有著各種各樣的優(yōu)點，但由于其推出時間尚短，在應用方面對其支持還不夠完善，還是應盡可能采用GB2312等兼容性比較強的中文編碼方案。
本文給出的解決方案，不僅適用于解決JAVA平臺對GB18030支持問題，而且，也為指定通用JAVA運行默認參數(shù)，提供了另一種思路。
--------------------------------------------------------------------------------
參考文獻
[i] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4954023