jsp亂碼解決大全

笨笨鼠→_→發表於2012-07-06
JS


一、JSP頁面顯示亂碼

二、表單提交中文時出現亂碼

三、資料庫連線


大家在JSP的開發過程中，經常出現中文亂碼的問題，可能一至困擾著您，我現在把我在JSP開發中遇到的中文亂碼的問題及解決辦法寫出來供大家參考。


一、JSP頁面顯示亂碼
下面的顯示頁面(display.jsp)就出現亂碼：
<html>
<head>
<title>JSP的中文處理</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>

<body>
<%
out.print("JSP的中文處理");
%>
</body>
</html>
對不同的WEB伺服器和不同的JDK版本，處理結果就不一樣。原因：伺服器使用的編碼方式不同和瀏覽器對不同的字元顯示結果不同而導致的。解決辦法：在JSP頁面中指定編碼方式(gb2312),即在頁面的第一行加上：<%@ page contentType="text/html; charset=gb2312"%>，就可以消除亂碼了。完整頁面如下

：
<%@ page contentType="text/html; charset=gb2312"%>
<html>
<head>
<title>JSP的中文處理</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>

<body>
<%
out.print("JSP的中文處理");
%>
</body>
</html>


二、表單提交中文時出現亂碼
下面是一個提交頁面(submit.jsp)，程式碼如下：
<html>
<head>
<title>JSP的中文處理</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>

<body>
<form name="form1" method="post" action="process.jsp">
<div align="center">
<input type="text" name="name">
<input type="submit" name="Submit" value="Submit">
</div>
</form>
</body>
</html>
下面是處理頁面(process.jsp)程式碼：
<%@ page contentType="text/html; charset=gb2312"%>
<html>
<head>
<title>JSP的中文處理</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>

<body>
<%=request.getParameter("name")%>
</body>
</html>
如果submit.jsp提交英文字元能正確顯示，如果提交中文時就會出現亂碼。原因：瀏覽器預設使用UTF-8編碼方式來傳送請求，而UTF- 8和GB2312編碼方式表示字元時不一樣，這樣就出現了不能識別字元。

解決辦法:通過request.seCharacterEncoding ("gb2312")對請求進行統一編碼，就實現了中文的正常顯示。修改後的process.jsp程式碼如下：

<%@ page contentType="text/html; charset=gb2312"%>
<%
request.seCharacterEncoding("gb2312");
%>
<html>
<head>
<title>JSP的中文處理</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
</head>

<body>
<%=request.getParameter("name")%>
</body>
</html>


三、資料庫連線出現亂碼
只要涉及中文的地方全部是亂碼，解決辦法：在資料庫的資料庫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()來轉換編碼。



如果你還有什麼不懂之處：我給大家推薦一個好的JSP-JAVA網站：

http://www.phy.hbnu.edu.cn/dsp/

總結：

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中一樣的，但是在servlet java檔案中構造的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" import="java.sql.*"errorPage="err.jsp" %> 


/////////////////////////////////////////////////////////////////////////////////////////
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 的字位。其所有字元都可以一對一對映到 Unicode 2.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個外，是因為 Java font 設定錯誤引起的）。解決類似的字元 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 內容傳送出去。依賴於各JAVA App Server 的實現方式，有的將查詢 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位 JAVA char在網路傳送時高8位會被丟棄，也為了確保Servlet頁面中的漢字（包括內嵌的和servlet執行過程中得到的）是期望的內碼，可以用 PrintWriter ōut=res.getWriter() 取代ServletOutputStream ōut=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 方式重新解析得到的字串；或者以 hack HttpUtils 類的方式解決。參考文章 2、3 均有介紹，不過最好將其中的中文 encoding GB2312、 CP1381 都改為 GBK，否則遇到 GBK 漢字時，還是會有問題。

　　Servlet API 2.3 提供一個新的函式 HttpServeletRequest.setCharacterEncoding 用於在呼叫request.getParameter(“param_name”) 前指定應用程式希望的 encoding，這將有助於徹底解決這個問題。

