標籤：.com blog 包括 uri 為什麼 a標籤 art char server
轉自：http://blog.sina.com.cn/s/blog_87cb63e50102w2b6.html
以下為本文：
***************************************************
基本概念
有資訊交換就會產生編碼、傳輸、解碼三個過程。編碼是資訊從一種形式轉變成另一種形式的過程，正如人類的語言通過聲帶編碼，轉換成聲波。解碼是編碼的逆函數，耳膜接收聲波，通過腦神經解碼成人類文化所能理解的資訊。
字元集是一種文化上下文下的所有文字元號集合，它的作用是規定了某個文化下的所有字元，以及該字元在資訊交換系統下的表示方式，在電腦資訊系統下是位元組或01序列。本文會在某些時刻將字元集和編碼方案互用，以方便理解。
對於java web應用，狹隘的編碼解碼的過程可以簡單的理解為：編碼的過程是文本字串資訊編碼成01序列，解碼是將01序列恢複為文本字串資訊，具體編碼成什麼樣的01序列是由編碼採用的字元集來決定的，也就是編碼方案。
亂碼是對資訊採用的編碼方案無法理解，使用了錯誤的編碼方案對資訊進行解碼造成的。如果要理解一段資訊的真實意圖，就得知道資訊採用的編碼方案，這是資訊交換的密鑰，這就是為什麼戰爭年代破解對方電報加密方式，實際上就是在破譯對方的編碼方案。
http協議層的編碼解碼
http協議層的字元集關係到http寄件者和接送者採用什麼字元集方案解析對方發送的內容。
瀏覽器端的編碼
請求端常規請求方式主要為form、url、ajax、http組件如HttpClient API。
瀏覽器存在文檔編碼方案charset的概念，文檔的編碼方案等同於文檔解碼方案，它對文檔中發生的請求編碼會產生影響。
影響form提交資料的編碼的因素包括：form的accept-charset屬性、html文檔的編碼方案即 document.charset。其中，form的accept-charset是否能夠有效，依賴具體瀏覽器的實現，有些瀏覽器並不支援，如IE。文 檔編碼方案可以通過document.charset來修改。
文檔內的url編碼，如iframe的src指定的url，以文檔編碼方案為準，地址欄的url的編碼方案完全取決於具體的瀏覽器實現，通過HttpClient組件發送請求時，url是能任意指定編碼方案的。
ajax發送http請求的url編碼方式完全取決於瀏覽器實現，一般支援以文檔編碼方案來決定，但是資料體統一採用utf-8，另外，雖然 ajax可以指定header在contenttype說明編碼方案，但這種做法不會對url、資料體的編碼方案產生任何影響，甚至在有些瀏覽器中，最終 contenttype中的編碼描述都無法真正影響。
另外，header的編碼方案是iso-8859-1，這個是http規範。
服務端的解碼
服務端的httpserver需要解碼的對象包括：header、url、資料體。
header解碼方案是iso-8859-1。
url解碼方案通常稱為URIEncoding，一般HttpServer會提供相應設定，標準servlet並不提供該介面。jetty預設utf-8字元集來解碼，但其他httpserver如tomcat會預設iso-8859-1。
資料體解碼在servlet中可以通過request.setCharacterEncoding來設定。一般的，有些httpserver會以characterEncoding>request要求標頭字元集>utf-8的優先順序來決定資料體的解碼方案。
服務端的編碼
服務端httpserver需要編碼的對象是：header、資料體。
header的編碼方案同樣是iso-8859-1。
通常情況下，服務端必須要指定返回資料體的編碼方案且要在header中標註編碼方案，否則httpserver一般預設iso-8859-1對輸出進行編碼，而瀏覽器也無法得知返回資料體的編碼方案，只能自行猜測，完全依賴瀏覽器自己的實現。
response.setCharacterEncoding的職能是告訴httpserver資料體的編碼方案，並不會也不應該影響到 header中的編碼方案的標註。response.setContentType會影響到header的編碼方案的標註，瀏覽器根據該標識決定解碼方 案。對於一個健全的httpserver來說，在同時通過兩個方法指定了資料體編碼方案和header編碼方案標註的情況下，資料體編碼方案應該由後者決 定，這樣使瀏覽器端得到的編碼資訊和服務端真正編碼資訊一致。另外，一定要注意的是這兩個指定編碼方案的方法必須在response建立輸出資料流之前調用， 輸出資料流一旦建立，編碼方案無法後期指定。
瀏覽器端的解碼
瀏覽器端對返回進行解碼的對象包括：header、資料體。
header的解碼方案是iso-8859-1。
瀏覽器的資料體解碼方案依賴返回資訊，瀏覽器首先從返回頭header中尋找編碼方案標註，如果沒有標註，在得知返回內容為html內容的話，將從head的meta標籤中讀取，如果還沒找到，瀏覽器就不知道如何解碼，會消極的選擇一種解碼方案。
在理論上，推薦html文檔在meta中聲明編碼，且編碼的聲明一定要在檔案開始的1024位元組內完成，所以最好在head標籤開始時立即聲明。
文檔中通常都會有一些通過url下載的資源檔，如css和js檔案，如果資源檔輸出時沒有在返回頭中指定明確的編碼方案，瀏覽器無法得知編碼方案，只能以上面介紹到的文檔編碼方案來進行解碼，這也是瀏覽器容錯的最佳策略。
web應用中瀏覽器與服務端的編碼和解碼
