開發java應用出現亂碼是很常見的，畢竟現在unicode的使用還不是很廣泛，在使用gb2312（包含了gbk簡體，big5繁體）的系統中要正確實現中文的display和資料庫的儲存是最基本的要求。

1，首先developer要明確自己為什麼會遇到亂碼，遇到什麼樣的亂碼（無意義的符號還是一串問號或者其它什麼東西）。新手遇到一堆很亂的字元時通常不知所措，最直接的反映就是開啟google搜尋“java中文”（這個字串在搜尋引擎上的查詢頻率非常高），然後一個一個的去看別人的解決方法。這樣做沒有錯，但是很難達到目的，原因下面會提到。總之，出現亂碼的原因是非常多的，解決的方法也完全不一樣，要解決問題必須先分析自己的

2，具體說來，需要哪些資訊才能確定專案中的亂碼的根源。 
a，開發者所用的作業系統 
b，j2ee容器的名稱，版本 
c，資料庫的名稱，版本（精確版本）以及jdbc驅動的版本 
d，出現亂碼的source code（比如是system out 出來的，還是jsp頁面中的，如果是jsp中的，那麼頭部宣告的情況也很重要）

3，如何初步分析亂碼出現的原因。有了上述的資訊，基本上就可以發帖求助了，相信放到javaworld等論壇上，很快就會有高手給你提出有效的解決方案的。當然不能總靠發帖求助，也要試試自行解決問題。如何下手呢？ 
a，分析一下你的“亂碼”到底是什麼編碼。這個其實不難，比如

b，如果用上面的步驟能得到正確的中文，說明你的資料肯定是在的，只不過是介面中沒有正確顯示而已。那麼第二步就該糾正你的view部分了，通常需要檢查的是jsp中是否選擇了正確的頁面編碼。在此要宣告被很多人誤解的一點，那就是 
<%@ page contentType="text/html; charset=GB2312" %> 
指令和 
<META http-equiv=Content-Type content="text/html; charset=gb2312"> 
兩者的不同。通常網上的很多文章在提到中文問題時都是說資料庫中選擇unicode或者gb2312儲存，同時在jsp中用page指令宣告編碼就可以解決。但是我覺得這種說法很不負責任，害的我費了N多時間為本來並不存在的亂碼而鬱悶。實際上page的作用是在jsp被編譯成為html的過程中提供編碼方式讓java來“讀取”表示式當中的String（有點類似於上面的第三個語句的作用），而meta的作用是眾所周知的為IE瀏覽器提供編碼選擇，是用來“顯示”最後的資料的。但是沒有看到有人提醒這一點，我一直把page當成meta在用，導致本來是iso-8859的資料，被page指令讀成gb2312，於是亂碼，所以又加了編碼轉化的函式把所有的string資料都從iso8859轉到gb2312（為什麼這麼轉，當時也沒考慮這麼多，因為這麼做可以正常顯示了，所以就這麼改了，呵呵當時實在沒有時間慢慢排查問題了）。

