charset和pageEncoding的區別

ContentType ,charset和pageEncoding的區別

========================說法一===========================

ContentType 屬性指定響應的 HTTP 內容類型。如果未指定 ContentType,默認爲 text/HTML。   語法  Response.ContentType [= ContentType ]   參數   ContentType 

 

pageEncoding是jsp文件本身的編碼

contentType的charset是指服務器發送給客戶端時的內容編碼

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

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

第二階段是由JAVAC的JAVA源碼至java byteCode的編譯,不論JSP編寫時候用的是什麼編碼方案,經過這個階段的結果全部是UTF-8的encoding的java源碼。

 

 

 

pageEncoding:設置JSP源文件和響應正文中的字符集編碼。
contentType:設置JSP源文件和響應正文的字符集編碼及MIME類型。

可見,pageEncoding和contentType都可以設置JSP源文件和響應正文中的字符集編碼。但也有區別:
設置JSP源文件字符集時,優先級爲pageEncoding>contentType。如果都沒有設置,默認ISO-8859-1。
設置響應輸出的字符集時,優先級爲contentType>pageEncoding。如果都沒有設置,默認ISO-8859-1。

可以簡單認爲是,pageEncoding是jsp文件本身的編碼;contentType的charset是指服務器發送給客戶端時的內容編碼。例如:pageEncoding="GBK"。這句話的意思是,告訴JVM 這個jsp本身採用的"GBK"編碼,在JSP編譯成Servlet傳給JVM的時候,就用“GBK”的編碼方式將Jsp網頁源文件翻譯成統一的UTF-8形式的Java字節碼。如果不加設定,則JVM默認的用ISO-8859-1這種編碼方式。contentType裏的charset=gbk,指的是此網頁文件輸出到瀏覽器的輸出方式爲gbk。在這個過程中,一個JSP的源文件需要經過三個階段,兩次編碼,才能完成一次完整的輸出。

第一階段:將jsp編譯成Servlet(.java)文件。用到的指令是pageEncoding,根據pageEncoding=“XXX”的指示,找到編碼的規則爲“XXX”,服務器在將JSP文件編譯成.java文件時會根據pageEncoding的設定讀取jsp,結果是由指定的編碼方案翻譯成統一的UTF-8編碼的JAVA源碼(即.java)。
第二階段:從Servlet文件(.java)到Java字節碼文件(.class),從UTF-8到UTF-8。在這一階段中,不論JSP編寫時候用的是什麼編碼方案,經過這個階段的結果全部是UTF-8的encoding的java源碼。JAVAC用UTF-8的encoding讀取java源碼,編譯成UTF-8編碼的二進制碼(即.class),這是JVM對常數字串在二進制碼(java encoding)內表達的規範。這一過程是由JVM的內在規範決定的,不受外界控制。
第三階段:從服務器到瀏覽器,這在一過程中用到的指令是contentType。服務器載入和執行由第二階段生成出來JAVA二進制碼,輸出的結果,也就是在客戶端可見到的結果,在這次輸出過程中,由contentType屬性中的charset來指定,將UTF8形式的二進制碼以charset的編碼形式來輸出。如果沒有人爲設定,則默認的是ISO-8859-1的形式。

 

 

========================說法二===========================

 