　　WebSphere Application Server 對標準的 Servlet API 2.x 作了擴充套件，提供較好的多語言支援。上述c,d情況，WAS 都要查詢 Browser 的語言設定，在預設狀況下zh、zh-cn 等均被對映為 JAVAencoding 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，在 Application Server 的命令列引數中指定-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-bit SBCS)，那麼應用程式在寫資料之前須將 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特徵字元均有的字串。一般來說，英文字元無論怎麼轉換或處理，都不會失真（如果遇到了，可以嘗試著增加連續的英文字母長度）。

4.結束語
　　其實 JSP/Servlet 的中文encoding 並沒有想像的那麼複雜，雖然定位和解決問題沒有定規，各種執行環境也各不盡然，但後面的原理是一樣的。瞭解字符集的知識是解決字元問題的基礎。不過，隨著中文字符集的變化，不僅僅是 java 程式設計，中文資訊處理中的問題還是會存在一段時間的。

5.參考文章
1) Character Problem Review
2) Java 程式設計技術中漢字問題的分析及解決
3) NLS Characters in WebSphere: SBCS/DBCS display on same page
4) GB18030
5) Setting language encoding in web applications: Websphere applications Server

　/////////////////////////////////////////////////////////////////////////////////////　 


關於jsp亂碼問題的解決。

1 最基本的亂碼問題。

這個亂碼問題是最簡單的亂碼問題。一般新會出現。就是頁面編碼不一致導致的亂碼。

<%@ page language="java" pageEncoding="UTF-8"%>

<%@ page contentType="text/html;charset=iso8859-1"%>

<html>

<head>

<title>中文問題</title>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

</head>

</head>

<body>

  我是個好人

</body>

</html>


三個地方的亂碼處理

第一個地方的編碼格式為jsp檔案的儲存格式。Eclipse會根據這個編碼格式儲存檔案。並編譯jsp檔案，包括裡面的漢字。

第二處編碼為解碼格式。因為存為UTF-8的檔案被解碼為iso8859-1，這樣 如有中文肯定出亂碼。也就是必須一致。而第二處所在的這一行，可以沒有。預設也是使用iso8859-1的編碼格式。所以如果沒有這一行的話，“我是個好人”也會出現亂碼。必須一致才可以。

  第三處編碼為控制瀏覽器的解碼方式。如果前面的解碼都一致並且無誤的話，這個編碼格式沒有關係。有的網頁出現亂碼，就是因為瀏覽器不能確定使用哪種編碼格式。因為頁面有時候會嵌入頁面，導致瀏覽器混淆了編碼格式。出現了亂碼。

2 表單使用Post方式提交後接收到的亂碼問題

這個問題也是一個常見的問題。這個亂碼也是tomcat的內部編碼格式iso8859-1在搗亂，也就是說post提交時，如果沒有設定提交的編碼格式，則會以iso8859-1方式進行提交，接受的jsp卻以utf-8的方式接受。導致亂碼。既然這樣的原因，下面有幾種解決方式，並比較。

A 接受引數時進行編碼轉換String str = new String(request.getParameter("something").getBytes("ISO-8859-1"),"utf-8")； 這樣的話，每一個引數都必須這樣進行轉碼。很麻煩。但確實可以拿到漢字。

B 在請求頁面上開始處，執行請求的編碼程式碼， request.setCharacterEncoding("UTF-8")，把提交內容的字符集設為UTF－8。這樣的話，接受此引數的頁面就不必在轉碼了。直接使用String str = request.getParameter("something")；即可得到漢字引數。但每頁都需要執行這句話。

這個方法也就對post提交的有效果，對於get提交和上傳檔案時的enctype="multipart/form-data"是無效的。稍後下面單獨對這個兩個的亂碼情況再進行說明。

C 為了避免每頁都要寫request.setCharacterEncoding("UTF-8")，建議使用過濾器對所有jsp  進行編碼處理。這個網上有很多例子。請大家自己查閱。

3 表單get提交方式的亂碼處理方式。

如果使用get方式提交中文，接受引數的頁面也會出現亂碼，這個亂碼的原因也是tomcat的內部編碼格式iso8859-1導致。Tomcat會以get的預設編碼方式iso8859-1對漢字進行編碼，編碼後追加到url，導致接受頁面得到的引數為亂碼/、。