4，資料庫選擇什麼樣的編碼比較好。目前流行的DB主要有sql server，mysql，oracle，DB2等，其中mysql作為免費DB中的老大，效能和功能是得到公認的，安裝配置比較方便，相應的driver也比較完善，價效比是絕對的OK。所以就以mysql為例。我個人建議採用mysql的預設編碼來儲存，也就是iso-8859-1（在mysql的選項中對應於latin-1）。理由主要有這麼幾個，一是iso-8859-1對中文的支援不錯；二是跟java中的預設編碼一致，至少在很多地方免除了轉換編碼的麻煩；三是預設的比較穩定，相容性也更好，因為多編碼的支援是由具體的DB產品提供的，別說跟其它的DB會不相容，即使自身的不同版本也可能出現相容性的問題。例如mysql 4.0以前的產品中，很多中文的解決方案是利用connection中的characterEncoding欄位來制定編碼，比如gb2312什麼的，這樣是ok 
的，因為原資料都是ISO8859_1編碼，jdbc驅動會採用url裡面指定的character set來進行編碼，resultSet.getString(*)取出的就是編碼後的字串。這樣就直接拿到gb2312的資料了。但是mysql 4.1的推出給很多dbadmin帶來了不小的麻煩，因為mysql4.1支援column level的character set，每個table,column都可以指定編碼，不指定就是ISO8895_1，因此jdbc取出資料後會根據column的character set來進行編碼，而不再是用一個全域性的引數來取所有的資料了。這從另一個方面也說明了亂碼問題的產生實在是很複雜的事情，原因太多了。我也只是針對自己遇到的實際情況提供一些解決思路，有什麼錯誤的地方請email至[email protected]希望能更多的看到達人自己的文章，而不是一堆以訛傳訛的拷貝。 
Internel Use Only. 
Any Question,please reffer to [email protected]

------------------------------------------------------------------------------------------------------------------------------------------------------- 
由於Java程式設計中的中文問題是一個老生常談的問題，在閱讀了許多關於Java中文問題解決方法之後，結合作者的程式設計實踐，我發現過去談的許多方法都不能清晰地說明問題及解決問題，尤其是跨平臺時的中文問題。於是我給出此篇文章，內容包括對控制檯執行的class、Servelets、JSP及EJB類中的中文問題我剖析和建議解決辦法。希望大家指教。

Abstract：本文深入分析了Java程式設計中Java編譯器對Java原始檔和JVM對class類檔案的編碼/解碼過程，通過此過程的解析透視出了Java程式設計中中文問題產生的根本原因，最後給出了建議的最優化的解決Java中文問題的方法。

1、中文問題的來源

計算機最初的作業系統支援的編碼是單位元組的字元編碼，於是，在計算機中一切處理程式最初都是以單位元組編碼的英文為準進行處理。

隨著計算機的發展，為了適應世界其它民族的語言（當然包括我們的漢字），人們提出了UNICODE編碼，它採用雙位元組編碼，相容英文字元和其它民族的雙位元組字元編碼，所以，目前，大多數國際性的軟體內部均採用UNICODE編碼，在軟體執行時，它獲得本地支援系統（多數時間是作業系統）預設支援的編碼格式，然後再將軟體內部的UNICODE轉化為本地系統預設支援的格式顯示出來。

Java的JDK和JVM即是如此，我這裡說的JDK是指國際版的JDK，我們大多數程式設計師使用的是國際化的JDK版本，以下所有的JDK均指國際化的JDK版本。我們的漢字是雙位元組編碼語言，為了能讓計算機處理中文，我們自己制定的gb2312、GBK、GBK2K等標準以適應計算機處理的需求。

所以，大部分的作業系統為了適應我們處理中文的需求，均定製有中文作業系統，它們採用的是GBK,GB2312編碼格式以正確顯示我們的漢字。如：中文Windows預設採用的是GBK編碼顯示，在中文Windows2000中儲存檔案時預設採用的儲存檔案的編碼格式也是GBK的，即所有在中文 Windows2000中儲存的檔案它的內部編碼預設均採用GBK編碼，注意：GBK是在GB2312基礎上擴充來的。

由於Java語言內部採用UNICODE編碼，所以在Java程式執行時，就存在著一個從UNICODE編碼和對應的作業系統及瀏覽器支援的編碼格式轉換輸入、輸出的問題，這個轉換過程有著一系列的步驟，如果其中任何一步出錯，則顯示出來的漢字就會出是亂碼，這就是我們常見的Java中文問題。

同時，Java是一個跨平臺的程式語言，也即我們編寫的程式不僅能在中文windows上執行，也能在中文Linux等系統上執行，同時也要求能在英文等系統上執行（我們經常看到有人把在中文Windows2000上編寫的Java程式，移植到英文Linux上執行）。這種移植操作也會帶來中文問題。

