一、JSP頁面顯示亂碼
二、表單提交中文時出現亂碼
三、數據庫連接
大家在JSP的開發過程中，經常出現中文亂碼的問題，可能一至困擾著您，我現在把我在JSP開發中遇到的中文亂碼的問題及解決辦法寫出來供大家參考。
一、JSP頁面顯示亂碼
下面的顯示頁面(display.jsp)就出現亂碼：
對不同的WEB服務器和不同的JDK版本，處理結果就不一樣。原因：服務器使用的編碼方式不同和浏覽器對不同的字符顯示結果不同而導致的。解決辦法：在JSP頁面中指定編碼方�(gb2312),即在頁面的第一行加上：<%@ page contentType="text/html; charset=gb2312"%>，就可以消除亂碼了。完整頁面如�
�
<%@ page contentType="text/html; charset=gb2312"%>
二、表單提交中文時出現亂碼
下面是一個提交頁�(submit.jsp)，代碼如下：
下面是處理頁�(process.jsp)代碼�
<%@ page contentType="text/html; charset=gb2312"%>
如果submit.jsp提交英文字符能正確顯示，如果提交中文時就會出現亂碼。原因：浏覽器默認使用UTF-8編碼方式來發送請求，而UTF-8和GB2312編碼方式表示字符時不一樣，這樣就出現了不能識別字符。解決辦�:通過request.seCharacterEncoding("gb2312")對請求進行統一編碼，就實現了中文的正常顯示。修改後的process.jsp代碼如下�
<%@ page contentType="text/html; charset=gb2312"%>
<%
request.seCharacterEncoding("gb2312");
%>
三、數據庫連接出現亂碼
只要涉及中文的地方全部是亂碼，解決辦法：在數據庫的數據庫URL中加上useUnicode=true&characterEncoding=GBK 就OK了�
四、數據庫的顯示亂�
在mysql4.1.0�,varchar類型，text類型就會出現中文亂碼，對於varchar類型把它設為binary屬性就可以解決中文問題，對於text類型就要用一個編碼轉換類來處理，實現如下�
public class Convert
{
/** 把ISO-8859-1碼轉換成GB2312*/
public static String ISOtoGB(String iso)
{
String gb;
try
{
if(iso.equals("") || iso == null)
{
return "";
}
else
{
iso = iso.trim();
gb = new String(iso.getBytes("ISO-8859-1"),"GB2312");
return gb;
}
}
catch(Exception e)
{
System.err.print("編碼轉換錯誤�"+e.getMessage());
return "";
}
}
}
把它編譯成class，就可以調用Convert類的靜態方法ISOtoGB()來轉換編碼�
總結�
1. 在jsp�<%@ page contentType="text/html; charset=A"%>如果指定了，那麼在改jsp中所有構造的String（不是引用），如果沒有指定編碼，那麼這些String的編碼是A的。從request的得到的String如果沒有指定request的編碼的話，他是iso-8859-1的從別的地方得到的String是使用原來初始的編碼的，比如從數據庫得到String,如果數據庫的編碼是B,那麼該String的編碼是B而不是A的，也不是系統默認的。此時，如果要輸出的String的編碼不是A,那麼，很可能顯示亂碼的，所以首先要將String正確轉化為編碼A的String,然後輸出�
2. 在jsp�<%@ page contentType="text/html; charset=A" %>沒有指定，那麼相當於指定�<%@page contentType="text/html; charset=ISO-8859-1" %>
3� Servelte中如果執行了� response.setContentType("text/html;charset=A");説明將response的字符輸出流編碼設置為A,所有要輸出的String的編碼要轉化為A的，否則會得到亂碼的。Servelet中從request得到的String的編碼和jsp中一樣的，但是在servletjava文件中構造的String是使用的系統默認的編碼的。在servelt中從外部得到的String是使用原來的編碼的，比如從編碼為B的數據庫得到的數據是編碼為B�,不是A,也不是系統默認的編碼�
********************************************
轉載：JSP中文亂碼問題解決方法小結
在使用JSP的過程中，最使人頭疼的一個問題就是中文亂碼問題，以下是我在軟件開發中遇到的亂
碼問題以及解決方法�
1、JSP頁面亂碼
這種亂碼的原因是應為沒有在頁面裡指定使用的字符集編碼，解決方法：只要在頁面開始地方用下面代碼指定字符集編碼即可，
2、數據庫亂碼
這種亂碼會使你插入數據庫的中文變成亂碼，或者讀出顯示時也是亂碼，解決方法如下：
在數據庫連接字符串中加入編碼字符�
String Url="jdbc:mysql://localhost/digitgulf?
user=root&password=root&useUnicode=true&characterEncoding=GB2312";
並在頁面中使用如下代碼：
response.setContentType("text/html;charset=gb2312");
request.setCharacterEncoding("gb2312");
3、中文作為參數傳遞亂�
當我們把一段中文字符作為參數傳遞個另一頁面時，也會出現亂碼情況，解決方法如下：
在參數傳遞時對參數編碼，比如
RearshRes.jsp?keywords=" + java.net.URLEncoder.encode(keywords)
然後在接收參數頁面使用如下語句接�
keywords=new String(request.getParameter("keywords").getBytes("8859_1"));
4、JSP頁面亂碼加這句
<%@ page contentType="text/html; charset=gb2312" language="java" %>
********************************************
JSP/JDBC MySQL亂碼問題
綠起�
JSP的request 默認為ISO8859_1，所以在處理中文的時候，要顯示中文的話，必須轉成GBK的，如下String str=new String(request.getParameter("name").getBytes("ISO8859-1"),"GBK"); out.println(str); 這樣就可以顯示中文了
MYSQL操作時的中文問題�
這個要看MySQL的默認編碼了，一般不調整的話為latin1其實和ISO8859_1一樣，所以操作的時候要處理和他一致，不然就會亂碼�
1.插入中文�
String sql2="INSERT INTO test (name) VALUES('"+request.getParameter("name")+"')";
stmt.executeUpdate(sql2);
不用編碼就可以插入了
2.顯示插入的中文：
因為存入的是latin，所以顯示的時候就要GBK一�
String x=new String((rs.getString("title")).getBytes("ISO8859_1"),"GBK");
out.println(x);
3.設定存儲編碼�
當然在MySQL為latin1編碼時，也可以存的時候用GBK�
Connection con=DriverManager.getConnection("jdbc:mysql://localhost:3306/jsp?
useUnicode=true&characterEncoding=GBK","root","");
str1="中文";
String sql2="INSERT INTO test (name) VALUES('"+str1+"')";
這樣也可以很成功的插入了，呵�
********************************************
JSP/Servlet 中的漢字編碼問題
網上� JSP/Servlet � DBCS 字符編碼問題有許多優秀的文章和討論，本文對它們作一些整理，並結� IBM WebSphere Application Server 3.5（WAS）的解決方法作一些說明，希望它不是多余的�
1.問題的起�
每個國家（或區域）都規定了計算機信息交換用的字符編碼集，如美國的ASCII，中國的GB2312-80，日本的JIS等，作為該國�/區域內信息處理的基礎，有著統一編碼的重要作用。字符編碼集按長度分為SBCS（單字節字符集），DBCS（雙字節字符集）兩大類。早期的軟件（尤其是操作系統），為了解決本地字符信息的計算機處理，出現了各種本地化版本（L10N），為了區分，引進了LANG，Codepage等概念。但是由於各個本地字符集代碼范圍重疊，相互間信息交換困難；軟件各個本地化版本獨立維護成本較高。因此有必要將本地化工作中的共性抽取出來，作一致處理，將特別的本地化處理內容降低到最少。這也就是所謂的國際化（I18N）。各種語言信息被進一步規范為Locale信息。處理的底層字符集變成了幾乎包含了所有字形的 Unicode�
現在大部分具有國際化特征的軟件核心字符處理都是以Unicode為基礎的，在軟件運行時根據當時的Locale/Lang/Codepage設置確定相應的本地字符編碼設置，並依此處理本地字符。在處理過程中需要實現Unicode和本地字符集的相互轉換，甚或以Unicode為中間的兩個不同本地字符集的相互轉換。這種方式在網絡環境下被進一步延伸，任何網絡兩端的字符信息也需要根據字符集的設置轉換成可接受的內容�
Java 語言內部是用 Unicode 表示字符的，遵守 Unicode V2.0。Java 程序無論是從/往文件系統以字符流讀/寫文件，還是往 URL 連接� HTML 信息，或� URL 連接讀取參�值，都會有字符編碼的轉換。這樣做雖然增加了編程的復雜度，容易引起混淆，但卻是符合國際化的思想的�
從理論上來說，這些根據字符集設置而進行的字符轉換不應該產生太多問題。而事實是由於應用程序的實際運行環境不同，Unicode和各個本地字符集的補充、完善，以及系統或應用程序實現的不規范，轉碼時出現的問題時時困擾著程序員和用戶�
2.GB2312-80，GBK，GB18030-2000 漢字字符�
其實解決 JAVA 程序中的漢字編碼問題的方法往往很簡單，但理解其背後的原因，定位問題，還需
要了解現有的漢字編碼和編碼轉換�
GB2312-80是在國內計算機漢字信息技術發展初始階段制定的，其中包含了大部分常用的一、二級漢字，�9區的符號。該字符集是幾乎所有的中文系統和國際化的軟件都支持的中文字符集，這也是最基本的中文字符集。其編碼范圍是高�0xa1�0xfe，低位也� 0xa1-0xfe；漢字從 0xb0a1 開始，結束於 0xf7fe�
GBK是GB2312-80的擴展，是向上兼容的。它包含�20902個漢字，其編碼范圍是0x8140-0xfefe，剔除高�0x80的字位。其所有字符都可以一對一映射到Unicode2.0，也就是說JAVA實際上提供了GBK字符集的支持。這是現階段Windows和其它一些中文操作系統的缺省字符集，但並不是所有的國際化軟件都支持該字符集，感覺是他們並不完全知道GBK是怎麼回事�值得注意的是它不是國家標准，而只是規范。隨著GB18030-2000國標的發布，它將在不久的將來完成它的歷史使命�
GB18030-2000(GBK2K)在GBK的基礎上進一步擴展了漢字，增加了藏、蒙等少數民族的字形。GBK2K從根本上解決了字位不夠，字形不足的問題。它有幾個特點：
●它並沒有確定所有的字形，只是規定了編碼范圍，留待以後擴充�
●編碼是變長的，其二字節部分� GBK 兼容；四字節部分是擴充的字形、字位，其編碼范圍是首字節 0x81-0xfe、二字節0x30-0x39、三字節 0x81-0xfe、四字節0x30-0x39�
●它的推廣是分階段的，首先要求實現的是能夠完全映射到 Unicode 3.0 標准的所有字彀�
●它是國家標准，是強制性的�
現在還沒有任何一個操作系統或軟件實現� GBK2K 的支持，這是現階段和將來漢化的工作內容�
3.JSP/Servlet 漢字編碼問題及在 WAS 中的解決辦法
3.1 常見� encoding 問題的現�
網上常出現的 JSP/Servlet encoding 問題一般都表現� browser 或應用程序端，如:
●浏覽器中看到的 Jsp/Servlet 頁面中的漢字怎麼都成� �?� ?
●浏覽器中看到的 Servlet 頁面中的漢字怎麼都成了亂碼？
●JAVA 應用程序界面中的漢字怎麼都成了方塊？
●Jsp/Servlet 頁面無法顯示 GBK 漢字�
●Jsp/Servlet 不能接收 form 提交的漢字�
●JSP/Servlet 數據庫讀寫無法獲得正確的內容�
隱藏在這些問題後面的是各種錯誤的字符轉換和處理（除�3個外，是因為Javafont設置錯誤引起的）。解決類似的字符encoding問題，需要了� Jsp/Servlet 的運行過程，檢查可能出現問題的各個點�
3.2 JSP/Servlet web 編程時的 encoding 問題
運行於Java 應用服務器的 JSP/Servlet � Browser 提供 HTML 內容�
其中有字符編碼轉換的地方有：
a.JSP 編譯。Java 應用服務器將根據 JVM � file.encoding 值讀� JSP 源文件，並轉換為內部字符編碼進行 JSP 編譯，生� JAVA 源文件，根據file.encoding值寫回文件系統。如果當前系統語言支持GBK，那麼這時候不會出現encoding問題。如果是英文的系統，如LANG � en_US的Linux,AIX或Solaris，則要將JVM的file.encoding值置成GBK。系統語言如果是GB2312，則根據需要，確定要不要設置file.encoding，將 file.encoding 設為 GBK 可以解決潛在� GBK 字符亂碼問題
b.Java需要被編譯�.class才能在JVM中執行，這個過程存在與a.同樣的file.encoding問題。從這裡開始servlet和jsp的運行就�似了，只不� Servlet 的編譯不是自動進行的�
c.Servlet需要將HTML頁面內容轉換為browser可接受的encoding內容發送出去。依賴於各JAVAAppServer的實現方式，有的將查� Browser的accept-charset和accept-language參數或以其它猜的方式確定encoding值，有的則不管。因此constant-encoding也許是最好的解決方法。對於中文網頁，可在JSP或Servlet中設置contentType="text/html;charset=GB2312"；如果頁面中有GBK字符，則設置為contentType="text/html; charset=GBK"，由於IE � Netscape對GBK的支持程度不一樣，作這種設置時需要測試一下�
因為16位JAVAchar在網絡傳送時�8位會被丟棄，也為了確保Servlet頁面中的漢字（包括內嵌的和servlet運行過程中得到的）是期望的內碼，可以用PrintWriterout=res.getWriter()取代ServletOutputStreamout=res.getOutputStream(),PrinterWriter將根據contentType中指定的charset作轉�(ContentType需在此之前指定�);也可以用OutputStreamWriter封裝ServletOutputStream類並用write(String)輸出漢字字符串� 對於 JSP，JAVA Application Server 應當能夠確保在這個階段將嵌入的漢字正確傳送出去�
d.這是URL字符encoding問題。如果通過get/post方式從browser返回�值中包含漢字信息，servlet將無法得到正確的值。SUN� J2SDK 中，HttpUtils.parseName 在解析參數時根本沒有考慮 browser 的語言設置，而是將得到的值� byte 方式解析。這是網上討論得最多的 encoding問題。因為這是設計缺陷，只能以bin方式重新解析得到的字符串；或者以hackHttpUtils類的方式解決。參考文�2�3均有介紹，不過最好將其中的中� encoding GB2312� CP1381 都改� GBK，否則遇� GBK 漢字時，還是會有問題�
ServletAPI2.3提供一個新的函數HttpServeletRequest.setCharacterEncoding用於在調用request.getParameter(“param_name�) 前指定應用程序希望的 encoding，這將有助於徹底解決這個問題�
WebSphere Application Server 對標准的 Servlet API 2.x 作了擴展，提供較好的多語言支持。上述c,d情況，WAS 都要查詢 Browser 的語言設置，在缺省狀況下zh、zh-cn 等均被映射為 JAVA encoding CP1381（注意：CP1381 只是等同� GB2312 的一� codepage，沒� GBK 支持）。這樣做我想是因為無法確認 Browser 運行的操作系統是支持GB2312,
還是 GBK，所以取其小。但是實際的應用
系統還是要求頁面中出� GBK 漢字，最著名的是朱總理名字中的�?�(rong2 �0xe946，\u9555)，所以有時還是需要將 Encoding/Charset 指定� GBK。當� WAS 中變更缺省的 encoding 沒有上面說的那麼麻煩，針� a,b，參考文� 5 ），� Application Server 的命令行參數中指�-Dfile.encoding=GBK即可；針對d，在ApplicationServer的命令行參數中指�-Ddefault.client.encoding=GBK。如果指定了-Ddefault.client.encoding=GBK，那麼c情況下可以不再指定charset�
3.3 數據庫讀寫時� encoding 問題
JSP/Servlet 編程中經常出� encoding 問題的另一個地方是讀寫數據庫中的數據。流行的關系數據庫系統都支持數據� encoding，也就是說在創建數據庫時可以指定它自己的字符集設置，數據庫的數據以指定的編碼形式存儲。當應用程序訪問數據時，在入口和出口處都會有 encoding 轉換。對於中文數據，應當保證數據的完整性。GB2312，GBK，UTF-8 等都是可選的數據� encoding；如果選� ISO8859-1(8-bitSBCS)，那麼應用程序在寫數據之前須�16Bit的一個漢字或Unicode拆分成兩�8-bit的字符，讀數據之後則需將兩個字節合並起來，同時還有判別其中的
SBCS 字符。沒有充分利用數據庫 encoding 的作用，反而增加了編程的復雜度，ISO8859-1不是推薦的數�
� encoding。JSP/Servlet編程時，可以先用數據庫管理系統提供的功能檢查其中的中文數據是否正確�
然後應當注意的是讀出來的數據的 encoding，JAVA 程序中一般得到的� Unicode。寫數據時則相反�
3.4 定位問題時常用的技�
定位中文encoding問題通常采用最笨的也是最有效的辦法——在你認為有嫌疑的程序處理後打印字符串的內碼。通過打印字符串的內碼，你可以發現什麼時候中文字符被轉換成Unicode，什麼時候Unicode被轉回中文內碼，什麼時候一個中文字成了兩個Unicode字符，什麼時候中文字符串被轉成了一串問號，什麼時候中文字符串的高位被截掉了…�
取用合適的樣本字符串也有助於區分問題的類型。如：”aa啊aa?aa”等中英相間、GB、GBK特征字符均有的字符串。一般來說，英文字符無論怎麼轉換或處理，都不會失真（如果遇到了，可以嘗試著增加連續的英文字母長度）�
*****************************************
關於jsp亂碼問題的解決�
1 最基本的亂碼問題�
這個亂碼問題是最簡單的亂碼問題。一般新會出現。就是頁面編碼不一致導致的亂碼�
<%@ page language="java" pageEncoding="UTF-8"%>
<%@ page contentType="text/html;charset=iso8859-1"%>
