作者：sonymusic
email: sonymusic@china.com
日期：2000-12-18 1:13:46
[h1]Java 編程技術中漢字問題的分析及解決[/h1]

段明輝
自由撰稿人
2000 年 11月 8日
[hr]在基于 Java 語言的編程中，我們經常碰到漢字的處理及顯示的問題。一大堆看不懂的亂碼肯定不是我們愿意看到的顯示效果，怎樣才能夠讓那些漢字正確顯示呢？Java 語言默認的編碼方式是UNICODE ，而我們中國人通常使用的文件和數據庫都是基于 GB2312 或者 BIG5 等方式編碼的，怎樣才能夠恰當地選擇漢字編碼方式并正確地處理漢字的編碼呢？本文將從漢字編碼的常識入手，結合 Java 編程實例，分析以上兩個問題并提出解決它們的方案。[hr]


現在 Java 編程語言已經廣泛應用于互聯(lián)網世界，早在 Sun 公司開發(fā) Java 語言的時候，就已經考慮到對非英文字符的支持了。Sun 公司公布的 Java 運行環(huán)境（JRE）本身就分英文版和國際版，但只有國際版才支持非英文字符。不過在 Java 編程語言的應用中，對中文字符的支持并非如同 Java Soft 的標準規(guī)范中所宣稱的那樣完美，因為中文字符集不只一個，而且不同的操作系統(tǒng)對中文字符的支持也不盡相同，所以會有許多和漢字編碼處理有關的問題在我們進行應用開發(fā)中困擾著我們。有很多關于這些問題的解答，但都比較瑣碎，并不能夠滿足大家迫切解決問題的愿望，關于 Java 中文問題的系統(tǒng)研究并不多，本文從漢字編碼常識出發(fā)，分析 Java 中文問題，希望對大家解決這個問題有所幫助。

[b]漢字編碼的常識[/b]

我們知道，英文字符一般是以一個字節(jié)來表示的，最常用的編碼方法是 ASCII 。但一個字節(jié)最多只能區(qū)分256個字符，而漢字成千上萬，所以現在都以雙字節(jié)來表示漢字，為了能夠與英文字符分開，每個字節(jié)的最高位一定為1，這樣雙字節(jié)最多可以表示64K格字符。我們經常碰到的編碼方式有 GB2312、BIG5、UNICODE 等。關于具體編碼方式的詳細資料，有興趣的讀者可以查閱相關資料。我膚淺談一下和我們關系密切的 GB2312 和 UNICODE。GB2312 碼，中華人民共和國國家標準漢字信息交換用編碼，是一個由中華人民共和國國家標準總局發(fā)布的關于簡化漢字的編碼，通行于中國大陸地區(qū)及新加坡，簡稱國標碼。兩個字節(jié)中，第一個字節(jié)（高字節(jié)）的值為區(qū)號值加32（20H），第二個字節(jié)（低字節(jié)）的值為位號值加32（20H），用這兩個值來表示一個漢字的編碼。UNICODE 碼是微軟提出的解決多國字符問題的多字節(jié)等長編碼，它對英文字符采取前面加“0”字節(jié)的策略實現等長兼容。如 “A” 的 ASCII 碼為0x41，UNICODE 就為0x00，0x41。利用特殊的工具各種編碼之間可以互相轉換。

[b]Java 中文問題的初步認識[/b]

我們基于 Java 編程語言進行應用開發(fā)時，不可避免地要處理中文。Java 編程語言默認的編碼方式是 UNICODE，而我們通常使用的數據庫及文件都是基于 GB2312 編碼的，我們經常碰到這樣的情況：瀏覽基于 JSP 技術的網站看到的是亂碼，文件打開后看到的也是亂碼，被 Java 修改過的數據庫的內容在別的場合應用時無法繼續(xù)正確地提供信息。 

String sEnglish = “apple”; 

String sChinese = “蘋果”; 

String s = “蘋果 apple ”; 

sEnglish 的長度是5，sChinese的長度是4，而 s 默認的長度是14。對于 sEnglish來說， Java 中的各個類都支持得非常好，肯定能夠正確顯示。但對于 sChinese 和 s 來說，雖然 Java Soft 聲明 Java 的基本類已經考慮到對多國字符的支持（默認 UNICODE 編碼），但是如果操作系統(tǒng)的默認編碼不是 UNICODE ，而是國標碼等。從 Java 源代碼到得到正確的結果，要經過 “Java 源代碼-> Java 字節(jié)碼-> ;虛擬機->操作系統(tǒng)->顯示設備”的過程。在上述過程中的每一步驟，我們都必須正確地處理漢字的編碼，才能夠使最終的顯示結果正確。 

“ Java 源代碼-> Java 字節(jié)碼”，標準的 Java 編譯器 javac 使用的字符集是系統(tǒng)默認的字符集，比如在中文 Windows 操作系統(tǒng)上就是 GBK ,而在 Linux 操作系統(tǒng)上就是ISO-8859-1，所以大家會發(fā)現在 Linux 操作系統(tǒng)上編譯的類中源文件中的中文字符都出了問題，解決的辦法就是在編譯的時候添加 encoding 參數，這樣才能夠與平臺無關。用法是 

javac –encoding GBK。 