還有，有人使用英文的作業系統和英文的IE等瀏覽器，來執行帶中文字元的程式和瀏覽中文網頁，它們本身就不支援中文，也會帶來中文問題。

幾乎所有的瀏覽器預設在傳遞引數時都是以UTF-8編碼格式來傳遞，而不是按中文編碼傳遞，所以，傳遞中文引數時也會有問題，從而帶來亂碼現象。

總之，以上幾個方面是Java中的中文問題的主要來源，我們把以上原因造成的程式不能正確執行而產生的問題稱作：Java中文問題。

2、Java編碼轉換的詳細過程

我們常見的Java程式包括以下類別：

*直接在console上執行的類(包括視覺化介面的類)

*JSP程式碼類（注：JSP是Servlets類的變型）

*Servelets類

*EJB類

*其它不可以直接執行的支援類

這些類檔案中，都有可能含有中文字串，並且我們常用前三類Java程式和使用者直接互動，用於輸出和輸入字元，如：我們在JSP和Servlet中得到客戶端送來的字元，這些字元也包括中文字元。無論這些Java類的作用如何，這些Java程式的生命週期都是這樣的：

*程式設計人員在一定的作業系統上選擇一個合適的編輯軟體來實現源程式程式碼並以.Java副檔名儲存在作業系統中，例如我們在中文Windows2000中用記事本編輯一個Java源程式。

*程式設計人員用JDK中的Javac.exe來編譯這些原始碼，形成.class類(JSP檔案是由容器呼叫JDK來編譯的)。

*直接執行這些類或將這些類佈署到WEB容器中去執行，並輸出結果。

那麼，在這些過程中，JDK和JVM是如何將這些檔案如何編碼和解碼並執行的呢？

這裡，我們以中文Windows2000作業系統為例說明Java類是如何來編碼和被解碼的。

第一步，我們在中文Windows2000中用編輯軟體如記事本編寫一個Java源程式檔案(包括以上五類Java程式)，程式檔案在儲存時預設採用了作業系統預設支援GBK編碼格式(作業系統預設支援的格式為file.encoding格式)形成了一個.Java檔案，也即，Java程式在被編譯前，我們的Java源程式檔案是採用作業系統預設支援的file.encoding編碼格式儲存的，Java源程式中含有中文資訊字元和英文程式程式碼；要檢視系統的file.encoding引數，可以用以下程式碼：

public class ShowSystemDefaultEncoding 
{ public static void main(String[] args) 
{ String encoding = 
System.getProperty("file.encoding"); 
System.out.println(encoding); 
} 
}

　　第二步，我們用JDK的Javac.exe檔案編譯我們的Java源程式，由於JDK是國際版的，在編譯的時候，如果我們沒有用- encoding引數指定我們的Java源程式的編碼格式，則Javac.exe首先獲得我們作業系統預設採用的編碼格式，也即在編譯Java程式時，若我們不指定源程式檔案的編碼格式，JDK首先獲得作業系統的file.encoding引數(它儲存的就是作業系統預設的編碼格式，如 Windows2000，它的值為GBK)，然後JDK就把我們的Java源程式從file.encoding編碼格式轉化為Java內部預設的 UNICODE格式放入記憶體中。

然後，Javac把轉換後的unicode格式的檔案進行編譯成.class類檔案，此時.class檔案是UNICODE編碼的，它暫放在記憶體中，緊接著，JDK將此以UNICODE編碼的編譯後的class檔案儲存到我們的作業系統中形成我們見到的.class檔案。

對我們來說，我們最終獲得的.class檔案是內容以UNICODE編碼格式儲存的類檔案，它內部包含我們源程式中的中文字串，只不過此時它己經由file.encoding格式轉化為UNICODE格式了。

