Java中文問題一直困擾著很多初學(xué)者，如果了解了Java系統(tǒng)的中文問題原理，我們就可以對中文問題能夠采取根本的解決之道。
最古老的解決方案是使用String的字節(jié)碼轉(zhuǎn)換，這種方案問題是不方便，我們需要破壞對象封裝性，進行字節(jié)碼轉(zhuǎn)換。
還有一種方式是對J2EE容器進行編碼設(shè)置，如果J2EE應(yīng)用系統(tǒng)脫離該容器，則會發(fā)生亂碼，而且指定容器配置不符合J2EE應(yīng)用和容器分離的原
則。
在Java內(nèi)部運算中，涉及到的所有字符串都會被轉(zhuǎn)化為UTF-8編碼來進行運算。那么，在被Java轉(zhuǎn)化之前，字符串是什么樣的字符集？ Java總
是根據(jù)操作系統(tǒng)的默認(rèn)編碼字符集來決定字符串的初始編碼，而且Java系統(tǒng)的輸入和輸出的都是采取操作系統(tǒng)的默認(rèn)編碼。
因 此，如果能統(tǒng)一Java系統(tǒng)的輸入、輸出和操作系統(tǒng)3者的編碼字符集合，將能夠使Java系統(tǒng)正確處理和顯示漢字。這是處理Java系統(tǒng)漢字的
一個原則， 但是在實際項目中，能夠正確抓住和控制住Java系統(tǒng)的輸入和輸出部分是比較難的。J2EE中，由于涉及到外部瀏覽器和數(shù)據(jù)庫等，
所以中文問題亂碼顯得非 常突出。
J2EE應(yīng)用程序是運行在J2EE容器中。在這個系統(tǒng)中，輸入途徑有很多種：一種是通過頁面表單打包成請求 （request）發(fā)往服務(wù)器的；第二種
是通過數(shù)據(jù)庫讀入；還有第3種輸入比較復(fù)雜，JSP在第一次運行時總是被編譯成Servlet，JSP中常常包含 中文字符，那么編譯使用javac時，
Java將根據(jù)默認(rèn)的操作系統(tǒng)編碼作為初始編碼。除非特別指定，如在Jbuilder/eclipse中可以指定默 認(rèn)的字符集。
輸出途徑也有幾種：第一種是JSP頁面的輸出。由于JSP頁面已經(jīng)被編譯成Servlet，那么在輸出時，也將根據(jù)操作系統(tǒng)的默認(rèn)編碼來選擇輸出編
碼，除非指定輸出編碼方式；還有輸出途徑是數(shù)據(jù)庫，將字符串輸出到數(shù)據(jù)庫。
由此看來，一個J2EE系統(tǒng)的輸入輸出是非常復(fù)雜，而且是動態(tài)變化的，而Java是跨平臺運行的，在實際編譯和運行中，都可能涉及到不同的操
作系統(tǒng)，如果任由Java自由根據(jù)操作系統(tǒng)來決定輸入輸出的編碼字符集，這將不可控制地出現(xiàn)亂碼。
正是由于Java的跨平臺特性，使得字符集問題必須由具體系統(tǒng)來統(tǒng)一解決，所以在一個Java應(yīng)用系統(tǒng)中，解決中文亂碼的根本辦法是明確指定
整個應(yīng)用系統(tǒng)統(tǒng)一字符集。
指定統(tǒng)一字符集時，到底是指定ISO8859_1 、GBK還是UTF-8呢？
（1）如統(tǒng)一指定為ISO8859_1，因為目前大多數(shù)軟件都是西方人編制的，他們默認(rèn)的字符集就是ISO8859_1，包括操作系統(tǒng)Linux和數(shù)據(jù)庫MySQL
等。這樣，如果指定Jive統(tǒng)一編碼為ISO8859_1，那么就有下面3個環(huán)節(jié)必須把握：
開發(fā)和編譯代碼時指定字符集為ISO8859_1。
運行操作系統(tǒng)的默認(rèn)編碼必須是ISO8859_1，如Linux。
在JSP頭部聲明：。
（2）如果統(tǒng)一指定為GBK中文字符集，上述3個環(huán)節(jié)同樣需要做到，不同的是只能運行在默認(rèn)編碼為GBK的操作系統(tǒng)，如中文Windows。
統(tǒng)一編碼為ISO8859_1和GBK雖然帶來編制代碼的方便，但是各自只能在相應(yīng)的操作系統(tǒng)上運行。但是也破壞了Java跨平臺運行的優(yōu)越性，只在
一定范圍內(nèi)行得通。例如，為了使得GBK編碼在linux上運行，設(shè)置Linux編碼為GBK。
那么有沒有一種除了應(yīng)用系統(tǒng)以外不需要進行任何附加設(shè)置的中文編碼根本解決方案呢？
將Java/J2EE系統(tǒng)的統(tǒng)一編碼定義為UTF-8。UTF-8編碼是一種兼容所有語言的編碼方式，惟一比較麻煩的就是要找到應(yīng)用系統(tǒng)的所有出入口，然
后使用UTF-8去“結(jié)扎”它。
一個J2EE應(yīng)用系統(tǒng)需要做下列幾步工作：
開發(fā)和編譯代碼時指定字符集為UTF-8。JBuilder和Eclipse都可以在項目屬性中設(shè)置。
使用過濾器，如果所有請求都經(jīng)過一個Servlet控制分配器，那么使用Servlet的filter執(zhí)行語句，將所有來自瀏覽器的請求（request）轉(zhuǎn)換為
UTF-8，因為瀏覽器發(fā)過來的請求包根據(jù)瀏覽器所在的操作系統(tǒng)編碼，可能是各種形式編碼。關(guān)鍵一句：
request.setCharacterEncoding("UTF-8")。
網(wǎng)上有此filter的源碼，Jdon框架源碼中com.jdon.util.SetCharacterEncodingFilter
需要配置web.xml 激活該Filter。
在JSP頭部聲明：。
在Jsp的html代碼中，聲明UTF-8:
設(shè)定數(shù)據(jù)庫連接方式是UTF-8。例如連接MYSQL時配置URL如下：
jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=UTF-8
一般數(shù)據(jù)庫都可以通過管理設(shè)置設(shè)定UTF-8
其他和外界交互時能夠設(shè)定編碼時就設(shè)定UTF-8，例如讀取文件，操作XML等。
一、Java中文問題的由來
Java的內(nèi)核和class文件是基于unicode的，這使Java程序具有良好的跨平臺性，但也帶來了一些中文亂碼問題的麻煩。原因主要有兩方面，Java和JSP文件本身編譯時產(chǎn)生的亂碼問題和Java程序于其他媒介交互產(chǎn)生的亂碼問題。
首
先Java（包括JSP）源文件中很可能包含有中文，而Java和JSP源文件的保存方式是基于字節(jié)流的，如果Java和JSP編譯成class文件過程
中，使用的編碼方式與源文件的編碼不一致，就會出現(xiàn)亂碼?；谶@種亂碼，建議在Java文件中盡量不要寫中文（注釋部分不參與編譯，寫中文沒關(guān)系），如果
必須寫的話，盡量手動帶參數(shù)－ecoding GBK或－ecoding gb2312編譯；對于JSP，在文件頭加上<%
@ page contentType="text/html;charset=GBK"%>或<%@ page contentType=
"text/html;charset=gb2312"%>基本上就能解決這類亂碼問題。
本文要重點討論的是第二類亂碼，即Java程序與其他存儲媒介交互時產(chǎn)生的亂碼。很多存儲媒介，如數(shù)據(jù)庫，文件，流等的存儲方式都是基于字節(jié)流的，Java程序與這些媒介交互時就會發(fā)生字符(char)與字節(jié)(byte)之間的轉(zhuǎn)換，具體情況如下：
從頁面form提交數(shù)據(jù)到j(luò)ava程序 byte－>char
從java程序到頁面顯示 char?>byte
從數(shù)據(jù)庫到j(luò)ava程序 byte?>char
從java程序到數(shù)據(jù)庫 char?>byte
從文件到j(luò)ava程序 byte－>char
從java程序到文件 char－>byte
從流到j(luò)ava程序 byte－>char
從java程序到流 char－>byte
如果在以上轉(zhuǎn)換過程中使用的編碼方式與字節(jié)原有的編碼不一致，很可能就會出現(xiàn)亂碼。
二、解決方法
前面已經(jīng)提到了Java程序與其他媒介交互時字符和字節(jié)的轉(zhuǎn)換過程，如果這些轉(zhuǎn)換過程中容易產(chǎn)生亂碼。解決這些亂碼問題的關(guān)鍵在于確保轉(zhuǎn)換時使用的編碼方式與字節(jié)原有的編碼方式保持一致，下面分別論述（Java或JSP自身產(chǎn)生的亂碼請參看第一部分）。
1、JSP與頁面參數(shù)之間的亂碼
JSP
獲取頁面參數(shù)時一般采用系統(tǒng)默認(rèn)的編碼方式，如果頁面參數(shù)的編碼類型和系統(tǒng)默認(rèn)的編碼類型不一致，很可能就會出現(xiàn)亂碼。解決這類亂碼問題的基本方法是在頁
面獲取參數(shù)之前，強制指定request獲取參數(shù)的編碼方式：request.setCharacterEncoding("GBK")或
request.setCharacterEncoding("gb2312")。
如果在JSP將變量輸出到頁面時出現(xiàn)了亂碼，可以通過設(shè)置
response.setContentType("text/html;charset=GBK")或response.setContentType
("text/html;charset=gb2312")解決。
如果不想在每個文件里都寫這樣兩句話，更簡潔的辦法是使用Servlet規(guī)范中的過慮器指定編碼，過濾器的在web.xml中的典型配置和主要代碼如下：
web.xml:
<filter>
<filter-name>CharacterEncodingFilter</filter-name>
<filter-class>net.vschool.web.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>GBK</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CharacterEncodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
CharacterEncodingFilter.java:
public class CharacterEncodingFilter implements Filter
{
protected String encoding = null;
public void init(FilterConfig filterConfig) throws ServletException
{
this.encoding = filterConfig.getInitParameter("encoding");
}
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException
{
request.setCharacterEncoding(encoding);
response.setContentType("text/html;charset="+encoding);
chain.doFilter(request, response);
}
}
2、Java與數(shù)據(jù)庫之間的亂碼
大
部分?jǐn)?shù)據(jù)庫都支持以unicode編碼方式，所以解決Java與數(shù)據(jù)庫之間的亂碼問題比較明智的方式是直接使用unicode編碼與數(shù)據(jù)庫交互。很多數(shù)據(jù)
庫驅(qū)動自動支持unicode，如Microsoft的SQLServer驅(qū)動。其他大部分?jǐn)?shù)據(jù)庫驅(qū)動，可以在驅(qū)動的url參數(shù)中指定，如如mm的
mysql驅(qū)動：jdbc:mysql://localhost/WEBCLDB?useUnicode=true&
characterEncoding=GBK。
3、Java與文件/流之間的亂碼
Java讀寫文件最常用的類是
FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream
和FileOutputStream是基于字節(jié)流的，常用于讀寫二進制文件。讀寫字符文件建議使用基于字符的FileReader和
FileWriter，省去了字節(jié)與字符之間的轉(zhuǎn)換。但這兩個類的構(gòu)造函數(shù)默認(rèn)使用系統(tǒng)的編碼方式，如果文件內(nèi)容與系統(tǒng)編碼方式不一致，可能會出現(xiàn)亂碼。
在這種情況下，建議使用FileReader和FileWriter的父類：
InputStreamReader/OutputStreamWriter，它們也是基于字符的，但在構(gòu)造函數(shù)中可以指定編碼類型：
InputStreamReader(InputStream in, Charset cs) 和OutputStreamWriter
(OutputStream out, Charset cs)。
4、其他
上面提到的方法應(yīng)該能解決大部分亂碼問題，如果在
其他地方還出現(xiàn)亂碼，可能需要手動修改代碼。解決Java亂碼問題的關(guān)鍵在于在字節(jié)與字符的轉(zhuǎn)換過程中，你必須知道原來字節(jié)或轉(zhuǎn)換后的字節(jié)的編碼方式，轉(zhuǎn)
換時采用的編碼必須與這個編碼方式保持一致。我們以前使用Resin服務(wù)器，使用smartUpload組件上傳文件，上傳文件同時傳遞的中文參數(shù)獲取沒
有亂碼問題。當(dāng)在Linux中把Resin設(shè)置成服務(wù)后，上傳文件同時的中文參數(shù)獲取出現(xiàn)了亂碼。這個問題困擾了我們很久，后來我們分析
smartUpload組件的源文件，因為文件上傳采用的是字節(jié)流的方式，里面包含的參數(shù)名稱和值也是字節(jié)流的方式傳遞的。smartUpload組件讀
取字節(jié)流后再將參數(shù)名稱和值從字節(jié)流中解析出來，問題就出現(xiàn)在smartUpload將字節(jié)流轉(zhuǎn)換成字符串時采用了系統(tǒng)默認(rèn)的編碼，而將Resin設(shè)置成
服務(wù)后，系統(tǒng)默認(rèn)的編碼可能發(fā)生了改變，因此出現(xiàn)了亂碼。后來，我們更改了smartUpload的源文件，增加了一個屬性charset和
setCharset(String)方法，將upload()方法中提取參數(shù)語句：
String value = new String(m_binArray, m_startData, (m_endData - m_startData) + 1 );
改成了
String value = new String(m_binArray, m_startData, (m_endData - m_startData) + 1, charset );
終于解決了這個亂碼問題。