天天看點
傳回

JSP編碼問題：pageEncoding、contentType、charset、setCharacterEncoding和setContentType

在開始本篇介紹之前，先回顧一下兩個模闆：

【一個JSP檔案模闆】

<%@ page language="java"contentType="text/html; charset=utf-8" pageEncoding="utf-8"%> 
<!DOCTYPE html PUBLIC "-//W3C//DTDHTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<metahttp-equiv="Content-Type" content="text/html;charset=utf-8">
<title>Insert titlehere</title>
</head>
<body>
        
</body>
</html>

【一個HTML模闆】

<!DOCTYPE html>
<html>
<head>
         <meta charset="utf-8">
         <title></title>
</head>
<body>
 
</body>
</html>

JSP中pageEncoding和charset的差別

  • pageEncoding是jsp頁面檔案本身的編碼格式，跟頁面顯示的編碼沒有關系
  • contentType的charset是指伺服器發送給用戶端時的内容編碼

如果pageEncoding屬性存在，那麼JSP頁面的字元編碼方式就由pageEncoding決定，否則就由contentType屬性中的charset決定，如果charset也不存在，JSP頁面的字元編碼方式就采用預設的ISO-8859-1。

  • pageEncoding：設定JSP源檔案和響應正文中的字元集編碼。隻适用于jsp輸出時的編碼，不會作為header發出去的；是告訴web Server該jsp頁面按照什麼編碼輸出，即web伺服器輸出的響應流的編碼。
  • contentType：設定JSP源檔案和響應正文的字元集編碼及MIME類型。MIME類型的預設值是“text/html”。

可見，pageEncoding和contentType都可以設定JSP源檔案和響應正文中的字元集編碼。但也有差別：

  • 設定JSP源檔案字元集時，優先級為pageEncoding>contentType。如果都沒有設定，預設ISO-8859-1。
  • 設定響應輸出的字元集時，優先級為contentType>pageEncoding。如果都沒有設定，預設ISO-8859-1。

例如：pageEncoding="GBK"。這句話的意思是，告訴JVM 這個jsp本身采用的"GBK"編碼，在JSP編譯成Servlet傳給JVM的時候，就用“GBK”的編碼方式将Jsp網頁源檔案翻譯成統一的UTF-8形式的Java位元組碼。如果不加設定，則JVM預設的用ISO-8859-1這種編碼方式。contentType裡的charset="gbk"，指的是此網頁檔案輸出到浏覽器的輸出方式為gbk。在這個過程中，一個JSP的源檔案需要經過三個階段，兩次編碼，才能完成一次完整的輸出。

三個階段，兩次編碼

JSP要經過三個階段和兩次的“編碼”，第一階段會用pageEncoding到utf-8；第二階段會用utf-8至utf-8；第三階段就是由Tomcat出來的網頁，用的是從utf-8到contentType。

第一階段是jsp編譯成.java。它會根據pageEncoding的設定讀取jsp，結果是由指定的編碼方案翻譯成統一的UTF-8 JAVA源碼（即.java），如果pageEncoding設定錯了，或沒有設定，出來的就可能是中文亂碼。

第二階段是由JAVAC的JAVA源碼至javabyteCode（即java位元組碼）的編譯。不論JSP編寫時候用的是什麼編碼方案，經過這個階段的結果全部是UTF-8的encoding的java位元組碼。JAVAC用UTF-8的encoding讀取java源碼，編譯成UTF-8 encoding的二進制碼（即.class），這是JVM對常數字串在二進制碼（java encoding）内表達的規範。

第三階段是Tomcat（或其的applicationcontainer）載入和執行階段二的來的JAVA二進制碼，輸出的結果，也就是在用戶端見到的，這時隐藏在階段一和階段二的參數contentType就發揮了功效。

contentType

pageEncoding 和contentType的預設都是 ISO8859-1。而随便設定了其中一個，另一個就跟着一樣了(TOMCAT 4.1.27是如此)。但這不是絕對的，這要看各自JSPC的處理方式。pageEncoding不等于contentType，更有利亞洲區的文字 CJKV系JSP網頁的開發和展示， (例pageEncoding=GB2312 不等于 contentType=utf-8)。

jsp 檔案不像.java，.java在被編譯器讀入的時候預設采用的是作業系統所設定的locale所對應的編碼，比如中國大陸就是GBK，台灣就是BIG5 或者MS950。而一般我們不管是在記事本還是在ue中寫代碼，如果沒有經過特别轉碼的話，寫出來的都是本地編碼格式的内容。是以編譯器采用的方法剛好可以讓虛拟機得到正确的資料。但是，jsp檔案不是這樣，它沒有這個預設轉碼過程，但是指定了pageEncoding就可以實作正确轉碼了。

舉個例子：

大都會列印出亂碼，因為我輸入的“你好嗎”是gbk的，但是伺服器是否正确抓到“你好嗎”不得而知。