解決辦法：

A 使用上例中的第一種方式，對接受到的字元進行解碼，再轉碼。

B Get走的是url提交，而在進入url之前已經進行了iso8859-1的編碼處理。要想影響這個編碼則需要在server.xml的Connector節點增加useBodyEncodingForURI="true"

屬性配置，即可控制tomcat對get方式的漢字編碼方式，上面這個屬性控制get提交也是用request.setCharacterEncoding("UTF-8")所設定的編碼格式進行編碼。所以自動編碼為utf-8，接受頁面正常接受就可以了。但我認為真正的編碼過程是，tomcat又要根據

<Connector port="8080"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" redirectPort="8443" acceptCount="100"

debug="0" connectionTimeout="20000" useBodyEncodingForURI="true"

disableUploadTimeout="true" URIEncoding=”UTF-8”/>

裡面所設定的URIEncoding=”UTF-8”再進行一次編碼，但是由於已經編碼為utf-8，再編碼也不會有變化了。如果是從url獲取編碼，接受頁面則是根據URIEncoding=”UTF-8”來進行解碼的。

4 上傳檔案時的亂碼解決

  上傳檔案時，form表單設定的都是enctype="multipart/form-data"。這種方式以流方式提交檔案。如果使用apach的上傳元件，會發現有很多亂碼想象。這是因為apach的先期commons-fileupload.jar有bug，取出漢字後進行解碼，因為這種方式提交，編碼又自動使用的是tomcat預設編碼格式iso-8859-1。但出現的亂碼問題是： 句號，逗號，等特殊符號變成了亂碼，漢字如果數量為奇數，則會出現亂碼，偶數則解析正常。

    解決方式： 下載commons-fileupload-1.1.1.jar 這個版本的jar已經解決了這些bug。

但是取出內容時仍然需要對取出的字元進行從iso8859-1到utf-8轉碼。已經能得到正常所有漢字以及字元。

5 Java程式碼關於url請求，接受引數的亂碼

url的編碼格式，取決於上面所說的URIEncoding=”UTF-8”。 如果設定了這個編碼格式，則意味著所有到url的漢字引數，都必須進行編碼才可以。否則得到的漢字引數值都是亂碼，例如一個連結 Response.sendDerect（“/a.jsp?name=張大維”）；而在a.jsp裡面直接使用String name"）；得到的就是亂碼。因為規定了必須是utf-8才可以，所以，這個轉向應該這樣寫：    Response.sendDerect（“/a.jsp?name=URLEncode.encode(“張大維”,”utf-8”)；才可以。

如果不設定這個引數URIEncoding=”UTF-8”， 會怎麼樣呢? 不設定則就使用了預設的編碼格式iso8859-1。問題又出來了，第一就是引數值的個數如果是奇數個數，則就可以正常解析，如果使偶數個數，得到最後字元就是亂碼。還有就是如果最後一個字元如果是英文，則就能正常解析，但中文的標點符號仍出現亂碼。權宜之計，如果您的引數中沒有中文標點符號，則可以在引數值最後加一個英文符號來解決亂碼問題，得到引數後再去掉這個最後面的符號。也可以湊或使用。

6 指令碼程式碼關於url請求，接受到的引數亂碼

指令碼中也會進行頁面轉向的控制，也會涉及到附帶引數，並在接受頁面解析這個引數的情況。如果這個漢字引數不進行URIEncoding=”UTF-8”所指定的編碼處理，則接受頁面接受到的漢字也是亂碼。指令碼處理編碼比較麻煩，必須有相應的編碼指令碼對應檔案，然後呼叫指令碼中的方法對漢字進行編碼即可。

7 關於jsp在MyEclipse中開啟的亂碼問題

對於一個已經存在的專案，Jsp檔案的儲存格式可能是utf-8。如果新安裝的eclipse，則預設開啟使用的編碼格式都是iso8859-1。所以導致jsp裡面的漢字出現亂碼。這個亂碼比較容易解決，直接到eclipse3.1的偏好設定裡面找到general-〉edidor，設定為您的檔案開啟編碼為utf-8即可。Eclipse會自動重新以新的編碼格式開啟。漢字即可正常顯示。

