瀏覽器 ie/firefox -------——---->servlet容器--------——---------------->顯示頁面
編碼 使用容器的uriencoding解碼/request解碼，再編碼發出響應 解碼
一、請求
我把使用者傳送請求方式不同引起的中文問題劃分了四種型別：
1、表單的get提交
2、表單的post提交
4、位址列中引數直接輸入中文提交（不討論，違背尋常規則，而且這種方式很難控制）
1.get提交
對於這種，影響的有tomcat的uriencoding。
瀏覽器會根據自己的頁面的編碼格式作為起始編碼格式（右擊選單編碼有顯示的），把字元使用瀏覽器的編碼格式編碼成byte位元組進行傳輸。到了tomcat這裡，tomcat會使用uriencoding進行重新編碼（解碼），如果tomcat沒有配置的話就會使用iso-8859-1對byte進行重新編碼（解碼）成字元。如果瀏覽器得編碼格式為utf-8，且tomcat沒有配置重新編碼（解碼）格式的話，就可以使用下面的方式拿到正確的字元了new string(request.getparameter("text").getbytes("iso-8859-1"),"utf-8") 上的意思就是說，把剛才的字元，用iso-8859-1進行編碼成byte，還原回去，再使用uft-8對byte進行重新編碼（解碼）成字元。（這個方法就是剛才從瀏覽器到tomcat過來的逆向過程）
2.post提交
對於這種情況，response.setcharacterencoding有影響，當沒有對response.setcharacterencoding設定的時候值為null，則預設採用iso-8859-1來進行重新編碼（解碼）。
瀏覽器根據自己頁面的編碼格式作為起始編碼格式，把字元進行編碼成byte進行傳輸，到了tomcat，tomcat不進行干涉其中的重新編碼（解碼）格式。如果response.getcharacterencoding為null，那麼預設採用iso-8859-1進行重新編碼（解碼）成字元，如果設定了，就按照設定的編碼格式進行重新編碼（解碼）字元。
jsp：pageencoding="gb18030" jsp頁面的編碼格式，即jsp會被解析成servlet時，採用的編碼格式。如果不配置，預設採用iso-8859-1，當jsp檔案儲存編碼型別和pageencoding不一致時就會出現jsp內部解析亂碼。eclipse現在預設pageencoding就是檔案的編碼格式，修改pageencoding就會修改檔案的編碼格式。該引數還有乙個功能，就是在jsp中不指定contenttype引數，也不使用response.setcharacterencoding方法時指定對伺服器響應進行重新編碼（解碼）的編碼，從而pageencoding會影響瀏覽器的編碼格式。
jsp：contenttype="text/html;charset=utf-8" 的作用是指定對伺服器響應進行重新編碼（解碼）的編碼。設定瀏覽器的編碼格式。也就是說瀏覽器提交資料就會使用這個編碼格式。相當於response.setcharacterencoding來改變編碼，但是改變的只是jsp請求的response編碼格式。不能改變裡面所有其他的ajax請求的編碼格式。在沒有設定的情況下預設採用iso-8859-1格式。
meta中
當前面pageencoding和contenttype都沒有設定的情況下，被解析成的html頁面就會採用這種編碼方式。來把byte解析成瀏覽器顯示的資訊。
jsp頁面中 pageencoding--->contenttype--->meta 預設預設。pageencoding寫了後面的都可以不用寫，預設繼承。
jsp頁面中的設定編碼優先順序response.setcharacterencoding--->contenttype--->pageencoding 層層覆蓋。
request.setcharacterencoding("utf-8")的作用是設定對客戶端請求進行重新編碼（解碼）的編碼。
該方法用來指定對瀏覽器傳送來的資料進行重新編碼（或者稱為解碼）時，使用的編碼。對post方法有效。
使用response.setcharacterencoding方法時，用該引數指定對伺服器響應進行重新編碼（解碼）的編碼。
關於utf-8和gbk轉化之間的問題
當utf-8轉化成gbk，再從gbk轉化成utf-8的時候，偶數漢字可以在utf-8，gbk兩者中互相轉換，而奇數個漢字則不能。
關於big5
關於其他的轉碼問題，如果使用的是簡體中文的字元，即使編碼和解碼都是使用big5，部分字元仍然無法解析，是亂碼。
關於iso-8859-1
iso-8859-1是不支援中文的，所以就算中文字元使用iso-8859-1進行編碼，最後再用iso-8859-1進行重新編碼（解碼）的話，拿到的字元也不能顯示中文。即換言之，iso-8859-1不能作為把字元變成byte的編碼格式使用。
ajax
二、返回資訊
而response如果沒有顯式設定的話，不管request的編碼是什麼，response的編碼就是iso-8859-1。
對於response返回的資訊如：response.getwriter().println就可以看到這個編碼設定的作用了。而對於使用request.setattribute等傳遞資料的話，這個編碼格式設定了也沒用。
當使用response.getwriter().println列印到瀏覽器時，在沒有設定response的時候預設為null，而在伺服器端則預設使用iso-8859-1進行編碼成byte，等到了瀏覽器，發現response的資訊header中沒有相關編碼設定，就會去取window系統的編碼格式，中文系統預設為gbk/gb2312。所以，列印出來的頁面的瀏覽器編碼格式為gb2312。而如果設定了response的編碼格式，那麼就算到了瀏覽器，瀏覽器解析也會按照設定的編碼格式重新編碼（解碼）。
當使用response.getwriter().println列印到本地檔案時，即使設定了response，在發出時，採用的是設定的編碼格式編碼成byte，等到了客戶端，客戶端會用系統的編碼格式重新編碼（解碼）檔案，對於windows預設就是gb2312/gbk，所以最好再response發出時就設定編碼的格式為gbk。
至於為什麼列印到瀏覽器，標頭檔案的資訊就寫入編碼格式，而列印到本地檔案，標頭檔案中就沒有寫入編碼格式的問題，還沒有得到證實。猜測：後端傳送到瀏覽器時，瀏覽器使用包含重新編碼（解碼）格式的。而傳送檔案時，沒有使用重新編碼（解碼）格式的，使用的是作業系統的編碼格式儲存檔案。
如果設定了response.setcharacterencoding。那麼就會按照這個編碼格式傳送到前端，瀏覽器並用這種方式重新編碼（解碼）。也就是說在傳送的頁面的文字資訊head中的content-type已經設定成了response.setcharacterencoding定義的編碼格式，來用作重新編碼（解碼）。
ajax
ajax使用的是response.responsetext來進行獲取資訊，也就是說，也是需要使用到response的編碼格式的。ajax不會再對該編碼格式進行任何修改。只是接受而已。
GET和POST 編碼和亂碼
1.什麼是url編碼。url編碼是一種瀏覽器用來打包表單輸入的格式，瀏覽器從表單中獲取所有的name和其對應的value，將他們以name value編碼方式作為url的一部分或者分離的傳送到伺服器上。2.url編碼規則。每對name value由 分開，每對來自表單的name value用 分開。...
HTML編碼和CSS編碼會遇到的問
參考鏈結 html 屬性應當按照以下給出的順序依次排列，確保 的易讀性。class 用於標識高度可復用元件，因此應該排在首位。id 用於標識具體元件，應當謹慎使用 例如，頁面內的書籤 因此排在第二位。positioning box model typographic visual 由於定位 posi...
servlet中get和post編碼問題
request.setcharacterencoding 是設定從request中取得的值或從資料庫中取出的值 response.setcontenttype text xml charset gbk 是設定頁面中為中文編碼 前者是設定動態文字 引數，資料庫 後者設定頁面靜態文字 response....