但是如果更改為：

這樣就伺服器一定會是正确抓到“你好”了。

補充：在My eclipse裡面設定jsp的編碼方式：window --> Preferences --> MyEclipse --> Files and Editors--> JSP中選擇你要設定的Encoding就可以了，一般現在都統一用UTF-8編碼了。

JSP/Servlet中的幾個編碼的作用

     在JSP/Servlet中主要有以下幾個地方可以設定編碼，pageEncoding="UTF-8"、contentType="text/html;charset=UTF-8"、request.setCharacterEncoding("UTF-8")和response.setCharacterEncoding("UTF-8")，其中前兩個隻能用于JSP中，而後兩個可以用于JSP和Servlet 中。

1、pageEncoding="UTF-8"的作用是設定JSP編譯成Servlet時使用的編碼。

     衆所周知，JSP在伺服器上是要先被編譯成Servlet的。pageEncoding="UTF-8"的作用就是告訴JSP編譯器在将JSP檔案編譯成Servlet時使用的編碼。通常，在JSP内部定義的字元串（直接在JSP中定義，而不是從浏覽器送出的資料）出現亂碼時，很多都是由于該參數設定錯誤引起的。例如，你的 JSP檔案是以GBK為編碼儲存的，而在JSP中卻指定pageEncoding="UTF-8"，就會引起JSP内部定義的字元串為亂碼。

     另外，該參數還有一個功能，就是在JSP中不指定contentType參數，也不使用response.setCharacterEncoding方法時，指定對伺服器響應進行重新編碼的編碼。

2、contentType="text/html;charset=UTF-8"的作用是指定對伺服器響應進行重新編碼的編碼。

    在不使用response.setCharacterEncoding方法時，用該參數指定對伺服器響應進行重新編碼的編碼。

3、response.setContentType指定傳回給用戶端的編碼，同時指定了浏覽器顯示的編碼。

4、request.setCharacterEncoding("UTF-8")的作用是設定對用戶端請求進行重新編碼的編碼。

     該方法用來指定對浏覽器發送來的資料進行重新編碼（或者稱為解碼）時，使用的編碼。它指定後可以通過getParameter()則直接獲得正确的字元串，如果不指定，則預設使用iso8859-1編碼。值得注意的是在執行setCharacterEncoding()之前，不能執行任何getParameter()。而且，該指定隻對POST方法有效，對GET方法無效。分析原因，應該是在執行第一個getParameter()的時候，java将會按照編碼分析所有的送出内容，而後續的getParameter()不再進行分析，是以setCharacterEncoding()無效。而對于GET方法送出表單是，送出的内容在URL中，一開始就已經按照編碼分析送出内容，setCharacterEncoding()自然就無效。

5、response.setCharacterEncoding("UTF-8")的作用是指定對伺服器響應進行重新編碼的編碼。

     伺服器在将資料發送到浏覽器前，對資料進行重新編碼時，使用的就是該編碼（設定HTTP響應的編碼）。如果之前使用response.setContentType設定了編碼格式，則使用response.setCharacterEncoding指定的編碼格式覆寫之前的設定。與response.setContentType相同的是，調用此方法，必須在getWriter執行之前或者response被送出之前。

 浏覽器是怎麼樣對接收和發送的資料進行編碼的

   response.setCharacterEncoding("UTF- 8")的作用是指定對伺服器響應進行重新編碼的編碼。同時，浏覽器也是根據這個參數來對其接收到的資料進行重新編碼（或者稱為解碼）。是以在無論你在 JSP中設定response.setCharacterEncoding("UTF-8")或者response.setCharacterEncoding("GBK")，浏覽器均能正确顯示中文（前提是你發送到浏覽器的資料編碼是正确的，比如正确設定了pageEncoding參數等）。讀者可以做個實驗，在JSP中設定response.setCharacterEncoding("UTF- 8")，在IE中顯示該頁面時，在IE的菜單中選擇"檢視(V)"à"編碼(D)"中可以檢視到是"Unicode（UTF-8）"，而在在JSP中設定response.setCharacterEncoding("GBK")，在IE中顯示該頁面 時，在IE的菜單中選擇"檢視(V)"à"編碼(D)"中可以檢視到是"簡體中文（GB2312）"。

     浏覽器在發送資料時，對URL和參數會進行URL編碼，對參數中的中文，浏覽器也是使response.setCharacterEncoding參數來進行URL編碼的。以百度和 GOOGLE為例，如果你在百度中搜尋"漢字"，百度會将其編碼為"%BA%BA%D7%D6"。而在GOOGLE中搜尋"漢字"，GOOGLE會将其編 碼為"%E6%B1%89%E5%AD%97"，這是因為百度的response.setCharacterEncoding參數為GBK，而 GOOGLE的的response.setCharacterEncoding參數為UTF-8。

      浏覽器在接收伺服器資料和發送資料到伺服器時所使用的編碼是相同的，預設情況下均為JSP頁面的response.setCharacterEncoding參數（或者contentType和 pageEncoding參數），我們稱其為浏覽器編碼。當然，在IE中可以修改浏覽器編碼（在IE的菜單中選擇"檢視(V)"à"編碼(D)"中修改），但通常情況下，修改該參數會使原本正确的頁面中出現亂碼。一個有趣的例子是，在IE中浏覽GOOGLE的首頁時，将浏覽器編碼修改為"簡體中文（GB2312）"，此時，頁面上的中文會變成亂碼，不理它，在文本框中輸入"漢字"，送出，GOOGLE會将其編碼為"%BA%BA%D7%D6"。可見，浏覽器在對中文進行URL編碼時，使用的就是浏覽器編碼。

     弄清了浏覽器是在接收和發送資料時，是如何對資料進行編碼的了，我們再來看看伺服器是在接收和發送資料時，是如何對資料進行編碼的。

     對于發送資料，伺服器按照response.setCharacterEncoding—contentType—pageEncoding的優先順序，對要發送的資料進行編碼。

     對于接收資料，要分三種情況。一種是浏覽器直接用URL送出的資料，另外兩種是用表單的GET和POST方式送出的資料。

   因為各種WEB伺服器對這三種方式的處理也不相同，是以我們以Tomcat5.0為例。

   無論使用那種方式送出，如果參數中包含中文，浏覽器都會使用目前浏覽器編碼對其進行URL編碼。

