二〇一〇年四月十九日 21:23:04
下午和女朋友去吃了點飯，之后在操場溜達了兩圈，送回去了她，我在自己組的房子里面開始看JSP的教程了，上午學(xué)習(xí)了一下request,打算看一下另一個內(nèi)置對象response. 看第一個參數(shù)的介紹contentType 就發(fā)蒙。
ContentType 屬性指定響應(yīng)的 HTTP 內(nèi)容類型。如果未指定 ContentType，默認(rèn)為 text/HTML。語法
Response.ContentType = "ContentType"
"ContentType" (描述內(nèi)容類型的字符串。該字符串通常被格式化為類型/子類型，其中類型是常規(guī)內(nèi)容范疇而子類為特定內(nèi)容類型)
一句話總結(jié)就是，服務(wù)器響應(yīng)客戶端是以"ContentType" 的類型來響應(yīng)的。這個很容易理解，但是在百度百科里面看了一下發(fā)現(xiàn)問題了，在contenttype里面有一個屬性是charset 指定編碼的，而pagEncoding也是編碼的，這兩個編碼有什么區(qū)別呢？
查閱了資料之后有了深刻的了解！
pageEncoding是jsp文件本身的編碼
contentType的charset是指服務(wù)器發(fā)送給客戶端時的內(nèi)容編碼
JSP要經(jīng)過兩次的"編碼"，第一階段會用pageEncoding，第二階段會用utf-8至utf-8，第三階段就是由Tomcat出來的網(wǎng)頁， 用的是contentType
第一階段是jsp編譯成.java，它會根據(jù)pageEncoding的設(shè)定讀取jsp，結(jié)果是由指定的編碼方案翻譯成統(tǒng)一的UTF-8 JAVA源碼（即.java），如果pageEncoding設(shè)定錯了，或沒有設(shè)定，出來的就是中文亂碼。
第二階段是由JAVAC的JAVA源碼至java byteCode的編譯，不論JSP編寫時候用的是什么編碼方案，經(jīng)過這個階段的結(jié)果全部是UTF-8的encoding的java源碼。
JAVAC用UTF-8的encoding讀取java源碼，編譯成UTF-8 encoding的二進制碼（即.class），這是JVM對常數(shù)字串在二進制碼（java encoding）內(nèi)表達的規(guī)范。
第三階段是Tomcat（或其的application container）載入和執(zhí)行階段二的來的JAVA二進制碼，輸出的結(jié)果，也就是在客戶端見到的，這時隱藏在階段一和階段二的參數(shù)contentType就發(fā)揮了功效
contentType的設(shè)定.
pageEncoding 和contentType的預(yù)設(shè)都是 ISO8859-1. 而隨便設(shè)定了其中一個, 另一個就跟著一樣了(TOMCAT4.1.27是如此). 但這不是絕對的, 這要看各自JSPC的處理方式. 而pageEncoding不等于contentType,
<%@ page contentType="text/html;charset=utf-8" %>
記得老師上課講的時候遇到了下面這種情況 他的處理辦法是把utf-8改成了gbk,
<%@ page contentType="text/html;charset=gbk" %>
貌似就是利用了隨便改變其中一個另一個就跟著變的原理吧。實際上正規(guī)的該法應(yīng)該是
<%@ page contentType="text/html;charset=utf-8" pageEncoding="GBK"%>
但是如果改成了這樣，在服務(wù)器端收到的獲取的中文不是亂碼，但是在客戶端打開的還是亂碼，因為charset=utf-8" 中charset指定了，輸出到客戶端的是utf-8的編碼，所以想正規(guī)的該法應(yīng)該改成
<%@ page contentType="text/html;charset=gbk" pageEncoding="GBK"%>
貌似這樣寫，還不如
<%@ page contentType="text/html;charset=gbk" %>
簡單呢， 看來以后自己還是用 這種簡單的寫法吧！
純屬個人自學(xué)的理解。如果錯誤還望指出