"ContentType" (描述內容類型的字符串。該字符串通常被格式化爲類型/子類型,其中類型是常規內容範疇而子類爲特定內容類型)

  一句話總結就是,服務器響應客戶端是以"ContentType" 的類型來響應的。這個很容易理解,但是在百度百科裏面看了一下發現問題了,在contenttype裏面有一個屬性是charset 指定編碼的,而pagEncoding也是編碼的,這兩個編碼有什麼區別呢?

  查閱了資料之後有了深刻的瞭解!

  pageEncoding是jsp文件本身的編碼

  contentType的charset是指服務器發送給客戶端時的內容編碼

  JSP要經過兩次的"編碼",第一階段會用pageEncoding,第二階段會用utf-8至utf-8,第三階段就是由Tomcat出來的網頁,用的是contentType

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

  第二階段是由JAVAC的JAVA源碼至java byteCode的編譯,不論JSP編寫時候用的是什麼編碼方案,經過這個階段的結果全部是UTF-8的encoding的java源碼。

  JAVAC用UTF-8的encoding讀取java源碼,編譯成UTF-8 encoding的二進制碼(即.class),這是JVM對常數字串在二進制碼(java encoding)內表達的規範。

  第三階段是Tomcat(或其的application container)載入和執行階段二的來的JAVA二進制碼,輸出的結果,也就是在客戶端見到的,這時隱藏在階段一和階段二的參數contentType就發揮了功效

  contentType的設定.

  pageEncoding 和contentType的預設都是 ISO8859-1. 而隨便設定了其中一個, 另一個就跟着一樣了(TOMCAT4.1.27是如此). 但這不是絕對的, 這要看各自JSPC的處理方式. 而pageEncoding不等於contentType,

  <%@ page contentType="text/html;charset=utf-8" %>

  記得老師上課講的時候遇到了下面這種情況 他的處理辦法是把utf-8改成了gbk,

  <%@ page contentType="text/html;charset=gbk" %>

  貌似就是利用了隨便改變其中一個另一個就跟着變的原理吧。實際上正規的該法應該是

  <%@ page contentType="text/html;charset=utf-8" pageEncoding="GBK"%>

  但是如果改成了這樣,在服務器端收到的獲取的中文不是亂碼,但是在客戶端打開的還是亂碼,因爲charset=utf-8" 中charset指定了,輸出到客戶端的是utf-8的編碼,所以想正規的該法應該改成

  <%@ page contentType="text/html;charset=gbk" pageEncoding="GBK"%>

  貌似這樣寫,還不如

  <%@ page contentType="text/html;charset=gbk" %>

  簡單呢, 看來以後自己還是用 這種簡單的寫法吧!

  純屬個人自學的理解。如果錯誤還望指出

 

 ===========================說法三===============================

名詞解釋及其作用  

    1. contentType: <%@ page contentType="text/html; charset=UTF-8"%>   

    2. pageEncoding:<%@ page pageEncoding="UTF-8"%>   

    3. html頁面charset:<META http-equiv="Content-Type" content="text/html; charset=UTF-8">   

    4. setCharacterEncoding:request.setCharacterEncoding(),response.setCharacterEncoding()  

    5. setContentType:response.setContentType()  

    6. setHeader: response.setHeader()  

    7. jsp頁面編碼: jsp文件本身的編碼  

    8. web頁面顯示編碼:jsp的輸出流在瀏覽器中顯示的編碼  

    9. web頁面輸入編碼: 輸入框輸入的字體編碼  

    10. web服務器輸入的請求流: web Server相應瀏覽器的請求數據  

    11. web服務器輸出的響應流: web Server相應瀏覽器的輸出數據  