這一步中，對於JSP源程式檔案是不同的，對於JSP，這個過程是這樣的：即WEB容器呼叫JSP編譯器，JSP編譯器先檢視JSP檔案中是否設定有檔案編碼格式，如果JSP檔案中沒有設定JSP檔案的編碼格式，則JSP編譯器呼叫JDK先把JSP檔案用JVM預設的字元編碼格式(也即WEB容器所在的作業系統的預設的file.encoding)轉化為臨時的Servlet類，然後再把它編譯成UNICODE格式的class類，並儲存在臨時檔案夾中。

如：在中文Windows2000上，WEB容器就把JSP檔案從GBK編碼格式轉化為UNICODE格式，然後編譯成臨時儲存的Servlet類，以響應使用者的請求。

　第三步，執行第二步編譯出來的類，分為三種情況： 
A、直接在console上執行的類

B、 EJB類和不可以直接執行的支援類(如JavaBean類)

C、 JSP程式碼和Servlet類

D、 Java程式和資料庫之間

下面我們分這四種情況來看。

A、直接在console上執行的類

這種情況，執行該類首先需要JVM支援，即作業系統中必須安裝有JRE。執行過程是這樣的：首先Java啟動JVM，此時JVM讀出作業系統中儲存的class檔案並把內容讀入記憶體中，此時記憶體中為UNICODE格式的class類，然後JVM執行它，如果此時此類需要接收使用者輸入，則類會預設用 file.encoding編碼格式對使用者輸入的串進行編碼並轉化為unicode儲存入記憶體（使用者可以設定輸入流的編碼格式）。

程式執行後，產生的字串（UNICODE編碼的）再回交給JVM，最後JRE把此字串再轉化為file.encoding格式(使用者可以設定輸出流的編碼格式)傳遞給作業系統顯示介面並輸出到介面上。以上每一步的轉化都需要正確的編碼格式轉化，才能最終不出現亂碼現象。 B、EJB類和不可以直接執行的支援類(如JavaBean類)

由於EJB類和不可以直接執行的支援類，它們一般不與使用者直接互動輸入和輸出，它們常常與其它的類進行互動輸入和輸出，所以它們在第二步被編譯後，就形成了內容是UNICODE編碼的類儲存在作業系統中了，以後只要它與其它的類之間的互動在引數傳遞過程中沒有丟失，則它就會正確的執行。

C、JSP程式碼和Servlet類

經過第二步後，JSP檔案也被轉化為Servlets類檔案，只不過它不像標準的Servlets一校存在於classes目錄中，它存在於WEB容器的臨時目錄中，故這一步中我們也把它做為Servlets來看。

對於Servlets，客戶端請求它時，WEB容器呼叫它的JVM來執行Servlet，首先，JVM把Servlet的class類從系統中讀出並裝入記憶體中，記憶體中是以UNICODE編碼的Servlet類的程式碼，然後JVM在記憶體中執行該Servlet類，如果Servlet在執行的過程中，需要接受從客戶端傳來的字元如：表單輸入的值和URL中傳入的值，此時如果程式中沒有設定接受引數時採用的編碼格式，則WEB容器會預設採用ISO- 8859-1編碼格式來接受傳入的值並在JVM中轉化為UNICODE格式的儲存在WEB容器的記憶體中。

Servlet執行後生成輸出，輸出的字串是UNICODE格式的，緊接著，容器將Servlet執行產生的UNICODE格式的串（如html 語法，使用者輸出的串等）直接傳送到客戶端瀏覽器上並輸出給使用者，如果此時指定了傳送時輸出的編碼格式，則按指定的編碼格式輸出到瀏覽器上，如果沒有指定，則預設按ISO-8859-1編碼傳送到客戶的瀏覽器上。

D、Java程式和資料庫之間

