首先說明我的特殊情況:
1. 前臺jsp中,我使用的是 form post 請求,設(shè)置了 enctype="multipart/form-data" ,頁面編碼格式都是utf-8
2. 后臺中,我使用的是commons-fileUpload組件,ServletFileUpload 解析form表單和文件,
3. 設(shè)置 request.setCharacterEncoding("UTF-8");
4. 設(shè)置了ServletFileUpload .setHeaderEncoding("UTF-8");
5.Tomcat 的配置下面 server.xml 也已經(jīng)設(shè)置了 URIEncoding="UTF-8";
至此,按道理所有的格式都匹配上了,前后對應(yīng),解析出來的肯定是utf-8,但是經(jīng)過formfield解析出來后任然是ISO-8859-1格式的編碼,
enctype="multipart/form-data" 會將數(shù)據(jù)以2進(jìn)制的編碼格式傳遞,因此我斷定是 ServletFileUpload 解析時(shí)出了問題,多番查找,
我的問題 缺少 了一步String formFieldValue = fileItem.getString("UTF-8");
JSP和Servlet的六種中文亂碼處理方法
一、表單提交時(shí)出現(xiàn)亂碼:
在進(jìn)行表單提交的時(shí)候,經(jīng)常提交一些中文,自然就避免不了出現(xiàn)中文亂碼的情況,對于表單來說有兩種提交方式:get和post提交方式。所以請求的時(shí)候便有g(shù)et請求和post請求。每種方式都有著不同的解決方法,之所以出現(xiàn)亂碼,原因就在于get請求時(shí),其傳遞給服務(wù)器的數(shù)據(jù)是附加在URL地址之后的;而post的請求時(shí),其傳遞給服務(wù)器的數(shù)據(jù)是作為請求體的一部分傳遞給服務(wù)器。這也就導(dǎo)致了對它們所產(chǎn)生的亂碼的處理方式是不同的。
1、客戶端的get請求
get提交時(shí), 容器以容器的編碼 來編碼 如果用的tomcat 默認(rèn)的編碼是iso-8859-1 在server.xml里面設(shè)置編碼 或者
下面代碼如
String name = request.getPara...("name");
String strName = new String(name.getByte("iso-8859-1"),"GBK");
對于不同的請求方式,解決亂碼的問題也是不一樣的,對于客戶端的get請求來說,服務(wù)器端處理要想不出現(xiàn)亂碼,解決這個(gè)問題稍微復(fù)雜一些,需要用到String類型的構(gòu)造函數(shù),其中的一個(gè)構(gòu)造函數(shù)就是用指定的編碼方式去解碼,一般都用“UTF-8”的方式。只要在服務(wù)器端將請求得到的參數(shù)重新構(gòu)造成一個(gè)字符串就行了。
經(jīng)過構(gòu)造之后,客戶端輸入中文,且表單時(shí)get請求的情況下,str就變成了中文了。
2、客戶端的post請求
對于客戶端的post請求來說,處理亂碼的問題就比較簡單了,因?yàn)檎埱蟮臄?shù)據(jù)時(shí)作為請求體的一部分傳遞給服務(wù)器的,所以只要修改請求內(nèi)的編碼就行了。只要在服務(wù)器端的最開始處將請求的數(shù)據(jù)設(shè)置為“UTF-8”就行了,輸入如下語句:request. setCharacterEncoding(“UTF-8”);這樣用戶在服務(wù)器端獲取到的中文數(shù)據(jù)就不再是亂碼了。
二、超鏈接時(shí)出現(xiàn)亂碼(低版本瀏覽器不行IE6)
在Web開發(fā)中,挺多的時(shí)候都是通過超鏈接去傳遞中文參數(shù)的,這也會導(dǎo)致在顯示的時(shí)候也會出現(xiàn)亂碼,對于超鏈接來說,它實(shí)際上是向服務(wù)器端發(fā)送了一個(gè)請求,而它發(fā)出的請求是屬于get請求,所以對于超鏈接的亂碼來說,它處理亂碼的方式和表單的get請求出現(xiàn)亂碼的方式是一樣的。
三、重定向時(shí)出現(xiàn)亂碼(低版本瀏覽器不行IE6)
有時(shí)寫上response的sendRedirect方法進(jìn)行重定向時(shí)也會出現(xiàn)亂碼,重定向時(shí)實(shí)際上也是向服務(wù)器發(fā)送了一個(gè)請求,所以解決亂碼的方法和和上面是一樣的。
四、瀏覽器版本低導(dǎo)致的亂碼
上網(wǎng)的時(shí)候,有時(shí)提交的一些信息在地址欄顯示的是“%2C%C6%CC%C6”的字樣,其實(shí)這都是防止出現(xiàn)亂碼進(jìn)行的解決方案,如果你的瀏覽器是IE6或以下版本,則我們的第二種情況和第三種情況會出現(xiàn)亂碼(尤其是當(dāng)中文是奇數(shù)的時(shí)候),這就不好使了所以我們必須采用另一種比較實(shí)際的作法:
在java.net包中提供了URLEncoder類和URLDcoder類,這兩個(gè)類又分別提供了encode和decode兩個(gè)靜態(tài)方法,分別用于進(jìn)行編碼和解碼。我們將要傳遞的中文參數(shù)進(jìn)行編碼之后,在傳遞給服務(wù)器,服務(wù)器解碼之后,就可以顯示中文了。
進(jìn)行編碼:URLEncoder.encode(stuname,”UTF-8”)
傳遞給服務(wù)器:a href=”/1.jsp?stuname%=stuname%>”>傳遞/a>
進(jìn)行解碼:URLDecoder.decode(stuname,”UTF-8”)
五、返回瀏覽器顯示的亂碼
在Servlet編程中,經(jīng)常需要通過response對象將一些信息返回給瀏覽器,給我們的客戶端,而我們在服務(wù)器端顯示的中文,但是響應(yīng)給客戶端瀏覽器卻是亂碼,這主要是由于response對象的getWriter()方法返回的PrintWriter對象默認(rèn)使用“ISO-8859-1”字符集編碼進(jìn)行Unicode字符串到字節(jié)數(shù)組的轉(zhuǎn)換,由于ISO8859-1字符集中根本就沒有包含中文字符,所以Java在進(jìn)行轉(zhuǎn)換的時(shí)候會將無效的字符編碼輸出給客戶端,于是便出現(xiàn)了亂碼,為此ServletResponse接口中便定義了setCharacterEncoding、setContentType等方法來指定getWriter方法返回的PrintWriter對象所使用的字符集編碼,所以我們在寫Servlet程序中,在調(diào)用getWriter方法之前設(shè)置這些方法的值。
只要編寫Servlet文件中含有響應(yīng)給客戶端的信息,那么就要寫上這兩句話。最好寫上第二句話,因?yàn)樗膬?yōu)先級高,它的設(shè)置結(jié)果將覆蓋setContentType等方法設(shè)置的字符編碼集。
六、修改Tomcat的編碼
在get請求所導(dǎo)致亂碼問題中,還有一種解決的方案,我們常用Tomcat作為運(yùn)行Servlet和JSP的容器,而Tomcat內(nèi)部默認(rèn)的編碼是ISO-8859-1,所以對于get請求方式,其傳遞的數(shù)據(jù)(URI)會附加在訪問的資源后面,其編碼是Tomcat默認(rèn)的,如果修改該URI的編碼,那么對于所有的get請求方式便不會出現(xiàn)亂碼了包括上邊說的重定向和超鏈接,在Tomcat的配置文件server.xml中找到修改Tomcat的端口的地方,在其內(nèi)部加入U(xiǎn)RIEncoding屬性,設(shè)置為和你的項(xiàng)目中所設(shè)的編碼一樣的值,這里全部都是UTF-8。
在編寫Servlet和JSP的時(shí)候,為了避免出現(xiàn)亂碼,最重要的就是:采用一致的編碼,如果編碼都一致了,肯定不會出現(xiàn)亂碼。
以上這篇解決中文亂碼的幾種解決方法(推薦)就是小編分享給大家的全部內(nèi)容了,希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
您可能感興趣的文章:- jquery中文亂碼的多種解決方法
- ajax中文亂碼的各種解決辦法總結(jié)