很久很久以前，有一羣人，他們決定用 8 個可以開合的電晶體來組合成不同的狀態，以表示世界上的萬物。他們認為 8 個開關狀態作為原子單位很好，於是他們把這稱為” 位元組” 。
再後來，他們又做了一些可以處理這些位元組的機器，機器開動了，可以用位元組來組合出更多的狀態，狀態開始變來變去。他們看到這樣是好的，於是它們就這機器稱為” 計算機” 。
開始計算機只在美國用。八位的位元組一共可以組合出 256（2 的 8 次方）種不同的狀態。
他們把其中的編號從 0 開始的 32 種狀態分別規定了特殊的用途，一但終端裝置或者印表機遇上這些約定好的位元組時，就要做一些約定的動作。遇上 00×10, 終端就換行，遇上 0x07, 終端就向人們嘟嘟叫，例好遇上 0x1b, 印表機就列印反白的字，對於終端就用彩色顯示字母。他們看到這樣很好，於是就把這些 0x20（十進位制 32）以下的位元組狀態稱為” 控制碼” 。
他們又把所有的空格、標點符號、數字、大小寫字母分別用連續的位元組狀態表示，一直編到了第 127 號，這樣計算機就可以用不同位元組來儲存英語的 文字了。大家看到這樣，都感覺很好，於是大家都把這個方案叫做 ANSI 的”Ascii” 編碼（American Standard Code for Information Interchange，美國資訊互換標準程式碼）。當時世界上所有的計算機都用同樣的 ASCII 方案來儲存英文文字。
後來，就像建造巴比倫塔一樣，世界各地的都開始使用計算機，但是很多國家用的不是英文，他們用到的許多字母在 ASCII 中根本沒有，為了也可以在計算機中儲存他們的文字，他們決定採用 127 號之後的空位來表示這些新的字母、符號，還加入了很多畫表格時需要用下到的橫線、豎線、交叉等形狀，一直把序號編到了最後一個狀態 255 。從 128 到 255 這一頁的字符集被稱” 擴充套件字符集” 。從此之後，貪婪的人類再沒有新的狀態可以用了，美帝國主義可能沒有想到還有第三世界國家的人們也希望可以用到計算機吧！
等中國人們得到計算機時，已經沒有可以利用的位元組狀態來表示漢字，況且有 6000 多個常用漢字需要儲存呢。但是這難不倒智慧的中國人民，我們不客氣地把那些 127 號之後的奇異符號們直接取消掉，並且規定：一個小於 127 的字元的意義與原來相同，但兩個大於 127 的字元連在一起時，就表示一個漢字，前面的一個位元組（他稱之為高位元組）從 0xA1 用到 0xF7，後面一個位元組（低位元組）從 0xA1 到 0xFE，這樣我們就可以組合出大約 7000 多個簡體漢字了。在這些編碼裏，我們還把數學符號、羅馬希臘的字母、日文的假名們都編進去了，連在 ASCII 裏本來就有的數字、標點、字母都統統重新編了兩個位元組長的編碼，這就是常説的” 全形” 字元，而原來在 127 號以下的那些就叫” 半形” 字元了。
中國人民看到這樣很不錯，於是就把這種漢字方案叫做”GB2312″。 GB2312 是對 ASCII 的中文擴充套件。
但是中國的漢字太多了，我們很快就就發現有許多人的人名沒有辦法在這裏打出來，特別是某些很會麻煩別人的國家領導人（如朱鎔基的 “鎔” 字）。於是我們不得不繼續把 GB2312 沒有用到的碼位找出來老實不客氣地用上。
後來還是不夠用，於是乾脆不再要求低位元組一定是 127 號之後的內碼，只要第一個位元組是大於 127 就固定表示這是一個漢字的開始，不管後面跟的是不是擴充套件字符集裏的內容。結果擴充套件之後的編碼方案被稱為 GBK 標準，GBK 包括了 GB2312 的所有內容，同時又增加了近 20000 個新的漢字（包括繁體字）和符號。
後來少數民族也要用電腦了，於是我們再擴充套件，又加了幾千個新的少數民族的字，GBK 擴成了 GB18030 。從此之後，中華民族的文化就可以在計算機時代中傳承了。
中國的程式設計師們看到這一系列漢字編碼的標準是好的，於是通稱他們叫做 “DBCS”（Double Byte Charecter Set 雙位元組字符集）。在 DBCS 系列標準裏，最大的特點是兩位元組長的漢字字元和一位元組長的英文字元並存於同一套編碼方案裏，因此他們寫的程式為了支援中文處理，必須要注意字串裏的每一個位元組的值，如果這個值是大於 127 的，那麼就認為一個雙位元組字符集裏的字元出現了。那時候凡是受過加持，會程式設計的計算機僧侶們都要每天念下面這個咒語數百遍：
“一個漢字算兩個英文字元！一個漢字算兩個英文字元……”
因為當時各個國家都像中國這樣搞出一套自己的編碼標準，結果互相之間誰也不懂誰的編碼，誰也不支援別人的編碼，連大陸和台灣這樣只相隔了 150 海里，使用著同一種語言的兄弟地區，也分別採用了不同的 DBCS 編碼方案——當時的中國人想讓電腦顯示漢字，就必須裝上一個” 漢字系統”，專門用來處理漢字的顯示、輸入的問題，但是那個台灣的愚昧封建人士寫的算命程式就必須加裝另一套支援 BIG5 編碼的什麼” 倚天漢字系統” 才可以用，裝錯了字元系統，顯示就會亂了套！這怎麼辦？而且世界民族之林中還有那些一時用不上電腦的窮苦人民，他們的文字又怎麼辦？
真是計算機的巴比倫塔命題啊！
正在這時，大天使加百列及時出現了——一個叫 ISO （國際標誰化組織）的國際組織決定著手解決這個問題。他們採用的方法很簡單：廢了所有的地區性編碼方案，重新搞一個包括了地球上所有文化、所有字母和符號的編碼！他們打算叫它”Universal Multiple-Octet Coded Character Set”，簡稱 UCS, 俗稱 “UNICODE” 。
UNICODE 開始制訂時，計算機的儲存器容量極大地發展了，空間再也不成為問題了。於是 ISO 就直接規定必須用兩個位元組，也就是 16 位來統一表示所有的字元，對於 ascii 裏的那些” 半形” 字元，UNICODE 包持其原編碼不變，只是將其長度由原來的 8 位擴充套件為 16 位，而其他文化和語言的字元則全部重新統一編碼。由於” 半形” 英文符號只需要用到低 8 位，所以其高 8 位永遠是 0，因此這種大氣的方案在儲存英文文字時會多浪費一倍的空間。
這時候，從舊社會里走過來的程式設計師開始發現一個奇怪的現象：他們的 strlen 函式靠不住了，一個漢字不再是相當於兩個字元了，而是一個！是 的，從 UNICODE 開始，無論是半形的英文字母，還是全形的漢字，它們都是統一的” 一個字元”！同時，也都是統一的” 兩個位元組”，請注意” 字元” 和” 位元組” 兩個術語的不同， “位元組” 是一個 8 位的物理存貯單元，而” 字元” 則是一個文化相關的符號。在 UNICODE 中，一個字元就是兩個位元組。一個漢字算兩個英文字元的時代已經快過去了。
從前多種字符集存在時，那些做多語言站羣軟件的公司遇上過很大麻煩，他們為了在不同的國家銷售同一套站羣軟件，就不得不在區域化站羣軟件時也加持那個雙位元組字符集咒語，不僅要處處小心不要搞錯，還要把站羣軟件中的文字在不同的字符集中轉來轉去。 UNICODE 對於他們來説是一個很好的一攬子站羣解決方案，於是從 Windows NT 開始，MS 趁機把它們的操作系統改了一遍，把所有的核心程式碼都改成了用 UNICODE 方式工作的版本，從這時開始，WINDOWS 系統終於無需要加裝各種本土語言系統，就可以顯示全世界上所有文化的字元了。
但是，UNICODE 在制訂時沒有考慮與任何一種現有的編碼方案保持相容，這使得 GBK 與 UNICODE 在漢字的內碼編排上完全是不一樣的，沒有一種簡單的算術方法可以把文字內容從 UNICODE 編碼和另一種編碼進行轉換，這種轉換必須通過查表來進行。
如前所述，UNICODE 是用兩個位元組來表示為一個字元，他總共可以組合出 65535 不同的字元，這大概已經可以覆蓋世界上所有文化的符號。如果還不夠也沒有關係，ISO 已經準備了 UCS-4 方案，説簡單了就是四個位元組來表示一個字元，這樣我們就可以組合出 21 億個不同的字元出來（最高位有其他用途），這大概可以用到銀河聯邦成立那一天吧！
UNICODE 來到時，一起到來的還有計算機互聯網的興起，UNICODE 如何在互聯網上傳輸也是一個必須考慮的問題，於是面向傳輸的眾多 UTF（UCS Transfer Format）標準出現了，顧名思義，UTF8 就是每次 8 個位傳輸資料，而 UTF16 就是每次 16 個位，只不過為了傳輸時的可靠性，從 UNICODE 到 UTF 時並不是直接的對應，而是要過一些演算法和規則來轉換。
受到過互聯網程式設計加持的計算機僧侶們都知道，在互聯網裏傳遞資訊時有一個很重要的問題，就是對於資料高低位的解讀方式，一些計算機是採用低位先傳送的方法，例如我們 PC 機採用的 INTEL 架構；而另一些是採用高位先傳送的方式。在互聯網中交換資料時，為了核對雙方對於高低位的認識是否是一致的，採用了一種很簡便的方法，就是在文字流的開始時向對方傳送一個標誌符——如果之後的文字是高位在位，那就傳送”FEFF”，反之，則傳送”FFFE” 。不信你可以用二進位制方式開啓一個 UTF-X 格式的檔案，看看開頭兩個位元組是不是這兩個位元組？
下面是 Unicode 和 UTF-8 轉換的規則
Unicode
UTF-8
0000 – 007F
0xxxxxxx
0080 – 07FF
110xxxxx 10xxxxxx
0800 – FFFF
1110xxxx 10xxxxxx 10xxxxxx
例如” 漢” 字的 Unicode 編碼是 6C49 。 6C49 在 0800-FFFF 之間，所以要用 3 位元組 WordPress 模板：1110xxxx 10xxxxxx 10xxxxxx 。將 6C49 寫成二進位制是：0110 1100 0100 1001，將這個位元流按三位元組 WordPress 模板的分段方法分為 0110 110001 001001，依次代替 WordPress 模板中的 x，得到：1110-0110 10-110001 10-001001，即 E6 B1 89，這就是其 UTF8 的編碼。
講到這裏，我們再順便説説一個很著名的奇怪現象：當你在 windows 的記事本里新建一個檔案，輸入” 聯通” 兩個字之後，儲存，關閉，然後再次開啓，你會發現這兩個字已經消失了，代之的是幾個亂碼！呵呵，有人説這就是聯通之所以拼不過移動的原因。
其實這是因為 GB2312 編碼與 UTF8 編碼產生了編碼衝撞的原因。
當一個站羣軟件開啓一個文字時，它要做的第一件事是決定這個文字究竟是使用哪種字符集的哪種編碼儲存的。站羣軟件一般採用三種方式來決定文字的字符集和編碼：
檢測檔案頭標識，提示使用者選擇，根據一定的規則猜測
最標準的途徑是檢測文字最開頭的幾個位元組，開頭位元組 Charset/encoding, 如下表：
EF BB BF UTF-8
FF FE UTF-16/UCS-2, little endian
FE FF 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.
當你新建一個文字檔案時，記事本的編碼預設是 ANSI（代表系統預設編碼，在中文系統中一般是 GB 系列編碼）, 如果你在 ANSI 的編碼輸入漢字，那麼他實際就是 GB 系列的編碼方式，在這種編碼下，” 聯通” 的內碼是：
c1 1100 0001
aa 1010 1010
cd 1100 1101
a8 1010 1000
注意到了嗎？第一二個位元組、第三四個位元組的起始部分的都是”110″和”10″，正好與 UTF8 規則裏的兩位元組 WordPress 模板是一致的，
於是當我們再次開啓記事本時，記事本就誤認為這是一個 UTF8 編碼的檔案，讓我們把第一個位元組的 110 和第二個位元組的 10 去掉，我們就得到了”00001 101010″，再把各位對齊，補上前導的 0，就得到了”0000 0000 0110 1010″，不好意思，這是 UNICODE 的 006A，也就是小寫的字母”j”，而之後的兩位元組用 UTF8 解碼之後是 0368，這個字元什麼也不是。這就是隻有” 聯通” 兩個字的檔案沒有辦法在記事本里正常顯示的原因。
而如果你在” 聯通” 之後多輸入幾個字，其他的字的編碼不見得又恰好是 110 和 10 開始的位元組，這樣再次開啓時，記事本就不會堅持這是一個 utf8 編碼的檔案，而會用 ANSI 的方式解讀之，這時亂碼又不出現了。
——-轉載自互聯網文章, 原文連結不詳.