對於幾乎所有資料庫的JDBC驅動程式，預設的在Java程式和資料庫之間傳遞資料都是以ISO-8859-1為預設編碼格式的，所以，我們的程式在向資料庫記憶體儲包含中文的資料時，JDBC首先是把程式內部的UNICODE編碼格式的資料轉化為ISO-8859-1的格式，然後傳遞到資料庫中，在資料庫儲存資料時，它預設即以ISO-8859-1儲存，所以，這是為什麼我們常常在資料庫中讀出的中文資料是亂碼。

3、分析常見的Java中文問題幾個必須清楚的原則

首先，經過上面的詳細分析，我們可以清晰地看到，任何Java程式的生命期中，其編碼轉換的關鍵過程是在於：最初編譯成class檔案的轉碼和最終向用戶輸出的轉碼過程。

其次，我們必須瞭解Java在編譯時支援的、常用的編碼格式有以下幾種：

*ISO-8859-1，8-bit, 同8859_1,ISO-8859-1,ISO_8859_1等編碼

*Cp1252，美國英語編碼，同ANSI標準編碼

*UTF-8，同unicode編碼

*GB2312，同gb2312-80,gb2312-1980等編碼

*GBK，同MS936，它是gb2312的擴充及其它的編碼，如韓文、日文、繁體中文等。同時，我們要注意這些編碼間的相容關體系如下：

unicode和UTF-8編碼是一一對應的關係。GB2312可以認為是GBK的子集，即GBK編碼是在gb2312上擴充套件來的。同時，GBK編碼包含了20902個漢字，編碼範圍為：0x8140-0xfefe，所有的字元可以一一對應到UNICODE2.0中來。

再次，對於放在作業系統中的.Java源程式檔案，在編譯時，我們可以指定它內容的編碼格式，具體來說用-encoding來指定。注意：如果源程式中含有中文字元，而你用-encoding指定為其它的編碼字元，顯然是要出錯的。

用-encoding指定原始檔的編碼方式為GBK或gb2312，無論我們在什麼系統上編譯含有中文字元的Java源程式都不會有問題，它都會正確地將中文轉化為UNICODE儲存在class檔案中。

然後，我們必須清楚，幾乎所有的WEB容器在其內部預設的字元編碼格式都是以ISO-8859-1為預設值的，同時，幾乎所有的瀏覽器在傳遞引數時都是預設以UTF-8的方式來傳遞引數的。

所以，雖然我們的Java原始檔在出入口的地方指定了正確的編碼方式，但其在容器內部執行時還是以ISO-8859-1來處理的。

4、中文問題的分類及其建議最優解決辦法

瞭解以上Java處理檔案的原理之後，我們就可以提出了一套建議最優的解決漢字問題的辦法。我們的目標是：我們在中文系統中編輯的含有中文字串或進行中文處理的Java源程式經編譯後可以移值到任何其它的作業系統中正確執行，或拿到其它作業系統中編譯後能正確執行，能正確地傳遞中文和英文引數，能正確地和資料庫交流中英文字串。我們的具體思路是：在Java程式轉碼的入口和出口及Java程式同用戶有輸入輸出轉換的地方限制編碼方法使之正確即可。

具體解決辦法如下：

1、針對直接在console上執行的類

對於這種情況，我們建議在程式編寫時，如果需要從使用者端接收使用者的可能含有中文的輸入或含有中文的輸出，程式中應該採用字元流來處理輸入和輸出，具體來說，應用以下面向字元型節點流型別：

對檔案：FileReader，FileWrieter

其位元組型節點流型別為：FileInputStream，FileOutputStream

對記憶體（陣列）：CharArrayReader，CharArrayWriter

其位元組型節點流型別為：ByteArrayInputStream，ByteArrayOutputStream

對記憶體（字串）：StringReader，StringWriter

對管道：PipedReader，PipedWriter

其位元組型節點流型別為：PipedInputStream，PipedOutputStream

同時，應該用以下面向字元型處理流來處理輸入和輸出：

BufferedWriter，BufferedReader

其位元組型的處理流為：BufferedInputeStream，