JSP中文亂碼問題大全，包括數據庫、各類類、Eclipse中、表頭等等。【部分轉】

 

JSP中文亂碼問題終極解決方案

在介紹方法以前咱們首先應該清楚具體的問題有哪些，筆者在本博客當中論述的JSP中文亂碼問題有以下幾個方面：頁面亂碼、參數亂碼、表單亂碼、源文件亂碼。下面來逐一解決其中的亂碼問題。

1、JSP頁面中文亂碼

在JSP頁面中，中文顯示亂碼有兩種狀況：一種是HTML中的中文亂碼，另外一種是在JSP中動態輸出的中文亂碼。

先看一個JSP程序：

 

上面這個JSP程序看起來好像是在頁面顯示幾句中文並且標題也是中文。運行後在瀏覽器中顯示如圖所示

緣由在於沒有在JSP中指定頁面顯示的編碼,消除亂碼的解決方案很簡單上面代碼中page命令修改爲以下所示便可

 

再次運行亂碼消失，原理就是向頁面指定編碼爲GB2312，那麼頁面就會按照此編碼來顯示，因而亂碼消失。

2、URL傳遞參數中文亂碼

通常狀況下在使用get方法提交表單的時候傳遞的參數若是是中文的話極可能會出現亂碼。

下面是一個示例程序

 

上面這個JSP程序的功能就是經過一個URL連接向自身傳遞一個參數，這個參數是中文字符串，這個程序的運行效果以下圖

對於URL傳遞中文參數亂碼這個問題，其處理方法比較特殊，僅僅轉換這個中文字符串或者設置JSP頁面顯示編碼都是不能解決問題的，須要修改Tomcat服務器的配置文件才能解決問題。在這裏修改Tomcat的conf目錄下的server.xml配置文件，具體改後的代碼以下

 

在原來代碼中添加URI編碼設置URIEncoding=「gb2312」便可，重啓Tomcat服務器能夠獲得正確的頁面。其原理也和上面的狀況相似，就是向程序指明編碼類型，而後顯示就正常了。

3、表單提交中文亂碼

對於表單的數據可使用request.getParameter（「」）的方法獲取，可是當表單中出現中文數據的時候就會出現亂碼。

示例代碼以下

 

在上面的表單當中想AcceptFormCharset這個頁面提價兩項數據，下面是AcceptFormCharset.jsp的內容：

 

在上面的程序中，若是表單輸入沒有中文，則能夠正常的顯示當輸入的數據中有中文的時候，獲得的結果如圖所示。

產生種結果的緣由是Tomcat中對於post方法提交的表單採用的默認編碼爲ISO-8859-1，而這種編碼格式不支持中文字符。對於這個問題能夠採用轉換編碼格式的方法來解決，如今對AcceptFromCharset這個頁面改動以下：

 

通過這樣的轉換編碼之後，全部的中文輸入均可以用request對象正常取出。在上面這個程序中，第四行和第五行是轉換編碼格式的關鍵，先從ISO-8859-1格式的字符串中取出字節內容，而後在用GB2312的編碼格式從新構造一個新的字符串。這樣就能夠支持中文變淡輸入的正常取值和顯示。改進之後程序運行結果以下

通過上面的更改編碼格式的處理，表單的中文輸入亂碼問題已經獲得解決。可是若是上面的表單中的輸入項不止是兩個，那麼每一個輸入項都須要進行編碼轉換，那樣就很麻煩了。這是咱們就用到了大名鼎鼎的過濾器filter了。關於這裏的內容大體的思慮和上面的同樣具體作法請參照筆者的另外一篇文章。

4、Eclipse中JSP文件中文亂碼

在Eclipse或者MyEclipse中因爲默認的JSP編碼格式爲ISO-8859-1，因此當打開由其餘編輯器編輯的JSP文件時會出現亂碼，如圖所示

對於這個問題咱們只須要更改一下Eclipse或者是MyEclipse中對JSP的默認編碼就能夠了，修改的地方（個人MyEclipse版本爲11）如圖所示

PS

在Eclipse或者MyEclipse當中JSP文件默認的編碼爲ISO-8859-1，因此在JSP代碼中間若是出現中文就不能保存，例如以下代碼

 

修改後在保存的時候會提示以下：

現這個提示的緣由在於JSP源文件中有ISO=8859-1編碼沒法識別的中文字符，對於這個問題，解決辦法就是在JSP頁面中聲明頁面編碼格式便可。聲明後代碼以下：

 

其中第一行中pageEncoding=「gb2312」指明瞭JSP頁面編碼採用GB2312，這樣就能夠正常保存JSP的源文件了。

遇到問題首先分析問題出現的緣由，只有知道了緣由才能去解決，學習分析問題的來源遠比解決這個問題重要的多。

亂碼問題的緣由就是程序（Eclipse也好，瀏覽器也罷）的編碼沒有和編程人員的編碼進行統一，（就像你和一個不懂中文的人用中文交流他固然不懂了）那麼解決這個問題只須要將編程人員想要的編碼告訴程序就能夠了，以上解決亂碼問題的種種方法均可以說是一種聲明編碼的過程，也就是說亂碼問題終極解決方案就是：轉碼。這裏的轉碼要麼是編程人員手動轉，要麼就是聲明一下讓程序去轉，換句話說就是：和不懂中文的交流，要麼讓他學中文，要麼你就去學習他的語言。

 

數據庫選擇什麼樣的編碼比較好。
目前流行的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來進行編碼，而再也不是用一個全局的參數來取全部的數據了。

不知道幫你解決問題了嗎？