8 關於html頁面在eclipse中開啟出現亂碼情況

由於大部分頁面都是由dreamweaver製作，其儲存格式跟eclipse的識別有差別導致。一般這種情況，在eclipse中新建一個jsp，直接從dreamweaver複製頁面內容貼上到jsp即可。


//////////////////////////////////////////////////////////////////////////////////////////
jsp中文亂碼問題的解決辦法 jsp中java中文編碼問題的個人經驗|終於看到一個完全解決的方案

開發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，分析一下你的”亂碼”到底是什麼編碼。這個其實不難，比如
System.out.println(testString);
這一段出現了亂碼，那麼不妨用窮舉法猜測一下它的實際編碼格式。
System.out.println(new String(testString.getBytes(”ISO-8859-1〃),”gb2312〃));
System.out.println(new String(testString.getBytes(”UTF8〃),”gb2312〃));
System.out.println(new String(testString.getBytes(”GB2312〃),”gb2312〃));
System.out.println(new String(testString.getBytes(”GBK”),”gb2312〃));
System.out.println(new String(testString.getBytes(”BIG5〃),”gb2312〃));
等等，上述程式碼的意思是用制定的編碼格式去讀取testString這個”亂碼”，並轉換成gb2312（此處僅以中文為例）然後你看哪一個轉換出來的結果是ok的，那就。。。

b，如果用上面的步驟能得到正確的中文，說明你的資料肯定是在的，只不過是介面中沒有正確顯示而已。那麼第二步就該糾正你的view部分了，通常需要檢查的是jsp中是否選擇了正確的頁面編碼。

在此要宣告被很多人誤解的一點，那就是<%@ page contentType=”text/html; charset=GB2312〃 %>指令和<META http-equiv=Content-Typecontent=”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的characterset，每個table,column都可以指定編碼，不指定就是ISO8895_1，因此jdbc取出資料後會根據column的character set來進行編碼，而不再是用一個全域性的引數來取所有的資料了。

這從另一個方面也說明了亂碼問題的產生實在是很複雜的事情，原因太多了。我也只是針對自己遇


////////////////////////////////////////////////////////////////////////////////////////

jsp中文問題解決之道

