編程|漢字|解決|問題
Java 編程技術中漢字問題的分析及解決
段明輝
自由撰稿人
2000 年 11月 8日
內容: 漢字編碼的常識 Java 中文問題的初步認識 Java 中文問題的表層分析及處理 Java 中文問題的根源分析及解決 Java Servlet 中文問題的根源 修改 Servlet.jar 中文亂碼的處理函數 參考資料 作者簡介
在基於 Java 語言的編程中，我們經常碰到漢字的處理及顯示的問題。一大堆看不懂的亂碼肯定不是我們願意看到的顯示效果，怎樣才能夠讓那些漢字正確顯示呢？Java 語言預設的編碼方式是UNICODE ，而我們中國人通常使用的檔案和資料庫都是基於 GB2312 或者 BIG5 等方式編碼的，怎樣才能夠恰當地選擇漢字編碼方式並正確地處理漢字的編碼呢？本文將從漢字編碼的常識入手，結合 Java 編程執行個體，分析以上兩個問題並提出解決它們的方案。
現在 Java 程式設計語言已經廣泛應用於互連網世界，早在 Sun 公司開發 Java 語言的時候，就已經考慮到對非英文字元的支援了。Sun 公司公布的 Java 運行環境（JRE）本身就分英文版和國際版，但只有國際版才支援非英文字元。不過在 Java 程式設計語言的應用中，對中文字元的支援並非如同 Java Soft 的標準規範中所宣稱的那樣完美，因為中文字元集不只一個，而且不同的作業系統對中文字元的支援也不盡相同，所以會有許多和漢字編碼處理有關的問題在我們進行應用開發中困擾著我們。有很多關於這些問題的解答，但都比較瑣碎，並不能夠滿足大家迫切解決問題的願望，關於 Java 中文問題的系統研究並不多，本文從漢字編碼常識出發，分析 Java 中文問題，希望對大家解決這個問題有所協助。
漢字編碼的常識
我們知道，英文字元一般是以一個位元組來表示的，最常用的編碼方法是 ASCII 。但一個位元組最多隻能區分256個字元，而漢字成千上萬，所以現在都以雙位元組來表示漢字，為了能夠與英文字元分開，每個位元組的最高位一定為1，這樣雙位元組最多可以表示64K格字元。我們經常碰到的編碼方式有 GB2312、BIG5、UNICODE 等。關於具體編碼方式的詳細資料，有興趣的讀者可以查閱相關資料。我膚淺談一下和我們關係密切的 GB2312 和 UNICODE。GB2312 碼，中華人民共和國國家標準漢字資訊交換用編碼，是一個由中華人民共和國國家標準總局發布的關於簡化漢字的編碼，通行於中國大陸地區及新加坡，簡稱國標碼。兩個位元組中，第一個位元組（高位元組）的值為區號值加32（20H），第二個位元組（低位元組）的值為位號值加32（20H），用這兩個值來表示一個漢字的編碼。UNICODE 碼是微軟提出的解決多國字元問題的多位元組等長編碼，它對英文字元採取前面加“0”位元組的策略實現等長相容。如 “A” 的 ASCII 碼為0x41，UNICODE 就為0x00，0x41。利用特殊的工具各種編碼之間可以互相轉換。
Java 中文問題的初步認識
我們基於 Java 程式設計語言進行應用開發時，不可避免地要處理中文。Java 程式設計語言預設的編碼方式是 UNICODE，而我們通常使用的資料庫及檔案都是基於 GB2312 編碼的，我們經常碰到這樣的情況：瀏覽基於 JSP 技術的網站看到的是亂碼，檔案開啟後看到的也是亂碼，被 Java 修改過的資料庫的內容在別的場合應用時無法繼續正確地提供資訊。
String sEnglish = “apple”;
String sChinese = “蘋果”;
String s = “蘋果 apple ”;
sEnglish 的長度是5，sChinese的長度是4，而 s 預設的長度是14。對於 sEnglish來說， Java 中的各個類都支援得非常好，肯定能夠正確顯示。但對於 sChinese 和 s 來說，雖然 Java Soft 聲明 Java 的基本類已經考慮到對多國字元的支援（預設 UNICODE 編碼），但是如果作業系統的預設編碼不是 UNICODE ，而是國標碼等。從 Java 原始碼到得到正確的結果，要經過 “Java 原始碼-> Java 位元組碼-> ;虛擬機器->作業系統->顯示裝置”的過程。在上述過程中的每一步驟，我們都必須正確地處理漢字的編碼，才能夠使最終的顯示結果正確。
“ Java 原始碼-> Java 位元組碼”，標準的 Java 編譯器 javac 使用的字元集是系統預設的字元集，比如在中文 Windows 作業系統上就是 GBK ,而在 Linux 作業系統上就是ISO-8859-1，所以大家會發現在 Linux 作業系統上編譯的類中源檔案中的中文字元都出了問題，解決的辦法就是在編譯的時候添加 encoding 參數，這樣才能夠與平台無關。用法是
javac –encoding GBK。
“ Java 位元組碼->虛擬機器->作業系統”， Java 運行環境 （JRE） 分英文版和國際版，但只有國際版才支援非英文字元。 Java 開發套件 （JDK） 肯定支援多國字元，但並非所有的電腦使用者都安裝了 JDK 。很多作業系統及應用軟體為了能夠更好的支援 Java ，都內嵌了 JRE 的國際版本，為自己支援多國字元提供了方便。
“作業系統->顯示裝置”，對於漢字來說，作業系統必須支援並能夠顯示它。英文作業系統如果不搭配特殊的應用軟體的話，是肯定不能夠顯示中文的。
還有一個問題，就是在 Java 編程過程中，對中文字元進行正確的編碼轉換。例如，向網頁輸出中文字串的時候，不論你是用
out.println(string); // string 是含中文的字串
還是用
<%=string%>，都必須作 UNICODE 到 GBK 的轉換，或者手動，或者自動。在 JSP 1.0中，可以定義輸出字元集，從而實現內碼的自動轉換。用法是
<%@page ContentType=”text/html;charset=gb2312” %>
但是在一些 JSP 版本中並沒有提供對輸出字元集的支援，（例如 JSP 0.92），這就需要手動編碼輸出了，方法非常多。最常用的方法是
String s1 = request.getParameter(“keyword”);
String s2 = new String(s1.getBytes(“ISO-8859-1”),”GBK”);
getBytes 方法用於將中文字元以“ISO-8859-1”編碼方式轉化成位元組數組，而“GBK” 是目標編碼方式。我們從以ISO-8859-1方式編碼的資料庫中讀出中文字串 s1 ，經過上述轉換過程，在支援 GBK 字元集的作業系統和應用軟體中就能夠正確顯示中文字串 s2 。
Java 中文問題的表層分析及處理
背景
開發環境
JDK1.15
Vcafe2.0
JPadPro
伺服器端
NT IIS
Sybase System
Jconnect（JDBC）
用戶端
IE5.0
Pwin98
.CLASS 檔案存放在伺服器端，由用戶端的瀏覽器運行 APPLET ， APPLET 只起調入 FRAME 類等主程式的作用。介面包括 Textfield ，TextArea，List，Choice 等。
I. 取中文
用 JDBC 執行 SELECT 語句從伺服器端讀取資料（中文）後，將資料用 APPEND 方法加到 TextArea（TA） ，不能正確顯示。但加到 List 中時，大部分漢字卻可正確顯示。
將資料按“ISO-8859-1” 編碼方式轉化為位元組數組，再按系統預設編碼方式 （Default Character Encoding） 轉化為 STRING ，即可在 TA 和 List 中正確顯示。
程式段如下：
dbstr2 = results.getString(1);
//After reading the result from DB server，converting it to string.
dbbyte1 = dbstr2.getBytes(“iso-8859-1”);
dbstr1 = new String(dbbyte1);
在轉換字串時不採用系統預設編碼方式，而直接採用“ GBK” 或者 “GB2312” ,在 A 和 B 兩種情況下，從資料庫取資料都沒有問題。
II. 寫中文到資料庫
處理方式與“取中文”相逆，先將 SQL 陳述式按系統預設編碼方式轉化為位元組數組，再按“ISO-8859-1”編碼方式轉化為 STRING ，最後送去執行，則中文資訊可正確寫入資料庫。
程式段如下：
sqlstmt = tf_input.getText();
//Before sending statement to DB server，converting it to sql statement.
dbbyte1 = sqlstmt.getBytes();
sqlstmt = newString(dbbyte1,”iso-8859-1”);
_stmt = _con.createStatement();
_stmt.executeUpdate(sqlstmt);
……
問題：如果客戶機上存在 CLASSPATH 指向 JDK 的 CLASSES.ZIP 時（稱為 A 情況），上述程式碼可正確執行。但是如果客戶機只有瀏覽器，而沒有 JDK 和 CLASSPATH 時（稱為 B 情況），則漢字無法正確轉換。
我們的分析：
1.經過測試，在 A 情況下，程式運行時系統的預設編碼方式為 GBK 或者 GB2312 。在 B 情況下，程式啟動時瀏覽器的 JAVA 控制台中出現如下錯誤資訊：
Can't find resource for sun.awt.windows.awtLocalization_zh_CN
然後系統的預設編碼方式為“8859-1”。
2.如果在轉換字串時不採用系統預設編碼方式，而是直接採用 “GBK” 或“GB2312”，則在 A 情況下程式仍然可正常運行，在 B 情況下，系統出現錯誤：
UnsupportedEncodingException。
3.在客戶機上，把 JDK 的 CLASSES.ZIP 解壓後，放在另一個目錄中， CLASSPATH 只包含該目錄。然後一邊逐步刪除該目錄中的 .CLASS 檔案，另一邊運行測試程式，最後發現在一千多個 CLASS 檔案中，只有一個是必不可少的，該檔案是：
sun.io.CharToByteDoubleByte.class。
將該檔案拷到伺服器端和其它的類放在一起，並在程式的開頭 IMPORT 它，在 B 情況下程式仍然無法正常運行。
4.在 A 情況下，如果在 CLASSPTH 中去掉 sun.io.CharToByteDoubleByte.class ，則程式運行時測得預設編碼方式為“8859-1”，否則為 “GBK” 或 “GB2312” 。
如果 JDK 的版本為1.2以上的話，在 B 情況下遇到的問題得到了很好的解決，測試的步驟同上，有興趣的讀者可以嘗試一下。
Java 中文問題的根源分析及解決
在簡體中文 MS Windows 98 + JDK 1.3 下，可以用 System.getProperties() 得到 Java 運行環境的一些基本屬性，類 PoorChinese 可以協助我們得到這些屬性。
類 PoorChinese 的原始碼：
public class PoorChinese {
public static void main(String[] args) {
System.getProperties().list(System.out);
}
}
執行 java PoorChinese 後，我們會得到:
系統變數 file.encoding 的值為 GBK ，user.language 的值為 zh ， user.region 的值為 CN ，這些系統變數的值決定了系統預設的編碼方式是 GBK 。
在上述系統中，下面的代碼將 GB2312 檔案轉換成 Big5 檔案，它們能夠協助我們理解 Java 中漢字編碼的轉化:
import java.io.*;
import java.util.*;
public class gb2big5 {
static int iCharNum=0;
public static void main(String[] args) {
System.out.println("Input GB2312 file, output Big5 file.");
if (args.length!=2) {
System.err.println("Usage: jview gb2big5 gbfile big5file");
System.exit(1);
}
String inputString = readInput(args[0]);
writeOutput(inputString,args[1]);
System.out.println("Number of Characters in file: "+iCharNum+".");
}
static void writeOutput(String str, String strOutFile) {
try {
FileOutputStream fos = new FileOutputStream(strOutFile);
Writer out = new OutputStreamWriter(fos, "Big5");
out.write(str);
out.close();
}
catch (IOException e) {
e.printStackTrace();
e.printStackTrace();
}
}
static String readInput(String strInFile) {
StringBuffer buffer = new StringBuffer();
try {
FileInputStream fis = new FileInputStream(strInFile);
InputStreamReader isr = new InputStreamReader(fis, "GB2312");
Reader in = new BufferedReader(isr);
int ch;
while ((ch = in.read()) > -1) {
iCharNum += 1;
buffer.append((char)ch);
}
in.close();
return buffer.toString();
}
catch (IOException e) {
e.printStackTrace();
return null;
}
}
}
編碼轉化的過程如下：
ByteToCharGB2312 CharToByteBig5
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 能夠嚴格地測試它的產品，為使用者帶來更多的方便。
附一個用於從資料庫和網路中取出
中文亂碼的處理函數，入參是有問題的字串，出參是問題已經解決了的字串。
String parseChinese(String in)
{
String s = null;
byte temp [];
if (in == null)
{
System.out.println("Warn:Chinese null founded!");
return new String("");
}
try
{
temp=in.getBytes("iso-8859-1");
temp=in.getBytes("iso-8859-1");
s = new String(temp);
}
{
System.out.println("Warn:Chinese null founded!");
return new String("");
}
try
{
temp=in.getBytes("iso-8859-1");
s = new String(temp);
}
catch(UnsupportedEncodingException e)
{
System.out.println (e.toString());
}
return s;
}
參考資料
- BBS 水木清華站的 Java 討論區
- 中國最大的電子公告板的 Java 討論區，有眾多高校的 Java 愛好者在此進行關於 Java 技術的討論
作者簡介
- 段明輝(duanmh@dns.ime.tsinghua.edu.cn)，清華大學電子工程系學生
- 現在正在清華大學微電子學研究所從事 Java 智慧卡微處理器的研究和開發
- 領導 BBS 水木清華站的 Java 討論群組，為眾多 Java 技術應用者提供解決方案
