每個程序員都絕對必須知道的關於字符集和Unicode的那點兒事（別找藉口！）
Unicode與字符集
你曾經是否覺得HTML中的"Content-Type"標籤充滿神祕？雖然你知道這個東西必須出現在HTML中，但對於它到底幹嗎你可能一無所知。
你是否曾經收到過來自你保加利亞朋友的郵件，到處都是"???? ?????? ??? ????"?
我很失望，因爲我發現許多軟件開發人員到現在爲止都還沒有對字符集、編碼、Unicode有一個清晰的認識，這是個事實。幾年前，在測試FogBUGZ項目時，忽然想看看它能不能接收用日文寫的電子郵件。這個世界上會有人用日文寫電子郵件？我不知道。測試結果很糟糕。我仔細看了用來解析MIME (Multipurpose Internet Mail Extenisons)格式的郵件所用的ActiveX控件，發現了它在字符集上面做的蠢事。於是我們不得不重新寫一段代碼，先消除Active控件的錯誤，然後再完成正確的轉換。類似的事情在我研究另一個商業庫的時候同樣發生了，這個庫關於字符編碼這部分的實現簡直糟透了。我找到它的開發者，把存在問題的包指給他，他卻表示對於此無能爲力。像很多程序員一樣，他只希望這個缺陷會被人們遺忘。
事實並非如他所願。因爲我發現，像PHP這麼流行的網頁開發工具，竟然在實現上也完全忽略了多種字符編碼的存在（譯者注：這篇文章寫於2003年，現在的 PHP可能已經糾正了這個問題吧），盲目地只使用8個比特來表示字符，於是開發優秀的國際化的Web應用程序變成了一場夢。我想說，受夠了。
我申明：在2003年，如果你是一個程序員，但你卻對字符、字符集、編碼和Unicode一無所知，那麼你別讓我抓到你。如果落在我手裏，我會讓你待在潛水艇裏剝六個月的洋蔥，我發誓。
另外，還有一件事：
在這篇文章裏，我所講的是每一個工作中的程序員都應該知道的知識。所有以爲"純文本 = ASCII碼 = 一個字符就是8比特"的人不單單錯了，而且錯得離譜。如果你仍然堅持使用這種方式編寫程序，那麼你比一個不相信細菌的存在醫生好不到哪裏去。所以在你讀完這篇文章以前，不要再寫半行代碼。
在我開始之前，必須說明白，如果你已經瞭解了國際化，可能你會覺得這篇文章過於簡單。沒錯，我的的確確是想架一座最短的橋，讓任何人都可以理解發生了什麼事，懂得如何寫出可以在非英文語言環境是正常工作的代碼。還得指出，字符處理僅僅是軟件國際化中的一小部分，但一口吃不成個胖子，今天我們只看什麼是字符集。
歷史回顧
可能你以爲我要開始談非常古老的字符集如EBCDIC之類的，實際上我不會。EBCDIC與你的生活無關，我們不需要回到那麼遠。
回到一般遠就行了。當Unix剛出來的時候，K&R寫了《The C Programming Language》一書，那時一切都很簡單。EBCDIC已經慚慚不用，因爲需要表示的字符只有那些不帶重音的英文字母，ASCII完全可以勝任。ASCII使用數字32到 127來表示所有的英文字母，比如空格是32，字母"A"是65等等。使用7個比特就可以存儲所有這樣字符。那個時代的大多數計算機使用8個比特來，所以你不但可以存儲全部的ASCII，而且還有一個比特可以多出來用作其他。如果你想，你可以把它用作你不可告人的目的。32以下的碼字是不可打印的，它們屬於控制字符，像7表示響鈴，12表示打印機換紙。
所有的一切都看起來那麼完美，當然前提你生在一個講英文的國家。
因爲一個字節有8個比特，而現在只用了7個，於是很多人就想到"對呀，我們可以使用128-255的碼字來表示其他東西"。麻煩來了，這麼多人同時出現了這樣的想法，而且將之付諸實踐。於是IBM-PC上多了一個叫OEM字符集的東西，它包括了一些在歐洲語言中用到的重音字符，還有一些畫圖的字符，比如水平線、垂直線等，水平線在右端會帶一個小彎鉤，垂直線會如何等等。使用這些畫圖字符你可以畫出漂亮的框、畫出光滑的線條，在老式的烘乾機上的8088電腦上你依然可以看到這些字符。事實上，當PC在美國之外的地方開始銷售的時候，OEM字符集就完全亂套了，所有的廠商都開始按照自己的方式使用高128個碼字。比如在有些PC上，130表示é，而在另外一些在以色列出售的計算機上，它可能表示的是希伯來字母ג，所以當美國人把包含résumés這樣字符的郵件發到以色列時，就爲變爲rגsumגs。在大多數情況下，比如俄語中，高128個碼字可能用作其他更多的用途，那麼你如何保證俄語文檔的可靠性呢？
最終ANSI標準結束了這種混亂。在標準中，對於低128個碼字大家都無異議，差不多就是ASCII了，但對於高128個碼字，根據你所在地的不同，會有不同的處理方式。我們稱這樣相異的編碼系統爲碼頁(code pages)。舉個例子，比如在以色列發佈的DOS中使用的碼頁是862，而在希臘使用的是737。它們的低128個完全相同，但從128往上，就有了很大差別。MS-DOS的國際版有很多這樣的碼頁，涵蓋了從英語到冰島語各種語言，甚至還有一些"多語言"碼頁。但是還得說，如果想讓希伯來語和希臘語在同一臺計算機上和平共處，基本上沒有可能。除非你自己寫程序，程序中的顯示部分直接使用位圖。因爲希伯來語對高128個碼字的解釋與希臘語壓根不同。
同時，在亞洲，更瘋狂的事情正在上演。因爲亞洲的字母系統中要上千個字母，8個比特無論如何也是滿足不了的。一般的解決方案就是使用DBCS- "雙字節字符集"，即有的字母使用一個字節來表示，有的使用兩個字節。所以處理字符串時，指針移動到下一個字符比較容易，但移動到上一個字符就變得非常危險了。於是s++或s--不再被鼓勵使用，相應的比如Windows下的AnsiNext和AnsiPrev被用來處理這種情況。
可惜，不少人依然堅信一個字節就是一個字符，一個字符就是8個比特。當然，如果你從來都沒有試着把一個字符串從一臺計算機移到另一臺計算機，或者你不用說除英文以外的另一種語言，那麼你的堅信不會出問題。但是互聯網出現讓字符串在計算機間移動變得非常普遍，於是所有的混亂都爆發了。非常幸運，Unicode適時而生。
Unicode
Unicode 是一個勇敢的嘗試，它試圖用一個字符集涵蓋這個星球上的所有書寫系統。一些人誤以爲Unicode只是簡單的使用16比特的碼字，也就是說每一個字符對應 16比特，總共可以表示65536個字符。這是完全不正確的。不過這是關於Unicode的最普遍的誤解，如果你也這樣認爲，不用感到不好意思。
事實上，Unicode使用一種與之前系統不同的思路來考慮字符，如果你不能理解這種思路，那其他的也就毫無意義了。
到現在爲止，我們的做法是把一個字母映射到幾個比特，這些比特可以存儲在磁盤或者內存中。
A -> 0100 0001
在Unicode中，一個字母被映射到一個叫做碼點(code point)的東西，這個碼點可以看作一個純粹的邏輯概念。至於碼點(code point)如何在內存或磁盤中存儲是另外的一個故事了。
在Unicode中，字母A可看做是一個柏拉圖式的理想，僅存在於天堂之中：（我的理解是字母A就是一個抽象，世界上並不存在這樣的東西，如果數學裏面的0、1、2等一樣）
這個柏拉圖式的A與B不同，也與a不同，但與A和A相同。這個觀點就是Times New Roman字體中的A與Helvetica字體中的A相同，與小寫的"a"不同，這個應該不會引起太多的異議。但在一些語言中，如何辨別一個字母會有很大的爭議。比如在德語中，字母 ß是看做一個完整的字母，還是看做ss的一種花式寫法？如果在一個字母的形狀因爲它處在一個單詞的末尾而略有改變，那還算是那個字母嗎？阿拉人說當然算了，但希伯來人卻不這麼認爲。但無論如何，這些問題已經被Unicode委員會的這幫聰明人給解決了，儘管這花了他們十多年的時間，儘管其中涉及多次政治味道很濃的辯論，但至少現在你不用再爲這個操心了，因爲它已經被解決。
每一個字母系統中的每一個柏拉圖式的字母在Unicode中都被分配了一個神奇的數字，比如像U+0639。這個神奇數字就是前面提到過的碼點(code point)。U+的意思就是"Unicode"，後面跟的數字是十六進制的。U+0639表示的是阿拉伯字母Ain。英文字母A在Unicode中的表示是U+0041。你可以使用Windows 2000/XP自帶的字符表功能或者Unicode的官方網站(www.unicode.org)來查找與字母的對應關係。
事實上Unicode可以定義的字符數並沒有上限，而且現在已經超過65536了。顯然，並不是任何Unicode字符都可以用2個字節來表示了。
舉個例子，假設我們現在有一個字符串：
在Unicode中，對應的碼點(code point)如下：
瞧，僅僅是一堆碼點而已，或者說數字。不過到現在爲止，我們還沒有說這些碼點究竟是如何存儲到內存或如何表示在email信息中的。
編碼
要存儲，編碼的概念當然就被引入進來。
Unicode最早的編碼想法，就是把每一個碼點(code point)都存儲在兩個字節中，這也就導致了大多數人的誤解。於是Hello就變成了：
這樣對嗎？如下如何？
技術上說，我相信這樣是可以的。事實上，早期的實現者們的確想把Unicode的碼點(code point)按照大端或小端兩種方式存儲，這樣至少已經有兩種存儲Unicode的方法了。於是人們就必須使用FE FF作爲每一個Unicode字符串的開頭，我們稱這個爲Unicode Byte Order Mark。如果你互換了你的高位與低位，就變成了FF FE，這樣讀取這個字符串的程序就知道後面字節也需要互換了。可惜，不是每一個Unicode字符串都有字節序標記。
現在，看起來好像問題已經解決了，可是這幫程序員仍在抱怨。"看看這些零！"他們會這樣說，因爲他們是美國人，他們只看不會碼點不會超過U+00FF的英文字母。同時他們也是California的嬉皮士，他們想節省一點。如果他們是得克薩斯人，可能他們就不會介意兩倍的字節數。但是這樣California節儉的人卻無法忍受字符串所佔空間翻倍。而且現在大堆的文檔使用的是ANSI和DBCS字符集，誰去轉換它們？於是這幫人選擇忽略Unicode，繼續自己的路，這顯然讓事情變得更糟。
於是非常聰明的UTF-8的概念被引入了。UTF-8是另一個系統，用來存儲字符串所對應的Unicode的碼點 (code points)-即那些神奇的U+數字組合，在內存中，而且存儲的最小單元是8比特的字節。在UTF-8中，0-127之間的碼字都使用一個字節來存儲，超過128的碼字使用2,3甚至6個字節來存儲。
這顯然有非常好的效果，因爲英文的文本使用UTF-8存儲的形式完全與ASCII一樣了，所以美國人壓根不會注意到發生了什麼變化。舉個例子，Hello -- U+0048 U+0065 U+006C U+006C U+006C U+006F，將會被存儲爲48 65 6C 6C 6F，這與ASCII、與ANSI標準、與所有這個星球上的OEM字符集顯然都是一樣的。現在，如果你需要使用希臘字母，你可以用幾個字節來存儲一個碼字，美國人永遠都不會注意到。（幹嗎得美國人注意，無語，美國人寫的文章...）
到現在我已經告訴了你三種Unicode的編碼方式，傳統的使用兩個字節存儲的稱之爲UCS-2或者UTF-16，而且你必須判斷空間是大端的UCS-2還是小端的UCS-2。新的UTF-8標準顯然更流行，如果你恰巧有專門面向英文的程序，顯然這些程序不需要知道UTF-8的存在依然可以工作地很好。
事實上，還有其它若干對Unicode編碼的方法。比如有個叫UTF-7，和UTF-8差不多，但是保證字節的最高位總是0,這樣如果你的字符不得不經過一些嚴格的郵件系統時（這些系統認爲7個比特完全夠用了），就不會有信息丟失。還有一個UCS-4，使用4個字節來存儲每個碼點(code point)，好處是每個碼點都使用相同的字節數來存儲，可惜這次就算是得克薩斯人也不願意了，因爲這個方法實在太浪費了。
現在的情況變成了你思考事情時所使用的基本單元--柏拉圖式的字母已經被Unicode的碼點完全表示了。這些碼點也可以完全使用其它舊的編碼體系。比如，你可以把 Hello對應的Unicode碼點串(U+0048 U+0065 U+006C U+006C U+006F)用ASCII、OEM Greek、Hebrew ANSI或其它上百個編碼體系來編碼，不過需要注意一點，有些字母會無法顯示。如果你要表示的Unicode碼點在你使用的編碼體系中壓根沒有對應的字符，那麼你可能會得到一個小問號"?"，或者得到一個"�"。
許多傳統的編碼體系僅僅能編碼Unicode碼點中的一部分，其餘全部會被顯示爲問號。比較流行的英文編碼體系有Windows-1252（Windows 9x中的西歐語言標準）和ISO-8859-1，還有aka Latin-1。但是如果想用這些編碼體系來編碼俄語或者希伯來語就只能得到一串問號了。UTF 7，8，16，和32都可以完全正確編碼Unicode中的所有碼點。
關於編碼的唯一事實
如果你完全忘掉了我剛剛解釋過的內容，沒有關係，請記住一點，如果你不知道一個字符串所使用的編碼，這個字符串在你手中也就毫無意義。你不能再把腦袋埋進沙中以爲"純文本"就是ASCII。事實上，
那麼我們如何得知一個字符串所使用的空間是何種編碼呢？對於這個問題已經有了標準的作法。如果是一份電子郵件，你必須在格式的頭部有如下語句：
Content-Type: text/plain; charset="UTF-8"
對於一個網頁，傳統的想法是Web服務器會返回一個類似於Content-Type的http頭和Web網頁，注意，這裏的字符編碼並不是在HTML中指出，而是在獨立的響應headers中指出。
這帶來了一些問題。假設你擁有一個大的Web服務器，擁有非常多的站點，每個站點都包括數以百計的Web頁面，而寫這些頁面的人可能使用不同的語言，他們在他們自己計算機上的FrontPage等工具中看到頁面正常顯示就提交了上來，顯然，服務器是沒有辦法知道這些文件究竟使用的是何種編碼，當然 Content-Type頭也沒有辦法發送了。
如果可以把Content-Type夾在HTML文件中，那不是會變得非常方便？這個想法會讓純粹論者發瘋，你如何在不知道它的編碼的情況下讀一個HTML文件呢？答案很簡單，因爲幾乎所有的編碼在32-127的碼字都做相同的事情，所以不需要使用特殊字符，你可以從HTML文件中獲得你想要的Content-Type。
<html>
<head>
<meta http-equiv="Conent-Type" content="text/html" charset="utf-8">
注意，這裏的meta標籤必須在head部分第一個出現，一旦瀏覽器看到這個標籤就會馬上停止解析頁面，然後使用這個標籤中給出的編碼從頭開始重新解析整個頁面。
如果瀏覽器在http頭或者meta標籤中都找不到相關的Content-Type信息，那應該怎麼辦？Internet Explorer做了一些事情：它試圖猜測出正確的編碼，基於不同語言編碼中典型文本中出現的那些字節的頗率。因爲古老的8比特的碼頁(code pages)傾向於把它們的國家編碼放置在128-255碼字的範圍內，而不同的人類語言字母系統中的字母使用頗率對應的直方圖會有不同，所以這個方法可以奏效。雖然很怪異，但對於那些老忘記寫Content-Type的幼稚網頁編寫者而言，這個方法大多數情況下可以讓他們的頁面顯然OK。直到有一天，他們寫的頁面不再滿足"letter-frequency-distribution"，Internet Explore覺得這應該是朝鮮語，於是就當朝鮮語來顯示了，結果顯然糟透了。這個頁面的讀者們立刻就遭殃了，一個保加利亞語寫的頁面卻用朝鮮語來顯示，效果會怎樣？於是讀者使用 查看-->編碼 菜單來不停地試啊試，直到他終於試出了正確的編碼，但前提是他知道可以這樣做，事實上大多數人根本不會這樣做。
在我的公司開發的一款Web頁面管理軟件CityDesk的最新版本中，我們決定像Visual Basic、COM和Windows NT/2000/XP所做的那樣，整個過程中使用UCS-2（兩個字節）Unicode。在我們寫的C++代碼中，我們把所有的char類型換成了wchar_t，所有使用str函數的地方，換成了相應的wcs函數（如使用wcscat和wcslen來替代strcat和strlen）。如果想在C中創建一個UCS-2的字符串，只需在字符串前面加L即可：L"Hello"。
當CityDesk發佈頁面的時候，它把所有的頁面都轉換成了UTF-8編碼，而差不多所有的瀏覽器都對UTF-8有不錯的支持。這就是"Joel On Software"（就是作者的首頁）編碼的方式，所以即使它擁有29個語言版本，至今也未聽到有一個人抱怨頁面無法瀏覽。
這篇文章已經有點長了，而且我也沒有辦法告訴你關於字符編碼和Unicode的所有應該瞭解的知識，但讀到現在我想你已經掌握到基本的概念，回去編程時可以使用抗生素而不是螞蝗和咒語了，這就看做是留給你的作業吧。
作者：Joel Spolsky
原文地址 http://www.joelonsoftware.com/articles/Unicode.html