（1）對于表單中POST方式送出的資料，隻要在接收資料的JSP中正确request.setCharacterEncoding參數，即将對用戶端請求進行重新編碼的編碼設定成浏覽器編碼，就可以保證得到的參數編碼正确。有寫讀者可能會問，那如何得到浏覽器編碼呢？上面我們提過了，在預設請情況下，浏覽器編碼就是你在響應該請求的JSP頁面中response.setCharacterEncoding設定的值。是以對于POST表單送出的資料，在獲得資料的 JSP頁面中request.setCharacterEncoding要和生成送出該表單的JSP頁面的response.setCharacterEncoding設定成相同的值。

（2）對于URL送出的資料和表單中GET方式送出的資料，在接收數 據的JSP中設定request.setCharacterEncoding參數是不行的，因為在Tomcat5.0中，預設情況下使用ISO-8859-1對URL送出的資料和表單中GET方式送出的資料進行重新編碼（解碼），而不使用該參數對URL送出的資料和表單中GET方式送出的資料進行重新編碼（解碼）。要解決該問題，應該在Tomcat的配置檔案的Connector标簽中設定useBodyEncodingForURI或者 URIEncoding屬性，其中useBodyEncodingForURI參數表示是否用request.setCharacterEncoding 參數對URL送出的資料和表單中GET方式送出的資料進行重新編碼，在預設情況下，該參數為false（Tomcat4.0中該參數預設為 true）；URIEncoding參數指定對所有GET方式請求（包括URL送出的資料和表單中GET方式送出的資料）進行統一的重新編碼（解碼）的編碼。URIEncoding和useBodyEncodingForURI差別是，URIEncoding是對所有GET方式的請求的資料進行統一的重新編碼（解碼），而useBodyEncodingForURI則是根據響應該請求的頁面的request.setCharacterEncoding參數 對資料進行的重新編碼（解碼），不同的頁面可以有不同的重新編碼（解碼）的編碼。是以對于URL送出的資料和表單中GET方式送出的資料，可以修改 URIEncoding參數為浏覽器編碼或者修改useBodyEncodingForURI為true，并且在獲得資料的JSP頁面中 request.setCharacterEncoding參數設定成浏覽器編碼。

下面總結下，以Tomcat5.0為WEB伺服器時，如何防止中文亂碼：

1、對于同一個應用，最好統一編碼，推薦為UTF-8，當然GBK也可以。

2、正确設定JSP的pageEncoding參數。

3、在所有的JSP/Servlet中設定contentType="text/html;charset=UTF-8"或response.setCharacterEncoding("UTF-8")，進而間接實作對浏覽器編碼的設定。

4、 對于請求，可以使用過濾器或者在每個JSP/Servlet中設定request.setCharacterEncoding("UTF-8")。同時，要修改Tomcat的預設配置，推薦将useBodyEncodingForURI參數設定為true，也可以将URIEncoding參數設定為 UTF-8（有可能影響其他應用，是以不推薦）。

前端開發技術 JSP編碼 pageEncoding contentType CHARSET setCharacterEncoding
上一篇: java url contenttype_url的post請求 Content-Type:application/json類型 Java後端接收（^_^）
下一篇: 凸優化—SVD—PCA原理詳情

繼續閱讀