他們之間的相互影響和作用域,以及先後作用順序  

    1. pageEncoding: 只是指明瞭 JSP 頁面本身的編碼格式,跟頁面顯示的編碼沒有關係;  

    容器在讀取(文件)或者(數據庫)或者(字符串常量)時將起轉化爲內部使用的 Unicode,而頁面顯示的時候將  

   內部的Unicode轉換爲contentType指定的編碼後顯示頁面內容;  

    如果pageEncoding屬性存在,那麼JSP頁面的字符編碼方式就由pageEncoding決定,  

    否則就由contentType屬性中的charset決定,如果charset也不存在,JSP頁面的字符編碼方式就採用  

    默認的ISO-8859-1。  

    2. contentType: 指定了MIME類型和JSP頁面迴應時的字符編碼方式。MIME類型的默認值是“text/html”;   

    字符編碼方式的默認值是“ISO-8859-1”. MIME類型和字符編碼方式由分號隔開;  

 pageEncoding和contentType的關係:  

        1. pageEncoding的內容只是用於jsp輸出時的編碼,不會作爲header發出去的; 是告訴web Server   

            jsp頁面按照什麼編碼輸出,即web服務器輸出的響應流的編碼;  

       2. 第一階段是jsp編譯成.java,它會根據pageEncoding的設定讀取jsp,結果是由指定的編碼方案翻譯  

            成統一的UTF-8 JAVA源碼(即.java).  

       3. 第二階段是由JAVAC的JAVA源碼至java byteCode的編譯,不論JSP編寫時候用的是什麼編碼方案,  

            經過這個階段的結果全部是UTF-8的encoding的java源碼.JAVAC用UTF-8的encoding讀取  

            java源碼,編譯成UTF-8 encoding的二進制碼(即.class),這是JVM對常數字串在二進制碼  

            (java encoding)內表達的規範.  

       4. 第三階段是Tomcat(或其的application container)載入和執行階段二的來的JAVA二進制碼,  

            輸出的結果,也就是在客戶端見到的,這時隱藏在階段一和階段二的參數contentType就發揮了功效      

         和contentType效果一樣的設置方式還有 html頁面charset, response.setCharacterEncoding(),   

        response.setContentType(),response.setHeader(); response.setContentType(),  

        response.setHeader();優先級最好,其次是response.setCharacterEncoding();再者是  

        <%@page contentType="text/html; chareset=gbk"%>,最後是<meta http-equiv="content-type"   

        content="text/html; charset=gb2312" />.  

    5. web頁面輸入編碼: 在設置頁面編碼<%@page contentType="text/html; chareset=gbk"%>的同時,也        就指定了頁面的輸入編碼;  

        如果頁面的顯示被設置爲UTF-8,那麼用戶所有的頁面輸入都會按照 UTF-8 編碼; 服務器端程序在讀  

        取表單輸入之前要設定輸入編碼;  

        表單被提交後,瀏覽器會將表單字段值轉換爲指定字符集對應的字節值,然後根據 HTTP 標準 URL  

        編碼方案對結果字節進行編碼.但是頁面需要告訴服務器當前頁面的編碼方式;  

        request.setCharacterEncoding(),能修改Serverlet獲取請求的編碼,response.setCharacterEncoding(),  

        能修改Serverlet返回結果的編碼.

或者用下面來說明:

  • pageEncoding是設置的JSP頁面源代碼的字符編碼格式,如果該項的值是utf-8,則JSP源代碼裏不能寫漢字了,如果你用的是eclipse等工具的話,保存時他會提示有一個錯誤,改成gbk就沒事了,就是這個道理
  • charset是請求服務器以後返回過來的內容的字符編碼,即使pageEncoding設置了gbk,保存,運行程序,查看頁面時會發現剛纔寫的漢字不能正常顯示,把charset改成gbk,正常

JSP要經過兩次的“編碼”,第一階段會用pageEncoding,第二階段會用utf-8至utf-8,第三階段就是由Tomcat返回來的網頁,用的是charset。 

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

第二階段是由JAVAC的JAVA源碼至java byteCode的編譯,不論JSP編寫時候用的是什麼編碼方案,經過這個階段的結果全部是UTF-8的encoding的java源碼。 

第三階段是Tomcat(或其的application container)載入和執行階段,輸出的結果,也就是在客戶端見到的,這時隱藏在階段一和階段二的參數contentType就發揮了功效。

注意:在設置JSP頁面源代碼字符編碼的時候,如果有pageEncoding這一項,則採取這一項的值,如果沒有,採取charset的值,如果都沒有,採取iso8859-1。pageEncoding 和contentType的預設都是 ISO8859-1. 而隨便設定了其中一個, 另一個就跟着一樣了(TOMCAT4.1.27是如此). 但這不是絕對的, 這要看各自JSP容器的處理方式.

如:在Tomcat中如果在jsp中設定了pageEncoding,則contentType也跟着設定成相同的編碼了,但是在resion中就不是,resin中還會用默認的,這點通過查看編譯後的類servlet java文件就可以看到這一點,而問題恰恰就出在這裏,所以,在jsp中,如果是在resin下最好還是明確的單獨設定這2個屬性。

總結:通常我們在JSP頁面設定<%@ page contentType="text/html;charset=GB2312"%>即可。

轉自:http://www.cnblogs.com/kevin-yuan/archive/2011/12/31/2308479.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章