最近看到網上有關編碼的一篇文章寫的不錯，給大家分享一下.......
原文網址：http://www.imkevinyang.com/2010/06/%E5%85%B3%E4%BA%8E%E5%AD%97%E7%AC%A6%E7%BC%96%E7%A0%81%EF%BC%8C%E4%BD%A0%E6%89%80%E9%9C%80%E8%A6%81%E7%9F%A5%E9%81%93%E7%9A%84.html/comment-page-1#comment-1625
作者：Kevin Yang
字元編碼的問題看似很小，經常被技術人員忽視，但是很容易導緻一些莫名其妙的問題。這裡總結了一下字元編碼的一些普及性的知識，希望對大家有所幫助。
還是得從ASCII碼說起
說到字元編碼，不得不說ASCII碼的簡史。計算機一開始發明的時候是用來解決數字計算的問題，後來人們發現，計算機還可以做更多的事，例如文本處理。但由于計算機隻識“數”，是以人們必須告訴計算機哪個數字來代表哪個特定字元，例如65代表字母‘A’，66代表字母‘B’，以此類推。但是計算機之間字元-數字的對應關系必須得一緻，否則就會造成同一段數字在不同計算機上顯示出來的字元不一樣。是以美國國家标準協會ANSI制定了一個标準，規定了常用字元的集合以及每個字元對應的編号，這就是ASCII字元集（Character Set），也稱ASCII碼。
當時的計算機普遍使用8比特位元組作為最小的存儲和處理單元，加之當時用到的字元也很少，26個大小寫英文字母還有數字再加上其他常用符号，也不到100個，是以使用7個比特位就可以高效的存儲和處理ASCII碼，剩下最高位1比特被用作一些通訊系統的奇偶校驗。
注意，位元組代表系統能夠處理的最小機關，不一定是8比特。隻是現代計算機的事實标準就是用8比特來代表一個位元組。在很多技術規格文獻中，為了避免産生歧義，更傾向于使用8位組（Octet）而不是位元組（Byte）這個術語來強調8個比特的二進制流。下文中為了便于了解，我會延用大家熟悉的“位元組”這個概念。
ASCII字元集由95個可列印字元（0x20-0x7E）和33個控制字元（0x00-0x19，0x7F）組成。可列印字元用于顯示在輸出裝置上，例如熒屏或者列印紙上，控制字元用于向計算機發出一些特殊指令，例如0x07會讓計算機發出哔的一聲，0x00通常用于訓示字元串的結束，0x0D和0x0A用于訓示列印機的列印針頭退到行首（回車）并移到下一行（換行）。
那時候的字元編解碼系統非常簡單，就是簡單的查表過程。例如将字元序列編碼為二進制流寫入儲存設備，隻需要在ASCII字元集中依次找到字元對應的位元組，然後直接将該位元組寫入儲存設備即可。解碼二進制流的過程也是類似。
OEM字元集的衍生
當計算機開始發展起來的時候，人們逐漸發現，ASCII字元集裡那可憐的128個字元已經不能再滿足他們的需求了。人們就在想，一個位元組能夠表示的數字（編号）有256個，而ASCII字元隻用到了0x00~0x7F，也就是占用了前128個，後面128個數字不用白不用，是以很多人打起了後面這128個數字的主意。可是問題在于，很多人同時有這樣的想法，但是大家對于0x80-0xFF這後面的128個數字分别對應什麼樣的字元，卻有各自的想法。這就導緻了當時銷往世界各地的機器上出現了大量各式各樣的OEM字元集。
下面這張表是IBM-PC機推出的其中一個OEM字元集，字元集的前128個字元和ASCII字元集的基本一緻（為什麼說基本一緻呢，是因為前32個控制字元在某些情況下會被IBM-PC機當作可列印字元解釋），後面128個字元空間加入了一些歐洲國家用到的重音字元，以及一些用于畫線條畫的字元。
事實上，大部分OEM字元集是相容ASCII字元集的，也就是說，大家對于0x00~0x7F這個範圍的解釋基本是相同的，而對于後半部分0x80~0xFF的解釋卻不一定相同。甚至有時候同樣的字元在不同OEM字元集中對應的位元組也是不同的。
不同的OEM字元集導緻人們無法跨機器交流各種文檔。例如職員甲發了一封履歷résumés給職員乙，結果職員乙看到的卻是r
sum
s，因為é字元在職員甲機器上的OEM字元集中對應的位元組是0x82，而在職員乙的機器上，由于使用的OEM字元集不同，對0x82位元組解碼後得到的字元卻是
。
多位元組字元集（MBCS）和中文字元集
上面我們提到的字元集都是基于單位元組編碼，也就是說，一個位元組翻譯成一個字元。這對于拉丁語系國家來說可能沒有什麼問題，因為他們通過擴充第8個比特，就可以得到256個字元了，足夠用了。但是對于亞洲國家來說，256個字元是遠遠不夠用的。是以這些國家的人為了用上電腦，又要保持和ASCII字元集的相容，就發明了多位元組編碼方式，相應的字元集就稱為多位元組字元集。例如中國使用的就是雙位元組字元集編碼（DBCS，Double Byte Character Set）。
對于單位元組字元集來說，代碼頁中隻需要有一張碼表即可，上面記錄着256個數字代表的字元。程式隻需要做簡單的查表操作就可以完成編解碼的過程。
代碼頁是字元集編碼的具體實作，你可以把他了解為一張“字元-位元組”映射表，通過查表實作“字元-位元組”的翻譯。下面會有更詳細的描述。
而對于多位元組字元集，代碼頁中通常會有很多碼表。那麼程式怎麼知道該使用哪張碼表去解碼二進制流呢？答案是，根據第一個位元組來選擇不同的碼表進行解析。
例如目前最常用的中文字元集GB2312，涵蓋了所有簡體字元以及一部分其他字元；GBK（K代表擴充的意思）則在GB2312的基礎上加入了對繁體字元等其他非簡體字元（GB18030字元集不是雙位元組字元集，我們在講Unicode的時候會提到）。這兩個字元集的字元都是使用1-2個位元組來表示。Windows系統采用936代碼頁來實作對GBK字元集的編解碼。在解析位元組流的時候，如果遇到位元組的最高位是0的話，那麼就使用936代碼頁中的第1張碼表進行解碼，這就和單位元組字元集的編解碼方式一緻了。
當位元組的高位是1的時候，确切的說，當第一個位元組位于0x
81
–0x
FE之間時，根據第一個位元組不同找到代碼頁中的相應的碼表，例如當第一個位元組是0x81，那麼對應936中的下面這張碼表：
（關于936代碼頁中完整的碼表資訊，參見MSDN：http://msdn.microsoft.com/en-us/library/cc194913%28v=MSDN.10%29.aspx.）
按照936代碼頁的碼表，當程式遇到連續位元組流0x81 0x40的時候，就會解碼為“丂”字元。
ANSI标準、國家标準、ISO标準
不同ASCII衍生字元集的出現，讓文檔交流變得非常困難，是以各種組織都陸續進行了标準化流程。例如美國ANSI組織制定了ANSI标準字元編碼（注意，我們現在通常說到ANSI編碼，通常指的是平台的預設編碼，例如英文作業系統中是ISO-8859-1，中文系統是GBK），ISO組織制定的各種ISO标準字元編碼，還有各國也會制定一些國家标準字元集，例如中國的GBK，GB2312和GB18030。
作業系統在釋出的時候，通常會往機器裡預裝這些标準的字元集還有平台專用的字元集，這樣隻要你的文檔是使用标準字元集編寫的，通用性就比較高了。例如你用GB2312字元集編寫的文檔，在中國大陸内的任何機器上都能正确顯示。同時，我們也可以在一台機器上閱讀多個國家不同語言的文檔了，前提是本機必須安裝該文檔使用的字元集。
Unicode的出現
雖然通過使用不同字元集，我們可以在一台機器上查閱不同語言的文檔，但是我們仍然無法解決一個問題：在一份文檔中顯示所有字元。為了解決這個問題，我們需要一個全人類達成共識的巨大的字元集，這就是Unicode字元集。
Unicode字元集概述
Unicode字元集涵蓋了目前人類使用的所有字元，并為每個字元進行統一編号，配置設定唯一的字元碼（Code Point）。Unicode字元集将所有字元按照使用上的頻繁度劃分為17個層面（Plane），每個層面上有216=65536個字元碼空間。
其中第0個層面BMP，基本涵蓋了當今世界用到的所有字元。其他的層面要麼是用來表示一些遠古時期的文字，要麼是留作擴充。我們平常用到的Unicode字元，一般都是位于BMP層面上的。目前Unicode字元集中尚有大量字元空間未使用。
編碼系統的變化
在Unicode出現之前，所有的字元集都是和具體編碼方案綁定在一起的，都是直接将字元和最終位元組流綁定死了，例如ASCII編碼系統規定使用7比特來編碼ASCII字元集；GB2312以及GBK字元集，限定了使用最多2個位元組來編碼所有字元，并且規定了位元組序。這樣的編碼系統通常用簡單的查表，也就是通過代碼頁就可以直接将字元映射為儲存設備上的位元組流了。例如下面這個例子：
這種方式的缺點在于，字元和位元組流之間耦合得太緊密了，進而限定了字元集的擴充能力。假設以後火星人入住地球了，要往現有字元集中加入火星文就變得很難甚至不可能了，而且很容易破壞現有的編碼規則。
是以Unicode在設計上考慮到了這一點，将字元集和字元編碼方案分離開。
也就是說，雖然每個字元在Unicode字元集中都能找到唯一确定的編号（字元碼，又稱Unicode碼），但是決定最終位元組流的卻是具體的字元編碼。例如同樣是對Unicode字元“A”進行編碼，UTF-8字元編碼得到的位元組流是0x41，而UTF-16（大端模式）得到的是0x00 0x41。
常見的Unicode編碼
UCS-2/UTF-16
如果要我們來實作Unicode字元集中BMP字元的編碼方案，我們會怎麼實作？由于BMP層面上有216=65536個字元碼，是以我們隻需要兩個位元組就可以完全表示這所有的字元了。
舉個例子，“中”的Unicode字元碼是0x4E2D(01001110 00101101)，那麼我們可以編碼為01001110 00101101（大端）或者00101101 01001110 （小端）。
UCS-2和UTF-16對于BMP層面的字元均是使用2個位元組來表示，并且編碼得到的結果完全一緻。不同之處在于，UCS-2最初設計的時候隻考慮到BMP字元，是以使用固定2個位元組長度，也就是說，他無法表示Unicode其他層面上的字元，而UTF-16為了解除這個限制，支援Unicode全字元集的編解碼，采用了變長編碼，最少使用2個位元組，如果要編碼BMP以外的字元，則需要4個位元組結對，這裡就不讨論那麼遠，有興趣可以參考維基百科：UTF-16/UCS-2。
Windows從NT時代開始就采用了UTF-16編碼，很多流行的程式設計平台，例如.Net，Java，Qt還有Mac下的Cocoa等都是使用UTF-16作為基礎的字元編碼。例如代碼中的字元串，在記憶體中相應的位元組流就是用UTF-16編碼過的。
UTF-8
UTF-8應該是目前應用最廣泛的一種Unicode編碼方案。由于UCS-2/UTF-16對于ASCII字元使用兩個位元組進行編碼，存儲和處理效率相對低下，并且由于ASCII字元經過UTF-16編碼後得到的兩個位元組，高位元組始終是0x00，很多C語言的函數都将此位元組視為字元串末尾進而導緻無法正确解析文本。是以一開始推出的時候遭到很多西方國家的抵觸，大大影響了Unicode的推行。後來聰明的人們發明了UTF-8編碼，解決了這個問題。
UTF-8編碼方案采用1-4個位元組來編碼字元，方法其實也非常簡單。
（上圖中的x代表Unicode碼的低8位，y代表高8位）
對于ASCII字元的編碼使用單位元組，和ASCII編碼一摸一樣，這樣所有原先使用ASCII編解碼的文檔就可以直接轉到UTF-8編碼了。對于其他字元，則使用2-4個位元組來表示，其中，首位元組前置1的數目代表正确解析所需要的位元組數，剩餘位元組的高2位始終是10。例如首位元組是1110yyyy，前置有3個1，說明正确解析總共需要3個位元組，需要和後面2個以10開頭的位元組結合才能正确解析得到字元。
關于UTF-8的更多資訊，參考維基百科：UTF-8。
GB18030
任何能夠将Unicode字元映射為位元組流的編碼都屬于Unicode編碼。中國的GB18030編碼，覆寫了Unicode所有的字元，是以也算是一種Unicode編碼。隻不過他的編碼方式并不像UTF-8或者UTF-16一樣，将Unicode字元的編号通過一定的規則進行轉換，而隻能通過查表的手段進行編碼。
關于GB18030的更多資訊，參考：GB18030。
Unicode相關的常見問題
Unicode是兩個位元組嗎？
Unicode隻是定義了一個龐大的、全球通用的字元集，并為每個字元規定了唯一确定的編号，具體存儲為什麼樣的位元組流，取決于字元編碼方案。推薦的Unicode編碼是UTF-16和UTF-8。
帶簽名的UTF-8指的是什麼意思？
帶簽名指的是位元組流以BOM标記開始。很多軟體會“智能”的探測目前位元組流使用的字元編碼，這種探測過程出于效率考慮，通常會提取位元組流前面若幹個位元組，看看是否符合某些常見字元編碼的編碼規則。由于UTF-8和ASCII編碼對于純英文的編碼是一樣的，無法區分開來，是以通過在位元組流最前面添加BOM标記可以告訴軟體，目前使用的是Unicode編碼，判别成功率就十分準确了。但是需要注意，不是所有軟體或者程式都能正确處理BOM标記，例如PHP就不會檢測BOM标記，直接把它當普通位元組流解析了。是以如果你的PHP檔案是采用帶BOM标記的UTF-8進行編碼的，那麼有可能會出現問題。
Unicode編碼和以前的字元集編碼有什麼差別？
早期字元編碼、字元集和代碼頁等概念都是表達同一個意思。例如GB2312字元集、GB2312編碼，936代碼頁，實際上說的是同個東西。但是對于Unicode則不同，Unicode字元集隻是定義了字元的集合和唯一編号，Unicode編碼，則是對UTF-8、UCS-2/UTF-16等具體編碼方案的統稱而已，并不是具體的編碼方案。是以當需要用到字元編碼的時候，你可以寫gb2312，codepage936，utf-8，utf-16，但請不要寫unicode（看過别人在網頁的meta标簽裡頭寫charset=UTF-8，有感而發）。
亂碼問題
亂碼指的是程式顯示出來的字元文本無法用任何語言去解讀。一般情況下會包含大量
或者?。亂碼問題是所有計算機使用者或多或少會遇到的問題。造成亂碼的原因就是因為使用了錯誤的字元編碼去解碼位元組流，是以當我們在思考任何跟文本顯示有關的問題時，請時刻保持清醒：目前使用的字元編碼是什麼。隻有這樣，我們才能正确分析和處理亂碼問題。
例如最常見的網頁亂碼問題。如果你是網站技術人員，遇到這樣的問題，需要檢查以下原因：
- 伺服器傳回的響應頭Content-Type沒有指明字元編碼
- 網頁内是否使用META HTTP-EQUIV标簽指定了字元編碼
- 網頁檔案本身存儲時使用的字元編碼和網頁聲明的字元編碼是否一緻
注意，網頁解析的過程如果使用的字元編碼不正确，還可能會導緻腳本或者樣式表出錯。具體細節可以參考我以前寫過的文章：文檔字元集導緻的腳本錯誤和Asp.Net頁面的編碼問題。
不久前看到某技術論壇有人回報，WinForm程式使用Clipboard類的GetData方法去通路剪切闆中的HTML内容時會出現亂碼的問題，我估計也是由于WinForm在擷取HTML文本的時候沒有用對正确的字元編碼導緻的。Windows剪貼闆隻支援UTF-8編碼，也就是說你傳入的文本都會被UTF-8編解碼。這樣一來，隻要兩個程式都是調用Windows剪切闆API程式設計的話，那麼複制粘貼的過程中不會出現亂碼。除非一方在擷取到剪貼闆資料之後使用了錯誤的字元編碼進行解碼，才會得到亂碼（我做了簡單的WinForm剪切闆程式設計實驗，發現GetData使用的是系統預設編碼，而不是UTF-8編碼）。
關于亂碼中出現?或者?，這裡需要額外提一下，當程式使用特定字元編碼解析位元組流的時候，一旦遇到無法解析的位元組流時，就會用
或者?來替代。是以，一旦你最終解析得到的文本包含這樣的字元，而你又無法得到原始位元組流的時候，說明正确的資訊已經徹底丢失了，嘗試任何字元編碼都無法從這樣的字元文本中還原出正确的資訊來。
必要的術語解釋
字元集（Character Set），字面上的了解就是字元的集合，例如ASCII字元集，定義了128個字元；GB2312定義了7445個字元。而計算機系統中提到的字元集準确來說，指的是已編号的字元的有序集合（不一定是連續）。
字元碼（Code Point）指的就是字元集中每個字元的數字編号。例如ASCII字元集用0-127這連續的128個數字分别表示128個字元；GBK字元集使用區位碼的方式為每個字元編号，首先定義一個94X94的矩陣，行稱為“區”，列稱為“位”，然後将所有國标漢字放入矩陣當中，這樣每個漢字就可以用唯一的“區位”碼來辨別了。例如“中”字被放到54區第48位，是以字元碼就是5448。而Unicode中将字元集按照一定的類别劃分到0~16這17個層面（Planes）中，每個層面中擁有216=65536個字元碼，是以Unicode總共擁有的字元碼，也即是Unicode的字元空間總共有17*65536=1114112。
編碼的過程是将字元轉換成位元組流。
解碼的過程是将位元組流解析為字元。
字元編碼（Character Encoding）是将字元集中的字元碼映射為位元組流的一種具體實作方案。例如ASCII字元編碼規定使用單位元組中低位的7個比特去編碼所有的字元。例如‘A’的編号是65，用單位元組表示就是0x41，是以寫入儲存設備的時候就是b’01000001’。GBK編碼則是将區位碼（GBK的字元碼）中的區碼和位碼的分别加上0xA0（160）的偏移（之是以要加上這樣的偏移，主要是為了和ASCII碼相容），例如剛剛提到的“中”字，區位碼是5448，十六進制是0x3630，區碼和位碼分别加上0xA0的偏移之後就得到0xD6D0，這就是“中”字的GBK編碼結果。
代碼頁（Code Page）一種字元編碼具體形式。早期字元相對少，是以通常會使用類似表格的形式将字元直接映射為位元組流，然後通過查表的方式來實作字元的編解碼。現代作業系統沿用了這種方式。例如Windows使用936代碼頁、Mac系統使用EUC-CN代碼頁實作GBK字元集的編碼，名字雖然不一樣，但對于同一漢字的編碼肯定是一樣的。
大小端的說法源自《格列佛遊記》。我們知道，雞蛋通常一端大一端小，小人國的人們對于剝蛋殼時應從哪一端開始剝起有着不一樣的看法。同樣，計算機界對于傳輸多位元組字（由多個位元組來共同表示一個資料類型）時，是先傳高位位元組（大端）還是先傳低位位元組（小端）也有着不一樣的看法，這就是計算機裡頭大小端模式的由來了。無論是寫檔案還是網絡傳輸，實際上都是往流裝置進行寫操作的過程，而且這個寫操作是從流的低位址向高位址開始寫（這很符合人的習慣），對于多位元組字來說，如果先寫入高位位元組，則稱作大端模式。反之則稱作小端模式。也就是說，大端模式下，位元組序和流裝置的位址順序是相反的，而小端模式則是相同的。一般網絡協定都采用大端模式進行傳輸，windows作業系統采用Utf-16小端模式。
——Kevin Yang
參考連結：
- The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
- http://developers.sun.com/dev/gadc/technicalpublications/articles/gb18030.html
- http://en.wikipedia.org/wiki/Universal_Character_Set
- http://en.wikipedia.org/wiki/Code_page