先Java（包括JSP）源文件中很可能包含有中文，而Java和JSP源文件的保存方式是基於字節流的，如果Java和JSP編譯成class文件過程
中，使用的編碼方式與源文件的編碼不壹致，就會出現亂碼。基於這種亂碼，建議在Java文件中盡量不要寫中文（註釋部分不參與編譯，寫中文沒關系），如果
必須寫的話，盡量手動帶參數－ecoding GBK或－ecoding gb2312編譯；對於JSP，在文件頭加上<%
@ page contentType="text/html;charset=GBK"%>或<%@ page contentType=
"text/html;charset=gb2312"%>基本上就能解決這類亂碼問題。本文要重點討論的是第二類亂碼，即Java程序與其他存儲媒介交互時產生的亂碼。很多存儲媒介，如數據庫，文件，流等的存儲方式都是基於字節流的，Java程序與這些媒介交互時就會發生字符(char)與字節(byte)之間的轉換，具體情況如下：從頁面form提交數據到java程序 byte－>char
從java程序到頁面顯示 char?>byte從數據庫到java程序 byte?>char
從java程序到數據庫 char?>byte從文件到java程序 byte－>char
從java程序到文件 char－>byte從流到java程序 byte－>char
從java程序到流 char－>byte如果在以上轉換過程中使用的編碼方式與字節原有的編碼不壹致，很可能就會出現亂碼。二、解決方法前面已經提到了Java程序與其他媒介交互時字符和字節的轉換過程，如果這些轉換過程中容易產生亂碼。解決這些亂碼問題的關鍵在於確保轉換時使用的編碼方式與字節原有的編碼方式保持壹致，下面分別論述（Java或JSP自身產生的亂碼請參看第壹部分）。1、JSP與頁面參數之間的亂碼
JSP
獲取頁面參數時壹般采用系統默認的編碼方式，如果頁面參數的編碼類型和系統默認的編碼類型不壹致，很可能就會出現亂碼。解決這類亂碼問題的基本方法是在頁
面獲取參數之前，強制指定request獲取參數的編碼方式：request.setCharacterEncoding("GBK")或
request.setCharacterEncoding("gb2312")。
如果在JSP將變量輸出到頁面時出現了亂碼，可以通過設置
response.setContentType("text/html;charset=GBK")或response.setContentType
("text/html;charset=gb2312")解決。
如果不想在每個文件裏都寫這樣兩句話，更簡潔的辦法是使用Servlet規範中的過慮器指定編碼，過濾器的在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與數據庫之間的亂碼
大
部分數據庫都支持以unicode編碼方式，所以解決Java與數據庫之間的亂碼問題比較明智的方式是直接使用unicode編碼與數據庫交互。很多數據
庫驅動自動支持unicode，如Microsoft的SQLServer驅動。其他大部分數據庫驅動，可以在驅動的url參數中指定，如如mm的
mysql驅動：jdbc:mysql://localhost/WEBCLDB?useUnicode=true&
characterEncoding=GBK。3、Java與文件/流之間的亂碼
Java讀寫文件最常用的類是
FileInputStream/FileOutputStream和FileReader/FileWriter。其中FileInputStream
和FileOutputStream是基於字節流的，常用於讀寫二進制文件。讀寫字符文件建議使用基於字符的FileReader和
FileWriter，省去了字節與字符之間的轉換。但這兩個類的構造函數默認使用系統的編碼方式，如果文件內容與系統編碼方式不壹致，可能會出現亂碼。
在這種情況下，建議使用FileReader和FileWriter的父類：
InputStreamReader/OutputStreamWriter，它們也是基於字符的，但在構造函數中可以指定編碼類型：
InputStreamReader(InputStream in, Charset cs) 和OutputStreamWriter
(OutputStream out, Charset cs)。4、其他
上面提到的方法應該能解決大部分亂碼問題，如果在
其他地方還出現亂碼，可能需要手動修改代碼。解決Java亂碼問題的關鍵在於在字節與字符的轉換過程中，妳必須知道原來字節或轉換後的字節的編碼方式，轉
換時采用的編碼必須與這個編碼方式保持壹致。我們以前使用Resin服務器，使用smartUpload組件上傳文件，上傳文件同時傳遞的中文參數獲取沒
有亂碼問題。當在Linux中把Resin設置成服務後，上傳文件同時的中文參數獲取出現了亂碼。這個問題困擾了我們很久，後來我們分析
smartUpload組件的源文件，因為文件上傳采用的是字節流的方式，裏面包含的參數名稱和值也是字節流的方式傳遞的。smartUpload組件讀
取字節流後再將參數名稱和值從字節流中解析出來，問題就出現在smartUpload將字節流轉換成字符串時采用了系統默認的編碼，而將Resin設置成
服務後，系統默認的編碼可能發生了改變，因此出現了亂碼。後來，我們更改了smartUpload的源文件，增加了壹個屬性charset和
setCharset(String)方法，將upload()方法中提取參數語句：
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 );
終於解決了這個亂碼問題。