一.編碼格式介紹
編碼一直是讓新手頭疼的問題，特别是 GBK、GB2312、UTF-8 這三個比較常見的網頁編碼的差別，更是讓許多新手暈頭轉向，怎麼解釋也解釋不清楚。但是編碼又是那麼重要，特别在網頁這一塊。如果你打出來的不是亂碼，而網頁中出現了亂碼，絕大部分原因就出在了編碼上了。此外除了亂碼之外，還會出現一些其他問題（例如：IE6 的 CSS 加載問題）等等。我寫本文的目的，就是要徹底解釋清楚這個編碼問題！如果你遇到了類似的問題，那就要仔細的看看這篇文章。
ANSI、GBK、GB2312、UTF-8、GB18030和 UNICODE
這幾個編碼關鍵詞是比較常見的，雖然我把我們放在了一起說，但并不意味這這幾個東西是平級的關系。本部分的内容，引用自網絡略有修改，不知原文出處，故無法署名。
很久很久以前，有一群人，他們決定用8個可以開合的半導體來組合成不同的狀态，以表示世界上的萬物，他們把這稱為”位元組”。再後來，他們又做了一些可以處理這些位元組的機器，機器開動了，可以用位元組來組合出很多狀态，狀态開始變來變去，他們就把這機器稱為”計算機”。
開始計算機隻在美國用。八位的位元組一共可以組合出256(2的8次方)種不同的狀态。他們把其中的編号從0開始的32種狀态分别規定了特殊的用途，一但終端、列印機遇上約定好的這些位元組被傳過來時，就要做一些約定的動作。遇上 00×10, 終端就換行，遇上0×07, 終端就向人們嘟嘟叫，例好遇上0x1b, 列印機就列印反白的字，或者終端就用彩色顯示字母。他們看到這樣很好，于是就把這些0×20以下的位元組狀态稱為”控制碼”。
他們又把所有的空格、标點符号、數字、大小寫字母分别用連續的位元組狀态表示，一直編到了第127号，這樣計算機就可以用不同位元組來存儲英語的文字 了。大家看到這樣，都感覺很好，于是大家都把這個方案叫做 ANSI 的”Ascii”編碼（American Standard Code for Information Interchange，美國資訊互換标準代碼）。當時世界上所有的計算機都用同樣的ASCII方案來儲存英文文字。
後來計算機發展越來越廣泛，世界各國為了可以在計算機儲存他們的文字，他們決定采用127号之後的空位來表示這些新的字母、符号，還加入了很多畫表格時需要用下到的橫線、豎線、交叉等形狀，一直把序号編到了 最後一個狀态255。從128到255這一頁的字元集被稱”擴充字元集”。但是原有的編号方法，已經再也放不下更多的編碼。
等中國人們得到計算機時，已經沒有可以利用的位元組狀态來表示漢字，況且有6000多個常用漢字需要儲存呢。于是國人就自主研發，把那些127号之後的奇異符号們直接取消掉。規定：一個小于127的字元的意義與原來相同，但兩個大于127的字元連在一起時，就表示一個漢字，前面的一個位元組（他稱之為高位元組）從0xA1用到 0xF7，後面一個位元組（低位元組）從0xA1到0xFE，這樣我們就可以組合出大約7000多個簡體漢字了。在這些編碼裡，我們還把數學符号、羅馬希臘的字母、日文的假名們都編進去了，連在 ASCII 裡本來就有的數字、标點、字母都統統重新編了兩個位元組長的編碼，這就是常說的”全角”字元，而原來在127号以下的那些就叫”半角”字元了。
中國人民看到這樣很不錯，于是就把這種漢字方案叫做 “GB2312″。GB2312 是對 ASCII 的中文擴充。
但是中國的漢字太多了，後來還是不夠用，于是幹脆不再要求低位元組一定是127号之後的内碼，隻要第一個位元組是大于127就固定表示這是一個漢字的開始，不管後面跟的是不是 擴充字元集裡的内容。結果擴充之後的編碼方案被稱為 GBK 标準，GBK 包括了 GB2312 的所有内容，同時又增加了近20000個新的漢字（包括繁體字）和符号。後來少數民族也要用電腦了，于是我們再擴充，又加了幾千個新的少數民族的字，GBK 擴成了 GB18030。從此之後，中華民族的文化就可以在計算機時代中傳承了。
因為當時各個國家都像中國這樣搞出一套自己的編碼标準，結果互相之間誰也不懂誰的編碼，誰也不支援别人的編碼。當時的中國人想讓電腦顯示漢字，就必須裝上一個”漢字系統”，專門用來處理漢字的顯示、輸入的問題，裝錯了字元系統，顯示就會亂了套。這怎麼辦？就在這時，一個叫 ISO （國際标誰化組織）的國際組織決定着手解決這個問題。他們采用的方法很簡單：廢了所有的地區性編碼方案，重新搞一個包括了地球上所有文化、所有字母和符号的編碼！他們打算叫它”Universal Multiple-Octet Coded Character Set”，簡稱 UCS, 俗稱 “UNICODE”。
UNICODE 開始制訂時，計算機的存儲器容量極大地發展了，空間再也不成為問題了。于是 ISO 就直接規定必須用兩個位元組，也就是16位來統一表示所有的字元，對于 ascii 裡的那些”半角”字元，UNICODE 包持其原編碼不變，隻是将其長度由原來的8位擴充為16位，而其他文化和語言的字元則全部重新統一編碼。由于”半角”英文符号隻需要用到低8位，是以其高 8位永遠是0，是以這種大氣的方案在儲存英文文本時會多浪費一倍的空間。
但是，UNICODE 在制訂時沒有考慮與任何一種現有的編碼方案保持相容，這使得 GBK 與UNICODE 在漢字的内碼編排上完全是不一樣的，沒有一種簡單的算術方法可以把文本内容從UNICODE編碼和另一種編碼進行轉換，這種轉換必須通過查表來進行。UNICODE 是用兩個位元組來表示為一個字元，他總共可以組合出65535不同的字元，這大概已經可以覆寫世界上所有文化的符号。
UNICODE 來到時，一起到來的還有計算機網絡的興起，UNICODE 如何在網絡上傳輸也是一個必須考慮的問題，于是面向傳輸的衆多 UTF（UCS Transfer Format）标準出現了，顧名思義，UTF8 就是每次8個位傳輸資料，而 UTF16 就是每次16個位，隻不過為了傳輸時的可靠性，從UNICODE到 UTF時并不是直接的對應，而是要過一些算法和規則來轉換。
看完這些，相信你對于這幾個編碼關系等，了解的比較清楚了吧。我再來簡單的總結一下：
● 中國人民通過對 ASCII 編碼的中文擴充改造，産生了 GB2312 編碼，可以表示6000多個常用漢字。
● 漢字實在是太多了，包括繁體和各種字元，于是産生了 GBK 編碼，它包括了 GB2312 中的編碼，同時擴充了很多。
● 中國是個多民族國家，各個民族幾乎都有自己獨立的語言系統，為了表示那些字元，繼續把 GBK 編碼擴充為 GB18030 編碼。
● 每個國家都像中國一樣，把自己的語言編碼，于是出現了各種各樣的編碼，如果你不安裝相應的編碼，就無法解釋相應編碼想表達的内容。
● 終于，有個叫 ISO 的組織看不下去了。他們一起創造了一種編碼 UNICODE ，這種編碼非常大，大到可以容納世界上任何一個文字和标志。是以隻要電腦上有 UNICODE 這種編碼系統，無論是全球哪種文字，隻需要儲存檔案的時候，儲存成 UNICODE 編碼就可以被其他電腦正常解釋。
● UNICODE 在網絡傳輸中，出現了兩個标準 UTF-8 和 UTF-16，分别每次傳輸 8個位和 16個位。
于是就會有人産生疑問，UTF-8 既然能儲存那麼多文字、符号，為什麼國内還有這麼多使用 GBK 等編碼的人？因為 UTF-8 等編碼體積比較大，占電腦空間比較多，如果面向的使用人群絕大部分都是中國人，用 GBK 等編碼也可以。但是目前的電腦來看，硬碟都是白菜價，電腦性能也已經足夠無視這點性能的消耗了。是以推薦所有的網頁使用統一編碼：UTF-8。
關于記事本無法單獨儲存“聯通”的問題
當你建立一個 文本文檔 之後，在裡面輸入 “聯通” 兩個字，然後儲存。當你再次打開的時候，原來輸入的 “聯通” 會變成兩個亂碼。
網頁編碼就是那點事
這個問題就是因為 GB2312 編碼與 UTF8 編碼産生了編碼沖撞造成的。從網上引來一段從UNICODE到UTF8的轉換規則：
UTF-8
0000 – 007F
0xxxxxxx
0080 – 07FF
110xxxxx 10xxxxxx
0800 – FFFF
1110xxxx 10xxxxxx 10xxxxxx
例如”漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間，是以要用3位元組模闆：1110xxxx 10xxxxxx 10xxxxxx。将6C49寫成二進制是：0110 1100 0100 1001，将這個比特流按三位元組模闆的分段方法分為0110 110001 001001，依次代替模闆中的x，得到：1110-0110 10-110001 10-001001，即E6 B1 89，這就是其UTF8的編碼。
而當你建立一個文本檔案時，記事本的編碼預設是ANSI, 如果你在ANSI的編碼輸入漢字，那麼他實際就是GB系列的編碼方式，在這種編碼下，”聯通”的内碼是：
c1 1100 0001
aa 1010 1010
cd 1100 1101
a8 1010 1000
注意到了嗎？第一二個位元組、第三四個位元組的起始部分的都是”110″和”10″，正好與UTF8規則裡的兩位元組模闆是一緻的，于是再次打開記事本 時，記事本就誤認為這是一個UTF8編碼的檔案，讓我們把第一個位元組的110和第二個位元組的10去掉，我們就得到了”00001 101010″，再把各位對齊，補上前導的0，就得到了”0000 0000 0110 1010″，不好意思，這是UNICODE的006A，也就是小寫的字母”j”，而之後的兩位元組用UTF8解碼之後是0368，這個字元什麼也不是。這就 是隻有”聯通”兩個字的檔案沒有辦法在記事本裡正常顯示的原因。
由這個問題，可以發散出很多問題。比較常見的一個問題就是：我已經把檔案儲存成了 XX 編碼，為什麼每次打開，還是原來的 YY 編碼？！原因就在于此，你雖然儲存成了 XX 編碼，但是系統識别的時候，卻誤識别為了 YY 編碼，是以還是顯示為 YY 編碼。為了避免這個問題，微軟公司弄出了一個叫 BOM 頭的東西。
關于檔案 BOM 頭的問題
當使用類似 WINDOWS 自帶的記事本等軟體，在儲存一個以UTF-8編碼的檔案時，會在檔案開始的地方插入三個不可見的字元（0xEF 0xBB 0xBF，即BOM）。它是一串隐藏的字元，用于讓記事本等編輯器識别這個檔案是否以UTF-8編碼。這樣就可以避免這個問題了。對于一般的檔案，這樣并不會産生什麼麻煩。
這樣做，也有弊處，尤其展現在網頁中。PHP并不會忽略BOM，是以在讀取、包含或者引用這些檔案時，會把BOM作為該檔案開頭正文 的一部分。根據嵌入式語言的特點，這串字元将被直接執行（顯示）出來。由此造成即使頁面的 top padding 設定為0，也無法讓整個網頁緊貼浏覽器頂部，因為在html一開頭有這3個字元。如果你在網頁中，發現了由未知的空白等，很有可能就是由于檔案有 BOM 頭造成的。遇到這種問題，把檔案儲存的時候，不要帶有 BOM 頭！
如何檢視和修改某文檔的編碼
1，直接使用記事本檢視和修改。我們可以用記事本打開檔案，然後點選左上角的 “檔案” =》“另存為”，這時候就會彈出一個儲存的視窗。在下面選擇好編碼之後，點選儲存就可以了。
網頁編碼就是那點事
但是這種方式的選擇餘地非常小，通常用來快速檢視檔案是什麼編碼。我更推薦使用下面的方法。
2，使用其他文本編輯器（例如：notepad ++）來檢視修改。幾乎所有的成熟的文本編輯器（例如：Dreamweaver、Emeditor等），都可以快速檢視或修改檔案編碼。這一點尤其展現在 notepad++ 上面。
打開一個檔案之後，會在右下角顯示目前檔案的編碼。
網頁編碼就是那點事
點選上面菜單欄中的 “encoding” 即可把目前文檔轉換成其他編碼
網頁編碼就是那點事
IE6 的加載 CSS 檔案 BUG
當 HTML 檔案的編碼 與想要加載 CSS 的檔案不一緻的時候，IE6 将無法讀取 CSS 檔案，即 HTML 檔案沒有樣式。就本人的觀察，這個問題從未在其他浏覽器中出現過，隻在 IE6 中出現過。隻需要把 CSS 檔案，儲存成 HTML 檔案的編碼即可。
二.windows記事本儲存“聯通” 編碼問題
簡單分析：
這是微軟記事本的一個BUG，準确點就是unicode編碼的問題。
隻要你拿拼音輸入“liantong”所對應的漢字，比如連同，連通等都會出現這個狀況。
而且這個問題隻在第一次出現，以後再使用就不會有問題了。
記事本預設的儲存格式是UTF-8，你若選擇儲存為Unicode，那麼這種狀況就不會出現了。
原理分析：
在計算機中字元通常并不是儲存為圖像，每個字元都是使用一個編碼來表示的，而每個字元究竟使用哪個編碼代表，要取決于使用哪個字元集(charset)。
在最初的時候，Internet上隻有一種字元集——ANSI的ASCII字元集，它使用7 bits來表示一個字元，總共表示128個字元，其中包括了英文字母、數字、标點符号等常用字元。之後，又進行擴充，使用8 bits表示一個字元，可以表示256個字元，主要在原來的7 bits字元集的基礎上加入了一些特殊符号例如制表符。
後來，由于各國語言的加入，ASCII已經不能滿足資訊交流的需要，是以，為了能夠表示其它國家的文字，各國在ASCII的基礎上制定了自己的字元集，這些從ANSI标準派生的字元集被習慣的統稱為ANSI字元集，它們正式的名稱應該是MBCS(Multi-Byte Chactacter System，即多位元組字元系統)。這些派生字元集的特點是以ASCII 127 bits為基礎，相容ASCII 127，他們使用大于128的編碼作為一個Leading Byte，緊跟在Leading Byte後的第二（甚至第三）個字元與Leading Byte一起作為實際的編碼。這樣的字元集有很多，我們常見的GB-2312就是其中之一。
例如在GB-2312字元集中，“連通”的編碼為C1 AC CD A8，其中C1和CD就是Leading Byte。前127個編碼為标準ASCII保留，例如“0”的編碼是30H（30H表示十六進制的30）。軟體在讀取時，如果看到30H，知道它小于128就是标準ASCII，表示“0”，看到C1大于128就知道它後面有一個另外的編碼，是以C1 AC一同構成一個整個的編碼，在GB-2312字元集中表示“連”。
由于每種語言都制定了自己的字元集，導緻最後存在的各種字元集實在太多，在國際交流中要經常轉換字元集非常不便。是以，提出了Unicode字元集，它固定使用16 bits（兩個位元組、一個字）來表示一個字元，共可以表示65536個字元。将世界上幾乎所有語言的常用字元收錄其中，友善了資訊交流。标準的Unicode稱為UTF-16。後來為了雙位元組的Unicode能夠在現存的處理單位元組的系統上正确傳輸，出現了UTF-8，使用類似MBCS的方式對Unicode進行編碼。注意UTF-8是編碼，它屬于Unicode字元集。Unicode字元集有多種編碼形式，而ASCII隻有一種，大多數MBCS（包括GB-2312）也隻有一種。
例如“連通”兩個字的Unicode标準編碼UTF-16 (big endian）為：DE 8F 1A 90
而其UTF-8編碼為：E8 BF 9E E9 80 9A
最後，當一個軟體打開一個文本時，它要做的第一件事是決定這個文本究竟是使用哪種字元集的哪種編碼儲存的。軟體有三種途徑來決定文本的字元集和編碼：
最标準的途徑是檢測文本最開頭的幾個位元組，如下表：
開頭位元組
Charset/encoding
EF BB BF
UTF-8
FE FF
UTF-16/UCS-2, little endian
FF FE
UTF-16/UCS-2, big endian
FF FE 00 00
UTF-32/UCS-4, little endian.
00 00 FE FF
UTF-32/UCS-4, big-endian.
例如插入标記後，連通”兩個字的UTF-16 (big endian）和UTF-8碼分别為：
FF FE DE 8F 1A 90
EF BB BF E8 BF 9E E9 80 9A
但是MBCS文本沒有這些位于開頭的字元集标記，更不幸的是，一些早期的和一些設計不良的軟體在儲存Unicode文本時不插入這些位于開頭的字元集标記。是以，軟體不能依賴于這種途徑。這時，軟體可以采取一種比較安全的方式來決定字元集及其編碼，那就是彈出一個對話框來請示使用者，例如将那個“連通”檔案拖到MS Word中，Word就會彈出一個對話框。
如果軟體不想麻煩使用者，或者它不友善向使用者請示，那它隻能采取自己“猜”的方法，軟體可以根據整個文本的特征來猜測它可能屬于哪個charset，這就很可能不準了。使用記事本打開那個“連通”檔案就屬于這種情況。
我們可以證明這一點：在記事本中鍵入“連通”後，選擇“另存為”，會看到最後一個下拉框中顯示有“ANSI”，這時儲存。當再當打開“連通”檔案出現亂碼後，再點選“檔案”->“另存為”，會看到最後一個下拉框中顯示有“UTF-8”，這說明記事本認為目前打開的這個文本是一個UTF-8編碼的文本。而我們剛才儲存時是用ANSI字元集儲存的。這說明，記事本猜測了“連通”檔案的字元集，認為它更像一個UTF-8編碼文本。這是因為“連通”兩個字的GB-2312編碼看起來更像UTF-8編碼導緻的，這是一個巧合，不是所有文字都這樣。可以使用記事本的打開功能，在打開“連通”檔案時在最後一個下拉框中選擇ANSI，就能正常顯示了。反過來，如果之前儲存時儲存為UTF-8編碼，則直接打開也不會出現問題。
如果将“連通”檔案放入MS Word中，Word也會認為它是一個UTF-8編碼的檔案，但它不能确定，是以會彈出一個對話框詢問使用者，這時選擇“簡體中文（GB2312）”，就能正常打開了。記事本在這一點上做得比較簡化罷了。
原文連結 http://www.qianxingzhem.com/post-1499.html
參考: http://blog.csdn.net/Zhiyuan_Ma/article/details/51838054
參考: http://blog.csdn.net/haiross/article/details/46360021