關於Java中文問題的幾條分析原則 – JAVA編程語言程序開發技術文章

盡管對於Java中文處理問題的討論已不乏其數，但由於Java技術涉及內容廣（J2EE包含瞭十幾種相關技術），技術供應商繁多，面向Java的Web服務器、應用服務器以及JDBC數據庫驅動等都沒有官方的標準，所以Java應用在處理中文過程中出瞭存在固有的問題外也存在隨著選用的服務器，驅動程序的不同而帶來的Java中文問題的多變性，增加瞭問題的復雜度。那麼，我們如何在這麼紛繁的現象中找到問題的癥結呢？

Java中文問題的一般解決辦法

事實上，Java的中文問題都是由於Java應用所采用的缺省編碼格式與目標或者應用所要讀入字符的編碼格式不同而造成的（具體參見文獻1）。對於如何解決Java的中文問題，通常有四種方法：

1）選擇JDK的中文本地化版本。盡管Java2 JDK的中文本地化版本（http://java.sun.com/products/jdk/1.2/chinesejdk.html）並不是一個官方的版本，Sun公司也沒有承諾會對該本地化版本進行升級，但其仍不失為一個Java中文問題的解決方案。

2）選擇合適的編譯參數。對於Java的國際版本來講，我們也可以在編譯Java應用的時候通過指定確定的編碼機制來實現其編譯結果對中文的支持。例如，對於需要支持繁體中文和簡體中文應用可以通過javac -encoding big5 sourcefile.java 和javac -encoding gb2312 sourcefile.java來編譯源程序。

3）通過編程的方式實現字符編碼的轉換代碼。通過編程的方式來解決Java的中文問題，已經成為瞭一種較為普遍的做法。下面就是一種最常見的字符編碼轉換函數，其將字符的編碼格式轉換為中文Windows系統的GBK編碼形式。

public static String toChinese(String strvalue){
try{
 if(strvalue==null) return null;
 else{ 
  strvalue = new String(strvalue.getBytes("ISO8859_1"), "GBK");
return strvalue;
 } 
}catch(Exception e){
    return null; 
  }
}

4）定義字符輸出集。對於JSP應用，我們可以通過< %@ page contentType=”text/html; charset=GBK” % >或< %@ page contentType=”text/html; charset=GB2312″ % >來定義JSP頁面的字符輸出集。當然，我們也可以通過HTML的標記< META HTTP-EQUIV=”Content-Type” CONTENT=”text/html; charset=gb2312″ >來定義字符的輸出集。

存在的問題

根據方法實現的方式，我們可以將以上四種方法分為兩類，一類是通過利用某些標準或者規則來實現的方法，上面的1)、2)、4）都屬於此類；一類是通過針對性的編程來實現的方法，上面所提的方法3）就屬於此類。

由於方法1)，2)，4）是具有規范性的一類方法，所以方法比較簡單，解決方案也不具備較大的針對性，較為通用，例如我們可以采用方法2）的編譯方式通過編譯Java源文件來實現內碼的預置，而無需考慮源碼到底有哪些部分出現瞭Java的中文處理問題，諸如輸出亂碼等等。

但是，正由於這些方法不具備針對性，解決問題的方法過於統一，所以在某些情況下，它們並不能徹底地解決Java的中文問題。舉一個非常常見的例子。在通常情況下，用戶的Java應用往往需要與其它Java應用接口進行交互，例如通過某種版本的JDBC訪問數據庫。由於JDBC的驅動所支持的編碼隨著提供商乃至版本的不同而不同，所以如果在數據庫的輸入輸出過程中出現中文不能正確處理問題時，我們需要在數據的輸入和輸出過程做兩次正好相反的編碼轉換，這對於方法1），2），4）來說，往往是無法解決的。當然，對於方法2，我們也可以通過采用一些技巧使來滿足上面的情況，一個最有效的辦法就是盡量將Java應用的各個部分組件化。例如我們可以通過將數據庫的讀入和輸出代碼分解在不同的源文件上來實現分別編譯，從而滿足不同的字符編碼要求。但是通常的程序設計都不太可能滿足這種要求，因為這種程序的劃分結果很可能是不合理的。例如，我們將數據庫的讀出和寫入方法封裝到一個類中是比較合適的一種設計，但如果將該類的這兩個方法分別實現在兩個文件裡則變得非常不合理。因此對於1），2），4）方法來說，雖然實現比較簡單，但卻具有一些無法克服的缺點。這也是那些實現起來相對復雜的編程方法得以流行的原因。

相對於方法1），2），4）來說，方法3）具有更好的針對性和靈活性。程序可以根據不同的情況做出靈活的處理，在任何需要的地方進行字符的編碼轉換，但是該方法的特點也對軟件的開發人員提出瞭更高要求–必須能夠準確的捕捉到有可能發生中文處理問題的地方，並做出正確的判斷和處理。

分析的原則

總的說來，所有解決Java中文處理的方法都不是很復雜。相反的是，由於Java技術特別是J2EE技術涉及的內容繁多，各種Web服務器、應用服務器以及JDBC數據庫驅動等參差不齊，所以如何正確而及時的發現應用的中文處理問題則變得相對復雜的多。那麼我們如何來發現這些問題呢？

通常，Java處理中文時所產生的問題都是由於用戶的Java應用所采用的缺省編碼格式與目標或者應用所要讀入字符的編碼格式不同而造成的，而引起這些不同的一個主要原因就是用戶的Java應用與其它應用進行瞭編碼格式不匹配的數據交換（包括直接或間接的數據輸入、輸出）。所以，為瞭及時發現問題，我們可以由這一點入手，根據以下的原則對應用進行分析：

註意字符變量情況。由於變量的字符編碼形式較為隱蔽，多次變量間數值的改變和運算可能會引起字符集的改變；在變量與頁面所提交數據的各種操作中，較容易發生不同編碼格式字符進行運算的情況。
註意任何形式的字符讀入與輸出。之所以要提到任何形式，是因為Java應用大多數都是作為網絡應用開發的，所以與其它語言的應用相比，Java應用需要面對網絡世界各種各樣的字符數據交換形式。例如各種表單的數據提交，URL形式的數據讀入，經過加密運算的字符數據交換，網頁控件選擇結果的輸入，控件內容的的顯示（如List控件）等等。
小心使用第三方的組件和應用。由於第三方組件和應用的實現是非透明的，所以一般情況下，我們很難判斷這些組件或驅動的缺省編碼格式是什麼，也無法對其進行控制。因此，在使用它們所提供的接口函數進行數據交換的時候要特別註意，如果確實出現中文無法正確處理情況，應首先檢查我們自己的代碼並調整相關代碼以適應這些接口，因為這些組件或者應用基本上不會提供調整編碼機制的接口。必要時，我們可能需要采用其它可替換的組件或者應用。
註意被請求對象所含有的數據輸入與輸出。這是非常隱蔽的一類情況，當我們的應用以對象的方式（例如序列化的對象）進行交互時，如果這個對象內
Related posts:

Related posts:

發佈留言 取消回覆

發佈留言取消回覆