盡管關於Java中文問題的討論已經相當多了，但由於Java的相關技術標准繁多，面向Java的Web服務器、應用服務器以及JDBC數據庫驅動等都沒有官方的標准，所以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應用，我們可以通過或來定義JSP頁面的字符輸出集。當然，我們也可以通過HTML的標記來定義字符的輸出集。
存在的問題
根據方法實現的方式，我們可以將以上四種方法分為兩類，一類是通過利用某些標准或者規則來實現的方法，上面的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應用與其它應用進行了編碼格式不匹配的數據交換（包括直接或間接的數據輸入、輸出）。所以，為了及時發現問題，我們可以由這一點入手，根據以下的原則對應用進行分析：
1.注意字符變量情況。由於變量的字符編碼形式較為隱蔽，多次變量間數值的改變和運算可能會引起字符集的改變；在變量與頁面所提交數據的各種操作中，較容易發生不同編碼格式字符進行運算的情況。
2.注意任何形式的字符讀入與輸出。之所以要提到任何形式，是因為Java應用大多數都是作為網絡應用開發的，所以與其它語言的應用相比，Java應用需要面對網絡世界各種各樣的字符數據交換形式。例如各種表單的數據提交，URL形式的數據讀入，經過加密運算的字符數據交換，網頁控件選擇結果的輸入，控件內容的的顯示（如List控件）等等。
3.小心使用第三方的組件和應用。由於第三方組件和應用的實現是非透明的，所以一般情況下，我們很難判斷這些組件或驅動的缺省編碼格式是什麼，也無法對其進行控制。因此，在使用它們所提供的接口函數進行數據交換的時候要特別注意，如果確實出現中文無法正確處理情況，應首先檢查我們自己的代碼並調整相關代碼以適應這些接口，因為這些組件或者應用基本上不會提供調整編碼機制的接口。必要時，我們可能需要采用其它可替換的組件或者應用。
4.注意被請求對象所含有的數據輸入與輸出。這是非常隱蔽的一類情況，當我們的應用以對象的方式（例如序列化的對象）進行交互時，如果這個對象內部含有字符數據的處理過程，或者含有某些數據的輸入、輸出，甚至是拋出一段用中文注解的異常，都可能出現中文無法正確顯示等問題。由於這些行為往往被封裝在對象中，所以我們在編寫程序時，很容易忽略這種可能情況。並且這種情況帶有一定的不可預見性，例如我們可能不清楚這個對象會在什麼時候拋出什麼樣的異常，所以這時我們就需要做一定的測試工作。
5.注意數據庫的數據訪問過程。Java通過JDBC與數據庫建立連接。對於JDBC驅動程序來說，由於目前大部分的JDBC驅動程序並不是針對中文系統而設計的(中文數據大都采用ISO-8859-1編碼方式)，所以一般情況下在數據讀寫過程中往往都需要字符編碼的轉化。但是我們仍建議用戶在使用這些JDBC驅動時，仔細閱讀它的說明。如果確實無法弄清JDBC字符數據的編碼到底是什麼，我們的建議是做一些必要的測試。例如下面是一組在簡體中文Win2000平台下，采用Weblogic 6.0所提供的JDBC驅動從MS SQL Server2000中正確讀入中文字符的代碼（例子中進行了字符運算）：
...
Class.forName("weblogic.jdbc.mssqlserver4.Driver").newInstance();
conn = myDriver.connect("jdbc:weblogic:mssqlserver4", props);
conn.setCatalog("labmanager");
Statement st = conn.createStatement();
//execute a query
String testStr;
String testTempStr = new String() ;
testStr=new String(testTempStr.getBytes("ISO-8859-1"));//編碼轉化
DatabaseMetaData DBMetaData =conn.getMetaData();
ResultSet rs=DBMetaData.getTables(null,null,null,new String[]{"TABLE"});
while (rs.next()){
for(int j=1; j<=rs.getMetaData().getColumnCount(); j++){
testStr=testStr+String(rs.getObject(j).toString().getBytes("ISO-8859-1"));
}
}
然而，需要注意的是，不同的JDBC驅動對相同的數據庫的支持並不同，而同一類JDBC驅動對不同的數據庫的支持也不相同，也就是說我們的字符轉化代碼在JDBC驅動改變甚至是版本變化情況下都有可能無法正確工作。例如對於上面的例子，在同樣的環境下改用i-net 的Una 2000 Driver Version 2.03 for MS SQL Server時，是無法正確處理中文的。原因很簡單，這個JDBC驅動本身支持的就是GBK的編碼機制，所以根本就不需要做任何的編碼轉化。
6.必要的測試。由於Java中文問題的產生隨著Web服務器，浏覽器，運行環境和開發工具的不同都可能發生變化，所以為了更好的避免問題的發生，我們必須作一些針對性的測試。另外，在我們確實無法通過分析來確定Java的中文處理問題是否可能發生的情況下或者無法知道問題的發生是由於哪個環節（是Web服務器，浏覽器還是JDBC數據驅動等等）引起的時候，測試工作則變得非常重要。並且我們可能需要較為全面的測試，例如對Web服務器，浏覽器和JDBC數據驅動等都要做測試，這樣有利於我們找出那些隱藏在多個環節協調過程中所產生的問題。
結論
事實上，Java中文處理之所以存在問題，其根本原因是由於被操作的中文字符（變量）的編碼格式與目標的編碼格式不同造成的，所有這些問題其實都是發生在字符的讀入、輸出過程中的，只要我們把握住這一環節，就可以更好的發現、分析、處理和預防Java的中文問題了。