“ Java 字節(jié)碼->虛擬機->操作系統(tǒng)”， Java 運行環(huán)境 （JRE） 分英文版和國際版，但只有國際版才支持非英文字符。 Java 開發(fā)工具包 （JDK） 肯定支持多國字符，但并非所有的計算機用戶都安裝了 JDK 。很多操作系統(tǒng)及應用軟件為了能夠更好的支持 Java ，都內嵌了 JRE 的國際版本，為自己支持多國字符提供了方便。 

“操作系統(tǒng)->顯示設備”，對于漢字來說，操作系統(tǒng)必須支持并能夠顯示它。英文操作系統(tǒng)如果不搭配特殊的應用軟件的話，是肯定不能夠顯示中文的。 

還有一個問題，就是在 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”編碼方式轉化成字節(jié)數組，而“GBK” 是目標編碼方式。我們從以ISO-8859-1方式編碼的數據庫中讀出中文字符串 s1 ，經過上述轉換過程，在支持 GBK 字符集的操作系統(tǒng)和應用軟件中就能夠正確顯示中文字符串 s2 。 

[b]Java 中文問題的表層分析及處理[/b]

背景 
 
開發(fā)環(huán)境 
 JDK1.15 
 Vcafe2.0 
 JPadPro 
 
服務器端 
 NT IIS 
 Sybase System 
 Jconnect（JDBC） 
 
客戶端 
 IE5.0 
 Pwin98 
   
 

.CLASS 文件存放在服務器端，由客戶端的瀏覽器運行 APPLET ， APPLET 只起調入 FRAME 類等主程序的作用。界面包括 Textfield ，TextArea，List，Choice 等。 

I.       取中文 

用 JDBC 執(zhí)行 SELECT 語句從服務器端讀取數據（中文）后，將數據用 APPEND 方法加到 TextArea（TA） ，不能正確顯示。但加到 List 中時，大部分漢字卻可正確顯示。 

將數據按“ISO-8859-1” 編碼方式轉化為字節(jié)數組，再按系統(tǒng)缺省編碼方式 （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); 

在轉換字符串時不采用系統(tǒng)默認編碼方式，而直接采用“ GBK” 或者 “GB2312” ,在 A 和 B 兩種情況下，從數據庫取數據都沒有問題。 

II.    寫中文到數據庫 

處理方式與“取中文”相逆，先將 SQL 語句按系統(tǒng)缺省編碼方式轉化為字節(jié)數組，再按“ISO-8859-1”編碼方式轉化為 STRING ，最后送去執(zhí)行，則中文信息可正確寫入數據庫。 

程序段如下： 

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 情況），上述程序代碼可正確執(zhí)行。但是如果客戶機只有瀏覽器，而沒有 JDK 和 CLASSPATH 時（稱為 B 情況），則漢字無法正確轉換。 

我們的分析： 

1.經過測試，在 A 情況下，程序運行時系統(tǒng)的缺省編碼方式為 GBK 或者 GB2312 。在 B 情況下，程序啟動時瀏覽器的 JAVA 控制臺中出現如下錯誤信息： 

Can't find resource for sun.awt.windows.awtLocalization_zh_CN 

然后系統(tǒng)的缺省編碼方式為“8859-1”。 

2.如果在轉換字符串時不采用系統(tǒng)缺省編碼方式，而是直接采用 “GBK” 或“GB2312”，則在 A 情況下程序仍然可正常運行，在 B 情況下，系統(tǒng)出現錯誤： 

UnsupportedEncodingException。 

3.在客戶機上，把 JDK 的 CLASSES.ZIP 解壓后，放在另一個目錄中， CLASSPATH 只包含該目錄。然后一邊逐步刪除該目錄中的 .CLASS 文件，另一邊運行測試程序，最后發(fā)現在一千多個 CLASS 文件中，只有一個是必不可少的，該文件是： 

sun.io.CharToByteDoubleByte.class。 

將該文件拷到服務器端和其它的類放在一起，并在程序的開頭 IMPORT 它，在 B 情況下程序仍然無法正常運行。 

4.在 A 情況下，如果在 CLASSPTH 中去掉 sun.io.CharToByteDoubleByte.class ，則程序運行時測得默認編碼方式為“8859-1”，否則為 “GBK” 或 “GB2312” 。 

如果 JDK 的版本為1.2以上的話，在 B 情況下遇到的問題得到了很好的解決，測試的步驟同上，有興趣的讀者可以嘗試一下。 

[/b]Java 中文問題的根源分析及解決[/b]

在簡體中文 MS Windows 98 + JDK 1.3 下，可以用 System.getProperties() 得到 Java 運行環(huán)境的一些基本屬性，類 PoorChinese 可以幫助我們得到這些屬性。 

類 PoorChinese 的源代碼： 

public class PoorChinese { 

   public static void main(String[] args) { 

       System.getProperties().list(System.out); 

   } 

} 

執(zhí)行 java PoorChinese 后，我們會得到: 

系統(tǒng)變量 file.encoding 的值為 GBK ，user.language 的值為 zh ， user.region 的值為 CN ，這些系統(tǒng)變量的值決定了系統(tǒng)默認的編碼方式是 GBK 。 

在上述系統(tǒng)中，下面的代碼將 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.");