和Java一樣，JSP是目前比較熱門的一個話題。它是一種在伺服器端編譯執行的Web設計語言，因為指令碼語言採用了Java，所以JSP繼承了Java的所有優點。可是在使用JSP程式的過程中，常遇到中文亂碼問題，很多人為此頭疼不已，初學的時候我就深受其害，而且使用平臺不同，中文亂碼問題的解決方法也不同，無形中增加了學習JSP的難度。其實，在徹底瞭解相關原因後，問題還是比較容易解決的。，以下是我總結的解決方法，相信對讀者會有一定的借鑑意義。  (因為我使用得最多的是Tomcat環境，所以主要是以Tomcat為例，其它的環境只會提及一下，但解決辦法也是差不多的!

每個國家（或區域）都規定了計算機資訊交換用的字元編碼集，如美國的擴充套件ASCII碼、中國的GB2312-80、日本的  JIS  等，作為該國家(區域)資訊處理的基礎，有著統一編碼的重要作用。由於各本地字符集程式碼範圍重疊，相互間資訊交換困難，軟體本地化版本獨立維護成本較高。因此有必要將本地化工作中的共性抽取出來，做一致性處理，將特殊的本地化處理內容降低到最少，這就是所謂的國際化（I18N）。各種語言資訊被規範為本地資訊，而底層字符集採用包含了所有字元的Unicode。 

相信瞭解JSP程式碼的讀者對ISO8859-1一定不陌生，ISO8859-1是我們平時使用比較多的一個CodePage，它屬於西歐語系。GB2312-80  是在國內計算機漢字資訊科技發展初始階段制訂的，其中包含了大部分常用的一、二級漢字和9區的符號。該字符集是幾乎所有的中文系統和國際化的軟體都支援的中文字符集，這也是最基本的中文字符集。 

GBK  是  GB2312-80  的擴充套件，是向上相容的。它包含了20902個漢字，其編碼範圍是  0x8140～0xFEFE，剔除高位  0x80  的字位，其所有字元都可以一對一對映到  Unicode  2.0，也就是說  Java 實際上提供了對  GBK  字符集的支援。 >GB18030-2000(GBK2K)  在  GBK  的基礎上進一步擴充套件了漢字，增加了藏、蒙等少數民族的文字。GBK2K  從根本上解決了字位不夠、字形不足的問題。  

1．Tomcat  4開發平臺 
這個版本應該是我們經常用到的版本，所以討論得會比較詳細。Windows  98／2000下的Tomcat  4以上版本都會出現中文問題（而在Linux下和Tomcat  3.x中則沒有問題），主要表現是頁面顯示亂碼。為解決這個問題，最簡單的方法就是在每個JSP的頁面開始處加上<%@  page  language=“Java” contentType=“text/html;  charset=gb2312”%>。不過，這還不夠，雖然這時顯示了中文，但是發現從資料庫讀出的欄位變成了亂碼。經過分析發現:  在資料庫中儲存的中文字元是正常的，資料庫用ISO8859-1字符集存取資料，而Java程式在處理字元時預設採用統一的ISO8859-1字符集(這也體現了Java國際化思想)，所以在資料新增的時候Java和資料庫都是以ISO8859-1方式處理，這樣不會出錯。但

是在讀取資料的時候就出現問題了，因為資料讀出也採用ISO8859-1字符集，而  JSP的檔案頭中有語句<%@  page  language=“Java”  contentType=“text/html; charset=gb2312”%>，這說明頁面採用GB2312的字符集顯示，這樣就和讀出的資料不一樣。這時頁面顯示從資料庫中讀出的字元是亂碼，解決的方法是對這些字元轉碼，從ISO8859-1轉成GB2312，就可以正常顯示了。這個解決辦法對很多平臺具有通用性，讀者可以靈活運用。具體的方法會在以下詳細講解。另外，對於不同的資料庫如SQL 

Server，Oracle，Mysql，Sybase等，字符集的選擇很重要。如果考慮多語言版本，資料庫的字符集就應該統一採用ISO8859-1，需要輸出的時候在不同的字符集之間做轉換就可以了。  

以下是針對不同平臺的總結： 
(1)  JSWDK只適合於普通開發，穩定性和其他問題可能不如商業軟體。  由於JDK  1.3版效能要好於JDK  1.2.2很多，並且對中文的支援也較好，所以應該儘量採用。  現在jdk已經出到1.4版本了，所以如果允許最好升級到最新的版本，這樣對中文的也會較好，而且還可以得到更多的支援。  

(2)  Tomcat僅僅是一個對JSP  1.1、Servlet  2.2標準的實現,  我們不應該要求這個免費軟體在細節和效能上都面面俱到,  它主要考慮英文使用者,  這也是為什麼不做特殊轉換，漢字用URL方法傳遞就有問題的原因。大部分IE瀏覽器預設始終以UTF-8傳送,  這似乎是Tomcat的一個不足,  另外Tomcat不管當前的作業系統是什麼語言,  都按ISO8859去編譯JSP,  似乎也欠妥。  

2.JSP程式碼的中文處理
(1)如果與資料無關的操作，可以在頁面首行加入
(2)將Form中的值傳送到資料庫中再取出來後全變成了“？”。Form用POST提交資料，程式碼中使用了語句：

String  st=new(request.getParameter(“name”).getBytes(“ISO8859_1”))，  而且也宣告瞭

charset=gb2312。 

要處理Form中傳遞的中文引數，應該在JSP中加入下面的程式碼，另外定義一個專門解決這個問題的getStr類，然後對接收到的引數進行轉換：  

String  keyword1=request.getParameter(“keyword1”); 
keyword1=getStr(keyword1); 
這樣就可以解決問題了，程式碼如下： 
<%@  page  contentType=“text/html;charset=gb2312”%> 
<%! 
public  String  getStr(String  str){ 
try{String  temp_p=str; 
byte[]  temp_t=temp_p.getBytes(“ISO8859-1”); 
String  temp=new  String(temp_t); 
return  temp; 
} 
catch(Exception  e){  } 
return  “NULL”; 
} 
%> 
<%--http://www.cndes.com測試--%> 
<%  String  keyword=“創聯網路技術中心歡迎您的到來”; 
String  keyword1=request.getParameter(“keyword1”); 
keyword1=getStr(keyword1); 
out.print(keyword); 
out.print(keyword1); 
%> 
另外，流行的關聯式資料庫系統都支援資料庫Encoding，也就是說在建立資料庫時可以指定它自己的字符集設定，資料庫的資料以指定的編碼形式儲存。當應用程式訪問資料時，在入口和出口處都會有 Encoding  轉換。對於中文資料，資料庫字元編碼的設定應當保證資料的完整性。  GB2312、GBK、UTF-8  等都是可選的資料庫  Encoding，也可以選擇  ISO8859-1  (8-bit)，  但會增加了程式設計的複雜度，ISO8859-1不是推薦的資料庫  Encoding。在JSP/Servlet程式設計時，可以先用資料庫管理系統提供的管理功能檢查其中的中文資料是否正確。 

(3)JDBC  Driver的字元轉換 
目前大多數JDBC  Driver採用本地編碼格式來傳輸中文字元，例如中文字元“0x4175”會被轉成“0x41”和“0x75”進行傳輸。因此需要對JDBC  Driver返回的字元以及要發給JDBC  Driver的字元進行轉換。當用JDBC  Driver向資料庫中插入資料時，需要先將Unicode轉成Native  code;  當  JDBC  Driver從資料庫中查詢資料時，則需要將Native  code轉換成Unicode。下面給出了這兩種轉換的實現:  

String  native2Unicode(String  s)  { 
if  (s  ==  null  ||  s.length()  ==  0)  { 
return  null; 
} 
byte[]  buffer  =  new  byte[s.length()]; 
for  (int  i  =  0;  i  s.length();  i++)  {  if  (s.charAt(i)>=  0x100)  { 
c  =  s.charAt(i); 
byte  []buf  =  (“”+c).getBytes(); 
buffer[j++]  =  (char)buf[0]; 
buffer[j++]  =  (char)buf[1]; 
} 
else  {buffer[j++]  =  s.charAt(i);} 
} 
return  new  String(buffer,  0,  j); 
} 
要注意的是，有些JDBC  Driver如果通過JDBC  Driver  Manager設定了正確的字符集屬性，以上方法就不需要了。具體情況可參考相關JDBC的資料。  

其實理解了，中文亂碼就這麼一回事!反覆使用就會摸出一定的門道了!我覺得以上的三種方法，只要你真的能弄懂，在遇到中文問題時，在這三種方法多試嘗，我保證你不再會使這種中文問題所煩!

以上只是自己的一些經驗所談，如果有什麼不對，希望能提出，共同學習!  


//////////////////////////////////////////////////////////////////////////////////////////

  我的亂碼之路——JSP與MySQL互動的中文亂碼解決方案及總結 

     首先實現了一個StringConvert bean（GBtoISO()和ISOtoGB()兩個方法），解決了與MySQL資料庫互動的時候的部分中文亂碼問題：在JSP程式中讀取MySQL的中文內容，用這兩個方。

    但是從JSP寫入到MySQL的中文內容都成了亂碼，並且再讀出來的時候也顯示為“？？”，在這裡應該出現了編碼轉換過程中的字元資訊丟失。鬱悶的是，我在命令列視窗中登陸到MySQL後，執行如“INSERT INTO customerVALUES('字元',...)”這樣的語句時，寫入到資料表中的中文內容又是顯示正常的！！！資料庫使用的字符集是utf8。

         碰壁多次，終於發現一條解決問題的路徑：檢視MySQL手冊的時候，看到一條這樣的語句：

Toallow multiple character sets to be sent from the client, the "UTF-8"encoding should be

used, either by configuring "utf8" as the defaultserver character set, or by configuring

the JDBC driver to use "UTF-8"through the characterEncoding property.

    

     此外，在查閱《MySQL權威指南》時，發現在查詢語句中可以使用這樣的語法將字串轉換到一個給定的字符集：_charset str。

     其中charset必須是伺服器支援的某個字符集。在本例中，shopdb資料庫使用的預設字符集是utf8，於是開始測試：

     先輸入INSERT INTO　publish Values('8',_gb2312 '高等教育出版社')  寫入後中文變成“？？”

     再試INSERT INTO　publish Values('8',_gbk '高等教育出版社') 結果同上     INSERT INTO　publish Values('8',_utf8 '高等教育出版社') 這下更乾脆，什麼都沒有！！

         　　快瘋了!!沒辦法，用show character set;命令檢視MySQL支援的字符集，心想我都試一遍總有一個能成功吧。瀏覽了一下，發現沒有幾個熟悉的字符集，就只剩下一個latin1(ISO-8859-1)比較常見了，不會是它吧，一試之下果然便是。

     INSERT INTO　publish Values('8',_latin1 '高等教育出版社') 輸入中文能夠正確顯示。

         　　這下總算找到方法了，把Tomcat下配置的資料庫連線池的url改為＂...characterEncoding=UTF-8＂，然後把寫入資料庫的中文內容用

     String s2 = new String(s1.getBytes("gb2312"),"ISO-8859-1")進行轉碼，其中s1為中文字串．然後再寫入到資料庫一切顯示正常。

         　　為解決這個問題檢視了n多資料，現作一個總結：由於字符集和字元編碼方式的不同，在OS以及程式之間傳遞資料（尤其是multiple character sets中的資料）時便會產生亂碼以及字元資訊的丟失．解決這個問題的關鍵便是瞭解資料輸出端和接收端使用的字符集和字元編碼方式，如果這兩種編碼方式不同，便需要在資料出口或入口處進行 轉碼。一般的說，在編寫程式碼,編譯，以及執行期間都會字元資料的傳遞，因此需要特別小心。

      在編寫程式碼的時候，你可能會使用某種開發工具，例如我正在使用的Eclipse．或許在寫的時候一切正常，可是一旦儲存後再次開啟文件，所有的中文字元都變成了亂碼。這是因為在編寫的時候，這些字元資料都在記憶體的某個stream中，ok，這沒問題，可是儲存的時候這個stream中的資料會被寫入到硬碟，使用的就是你的開發工具預設的編碼方式，如果很不幸你的開發工具預設編碼方式是ISO-8859-1，中文字元資訊就不能正確地儲存。Eclipse中可以這樣檢視並修改預設字元編碼方式：Project->Properties->info，這裡有＂default encoding for text file＂。如果設定為GBK，那麼編寫程式碼並儲存這關就過了。

     　對於JSP程式而言，編寫完程式碼後就交給Container，首先它們會被轉成.java檔案，然後編譯成.class才能提交給伺服器執行．這個過程也存在字元編碼問題．java編譯器(javac)使用作業系統的語言環境作為預設的字元編碼方式，JRE(Java Runtime Environment)也是這樣。只有當編譯和執行環境的字元編碼方式與儲存原始檔的編碼方式相同時，中文字元才能正確地顯示。否則就需要在執行時進行轉碼，使它們使用相容的編碼。這裡的設定可以分為幾個層次：作業系統層支援的語言，這是最重要的，因為它會影響ＪＶＭ的預設字元編碼方式，同時對字元的顯示，如字型等有直接影響；J2EE伺服器層，大多數伺服器都可以對字元編碼進行自定義的配置，例如Tomcat就可以通過web.xml中設定javaEncoding引數設定字元編碼，預設是UTF-8．

     IE也可以設定成總是使用UTF-8編碼來傳送請求．應用程式層，每個配置在伺服器下的程式都可以設定自己的編碼方式，這個我目前還沒有用到，以後再學習。

     執行時的轉碼，執行時期，應用程式很可能需要與外部系統進行互動，例如對資料庫進行讀寫，對外部檔案進行讀寫．在這些情況下，應用程式免不了要和外部系統進行資料交換。那麼對於中文字元， 資料出入口的編碼方式就顯得特別重要了。一般外部系統都有自己的字元編碼方式，我的例子中配置的MySQL就是使用的UTF-8編碼。JSP頁面通過設定＂charset=gb2312＂,    使用gb2312編碼，在它與資料庫互動的時候就需要進行顯式的轉碼才能正確處理中文字元。


相關文章