下載一個文檔，一打開發(fā)現(xiàn)是亂碼，不抓狂才怪…… 你們都知道，這都是字符編碼闖的禍。ASCII、ANSI、GB18030、Unicode、UTF-8、UTF-8 with BOM、UTF without BOM、UTF-16、UTF-16LE、UTF-16BE…… 一大坨的誰分得清？聽說UTF-8就是Unicode，但怎么Windows記事本里的保存選項(xiàng)有UTF-8和Unicode兩個選項(xiàng)呀？！究竟各種軟件是怎樣判斷一個文件是什么編碼呢？為什么有時(shí)候又判斷錯誤呢？讓我一一道來。
世界上本沒有字符編碼。自從有了計(jì)算機(jī)，我們有了用0和1記錄文字的需求，于是字符就有了編碼。
== ASCII ==
ASCII編碼表示的“Hello GuoKr”（十進(jìn)制）：72 101 108 111 32 71 117 111 75 114
ASCII是最基本的編碼，它定義了0～127對應(yīng)的字符，包括最基本的英文字母、標(biāo)點(diǎn)符號。它無法表示中文。ASCII編碼的文本，每一個字節(jié)都是0～127，如果某個字節(jié)大于127，那它一定不是ASCII編碼。
== GB* / ANSI ==
為了用計(jì)算機(jī)記錄并顯示中文，中國人發(fā)明了GB系列編碼。GB系列編碼定義了中文漢字、標(biāo)點(diǎn)的編碼。按照GB系列編碼，在一段文本中，如果一個字節(jié)是0～127，那么這個字節(jié)的含義同ASCII編碼，否則，這個字節(jié)和下一個字節(jié)共同組成漢字（或是GB編碼定義的其他字符）。因此，GB系列編碼向下兼容ASCII，也就是說，如果一段用GB編碼文本里的所有字符都在ASCII中有定義，那么這段編碼和ASCII編碼完全一樣。GB編碼早期收錄的漢字不足一萬個，基本滿足日常使用需求，但不包含一些生僻的字，后來在一個個新版本中加進(jìn)去。最早的GB編碼是GB2312，后來有GBK，最新的是GB18030，加入了一些國內(nèi)少數(shù)民族的文字，一些生僻字被編到4個字節(jié)，每擴(kuò)展一次都完全保留之前版本的編碼，所以每個新版本都向下兼容。
同樣，日文、韓文、世界各國文字都有了它們各自的編碼（如果ASCII不能滿足使用要求的話）。這些編碼都和GB編碼相似，兼容ASCII并用兩個字節(jié)表示一個字。所有這些各國文字編碼，微軟統(tǒng)稱為ANSI 。所以即使知道是ANSI，我們還需要知道這是哪國文字才能解碼，因?yàn)檫@些編碼都互相沖突。另外，你無法用一段ANSI 編碼表示既有漢字、又有韓字的文本。
等等，上面我誤導(dǎo)大家了……其實(shí)是微軟誤導(dǎo)大家了，嚴(yán)格來說ANSI 不是字符編碼，而是美國一個非營利組織，他們做了很多標(biāo)準(zhǔn)制定工作，包括C語言規(guī)范ANSI C，還有各國文字編碼對應(yīng)的“代碼頁”（code page）。ANSI 規(guī)定簡體中文GB編碼的代碼頁是936，所以GB編碼又叫做ANSI code page 936（按ANSI標(biāo)準(zhǔn)的代碼頁936），各國編碼被統(tǒng)稱為ANSI 由來于此——這是個離譜的歷史錯誤，這就像我自己給國內(nèi)的大學(xué)做了個排名，排名的依據(jù)是飯?zhí)贸猿鱿x子的概率，然后國內(nèi)的大學(xué)就被統(tǒng)稱為黃油貓。不過對于這些亂七八糟互相沖突的多國字符編碼，有個統(tǒng)稱還是不錯的（我了個去還要謝謝微軟），下面討論姑且繼續(xù)使用ANSI 。
==Unicode / UTF / UCS==
為了解決沖突的問題，促進(jìn)世界和平，我們有了Unicode（聯(lián)合碼？）——一種將全世界所有語言所有字符都收錄在一起、讓它們和平共處的編碼……哦，等等，Unicode雖是一種字符編碼，但嚴(yán)格來說它和GB18030不能相提并論：它只定義了每一個字符對應(yīng)一個整數(shù)（目前包含了十萬多個字符，其中0～127和ASCII完全一樣），但它沒有定義這個整數(shù)如何變成字節(jié)。當(dāng)你告訴我這段數(shù)據(jù)是Unicode編碼，啊，不好意思，我還是不知道該怎么解碼——因?yàn)樽兂勺止?jié)流的格式不只一種，它們都叫做“Unicode轉(zhuǎn)換格式”（Unicode Transformation Format，簡稱為UTF）。
所以這里面就有了一大堆UTF：UTF-8、UTF-8 with BOM、UTF-8 without BOM、UTF-16、UTF-16LE、UTF-16BE…… 還有很少見的UTF-32、，早期還會聽說過UCS-2、UCS-4…… _(:з」∠)_
等等，為什么Windows記事本里有個保存選項(xiàng)是Unicode？這個稍后說。
先說最常見的UTF-8：它將一個字符編為1-4個字節(jié)，其中一個字節(jié)的字符和ASCII 完全一致，所以它也向下兼容ASCII。和ANSI類似，UTF-8第一個字節(jié)決定了之后多少個字節(jié)是一組好基友。多數(shù)漢字在UTF-8里為3個字節(jié)，有一些生僻的漢字會編到4字節(jié)。
我們迎來第一種不兼容ASCII的編碼：UTF-16。UTF-16以每2個字節(jié)為一個單元，每個字符由1-2個單元組成，所以每個字符可能是2個字節(jié)或者4個字節(jié)，包括最常見的英文字母都會編成兩個字節(jié)。大部分漢字也是2個字節(jié)，少部分生僻字為4個字節(jié)。UTF-16還有講究，一個單元中的兩個字節(jié)的順序不是唯一的。學(xué)過計(jì)算機(jī)原理的同學(xué)知道，計(jì)算機(jī)中表示一個整數(shù)分兩種格式：低位在前高位在后，或者反過來。例如用兩個字節(jié)表示260這個整數(shù)，可能是：
低位在前：04 01 （260=4+256*1）
高位在前：01 04 （260=256*1+4）
低位在前的UTF-16叫UTF-16LE，高位在前的叫UTF-16BE。目前絕大部分的計(jì)算機(jī)系統(tǒng)都使用低位在前的整數(shù)格式，所以如果沒有聲明，UTF-16默認(rèn)是LE。
早期Unicode收編的字還不多時(shí)，兩個字節(jié)足夠表示所有字符，所以有一種固定為兩個字節(jié)的UTF，叫UCS-2。UTF-16的兩個字節(jié)部分和UCS-2完全一樣，所以UTF-16向下兼容UCS-2。UCS-2同樣分LE和BE。而Windows的記事本還有Windows其它地方所謂的Unicode，當(dāng)代的Windows里其實(shí)是UTF-16LE，在Windows XP和更早的版本里是UCS-2LE。微軟（又是微軟）正是混淆Unicode概念的禍?zhǔn)?，微軟你這么討厭你家人知道嗎？
此外，UTF-32和UCS-4固定為4個字節(jié)一個字符，同樣分LE和BE。
還沒完，這么多字符編碼，軟件打開時(shí)如何知道是哪個編碼？于是不知道誰蹲坑時(shí)想出了BOM：在一個文本文件或者一段字符編碼前加上幾個固定的字節(jié)用于識別，這些字節(jié)保證不對應(yīng)任何一個字符，所以軟件一讀就能驗(yàn)明正身：
EF BB BF － 我是UTF-8
FF FE － 我是UTF-16LE
FE FF － 我是UTF-16BE
（沒有BOM，直奔主題）－你猜？
不錯，沒BOM只能靠猜了。軟件讀入文件時(shí)可以所有編碼都試一下，看哪個像。另外，BOM只針對Unicode系列編碼，ANSI通通不會有BOM。很顯然，沒有BOM難免偶然猜錯。網(wǎng)上就流傳了一個神奇的段子：打開Windows記事本，打入“聯(lián)通”兩個字，保存，關(guān)閉，再打開，變成了個黑塊。記事本用ANSI（GB18030）保存聯(lián)通這兩個字，剛好這兩個字的GB18030編碼看起來很像UTF-16，于是就當(dāng)成UTF-16來打開……
BOM聽起來很不錯，但實(shí)際是個討厭的設(shè)計(jì)，因?yàn)樗秃芏鄥f(xié)議、規(guī)范不兼容，這是題外話。
于是，UTF-8 with BOM、UTF-16 without BOM 你們就懂了。等等，如果不提BOM，究竟有BOM還是沒有BOM？—— 又是一個十分糾結(jié)的問題，Windows里的軟件一般都默認(rèn)有BOM，而其它系統(tǒng)都默認(rèn)沒有BOM——可能是因?yàn)閃indows常要兼容ANSI的原因，特別依賴BOM來防止會錯意。
==誰是正統(tǒng)==
這么多種編碼，用來寫文章就罷了，打開個文檔看到亂碼就退出、換個程序或者換個編碼再打開；但寫程序時(shí)可半點(diǎn)馬虎不得，各種程序開發(fā)環(huán)境對編碼支持都不一樣，如果編碼沒搞好，你寫好的程序可能在別人計(jì)算機(jī)上就運(yùn)行不起來了。如果我開發(fā)跨平臺的代碼，而且要有中文（注釋），哪用什么編碼好？以下是我所知道各開發(fā)環(huán)境／編譯器支持常見編碼情況（所有＝ANSI、UTF-8 BOM and no BOM、UTF-16LE BOM and no BOM）：
ANSI是無法跨境的，用GB寫的文檔拿去韓國就果斷亂碼了。光是簡體中文系統(tǒng)，ANSI 也是經(jīng)常被認(rèn)錯的，Eclipse里經(jīng)常（不總是）出現(xiàn)打開ANSI 文件是亂碼的情況，這是因?yàn)锳NSI 沒有很明顯的特征。XCode和Mac的文本編輯器打開ANSI 直接是亂碼，因?yàn)槊鞔_不支持。ANSI 容錯性普遍比較差，一個字節(jié)錯了可能導(dǎo)致后面的字通通掛掉。為了防止Eclipse等發(fā)神經(jīng)，也為免跨國帶來麻煩，更為了你自己的數(shù)據(jù)安全，請遠(yuǎn)離ANSI。
UTF-16不兼容ASCII，不兼容C語言的字符串處理庫函數(shù)（因?yàn)樽止?jié)流里有\(zhòng)0），除了Windows愛用，其它系統(tǒng)都痛恨它。BOM和很多協(xié)議規(guī)范沖突，很多軟件都抵制，也是只有Windows常用，而且將其列為正統(tǒng)（作反）。
綜上，跨平臺開發(fā)請使用UTF-8 without BOM，那是最通用的編碼，是很多軟件系統(tǒng)的默認(rèn)編碼，你在看的網(wǎng)頁也用它。它特征明顯，除了VC編譯器和微軟的各種軟件外暫時(shí)沒發(fā)現(xiàn)哪個軟件會有認(rèn)錯的情況。它還有經(jīng)過精心設(shè)計(jì)的容錯機(jī)制，錯一個字節(jié)最多只會錯一個字符。請手動設(shè)置你的開發(fā)環(huán)境，將默認(rèn)保存的編碼設(shè)為UTF-8 without BOM，并將其它編碼的文件轉(zhuǎn)換過來，亂碼就拜拜啦；記事本等不支持的編輯器，不要讓他們摸你的文件。至于VC編譯器硬要鬧別扭就由它去吧 _(:з」∠)_
（經(jīng)過測試，VS2010能正常打開UTF-8 without BOM的代碼，但可能編譯不通過，并報(bào)奇怪的編譯錯誤）
為什么程序猿那么喜歡黑微軟??？因?yàn)槲④浤侨簮烌}的設(shè)計(jì)師總是和大家不太一樣……
寫在最后：
在這個機(jī)器能聽懂人語的年代，我們還要操心字符編碼這么低級的事，真是不可思議…… 解決方案這么簡單：幾家大公司坐一圈，說定一種編碼，以后通通用一種編碼。而且這種編碼已經(jīng)浮出水面、支持成熟：UTF-8。我很贊賞蘋果，他們果斷和ANSI還有一大堆不統(tǒng)一的編碼一刀兩段，所有軟件只支持UTF-8，這才是真正對用戶負(fù)責(zé) —— 而微軟到今天還死抱著ANSI不放，在這件小事上就看出他就是如此不舍得過去一點(diǎn)的成就，如此不舍得革自己的命。
