關(guān)于Windows Notepad里可選的字符編碼

▲ Windows Notepad的編碼包含ANSI、Unicode、Unicode big endian和UTF-8。

警告

本文僅僅闡述一個廣泛使用的軟件的技術(shù)事實(shí)，不代表作者支持或反對使用該軟件。
事實(shí)上作者推薦任何時(shí)候都不使用 Windows Notepad 來處理計(jì)算機(jī)程序代碼。
本文僅在某一個簡體中文版64位Windows 7的實(shí)例下驗(yàn)證，僅供參考。不保證在其他相同或相異系統(tǒng)下能夠重現(xiàn)一致的結(jié)果。

注意

本文嚴(yán)格區(qū)分Unicode的編碼和字節(jié)序列化。
Unicode的編碼僅指使用數(shù)（通常寫成16進(jìn)制數(shù)）來一對一的代表字符的工作。這個數(shù)的范圍僅受Unicode標(biāo)準(zhǔn)的約束，與計(jì)算機(jī)毫無關(guān)聯(lián)。
Unicode的字節(jié)序列化指為了能夠?qū)懭胗?jì)算機(jī)存儲器，而把一個Unicode標(biāo)準(zhǔn)范圍內(nèi)的數(shù)，表示成N個字節(jié)的工作。

測試用例

測試用例為：“錕斤拷【斷行】a【斷行】”。（錕斤拷是一種信仰。）

所有字符的GBK和Unicode編碼為：

• 錕 GBK=EFBF Unicode=U+951F
• 斤 GBK=BDEF Unicode=U+65A4
• 拷 GBK=BFBD Unicode=U+62F7

以下ASCII字符的GBK和Unicode編碼與ASCII一致：

a=0x61 CR=0x0D LF=0x0A ?（Windows一個換行符占有兩個字符：CR+LF）

ANSI

在簡體中文系統(tǒng)下，ANSI就是中華人民共和國國家標(biāo)準(zhǔn)定義的GBK編碼。

Windows Notepad使用ANSI存儲這個文件的結(jié)果如下：

EF BF  BD EF  BF BD  0D  0A  61  0D  0A -----  -----  -----  --  --  --  --  --

簡單的使用GBK編碼存儲了所有的字符。最高位不是1的單字節(jié)并等同于ASCII，否則雙字節(jié)。

這里要注意字節(jié)序（Endian）的問題[注A]。可以看到這里的字節(jié)序是大端在先（big-endian）的。

但是不必特意強(qiáng)調(diào)“大端在先的GBK”——因?yàn)閺腉B2312開始，標(biāo)準(zhǔn)就規(guī)定了存儲方式是大端在先的[注B]。后來的GBK和GB18030-2000向下兼容。

ANSI的麻煩就是依賴系統(tǒng)——其他語言系統(tǒng)的ANSI就不是GBK了，打開GBK的文件必然亂碼。并且GBK的字符集本身也太小。
（千萬不要說“我只用中文”——少了Unicode那些符號，網(wǎng)上那些顏文字都打不出來）

Unicode系列

Windows Notepad所說的“Unicode”、“Unicode big endian”和UTF-8，全都是同樣的Unicode編碼的不同的字節(jié)序列化存儲方法。

UTF-16 和 bom

這里的Unicode指UTF-16[注C]。UTF-16是極其簡單粗暴的序列化方法——絕大多數(shù)的Unicode字符都在U+0000~U+FFFF的范圍內(nèi)[注D]，那就每個字符用兩個字節(jié)，把Unicode編碼的原始值寫盤。

注意ASCII字符也必須浪費(fèi)一倍的空間存儲高8位的0x00——因?yàn)槿绻迅?位的0略了，解析時(shí)就再也沒有其他的依據(jù)去斷字。

對于UTF-16就存在大端和小端的問題了——UTF-16并不規(guī)定字節(jié)的大端在前還是小端在前。但UTF-16并不包含表示字節(jié)序的信息，總不能人工看看哪個解析是不亂碼的吧……

Unicode提供的解決方式是，把一個零寬無斷字空格符（U+FEFF ZERO WIDTH NO-break SPACE）以UTF-16的方式序列化之后，塞到文件的最前邊。這樣UTF-16解析器讀取文件的前兩個字節(jié)，如果是FE FF就是大端在前，F(xiàn)F FE就是小端在前。

這個塞進(jìn)去的東西就叫BOM（Byte Order Mark，字節(jié)順序標(biāo)記）。

值得一提的是，零寬無斷字空格符也常用于充當(dāng)1個有效字符，破拆各種場合的字?jǐn)?shù)限制。包括SegmentFault的問答和評論內(nèi)容在內(nèi)。

記事本的“Unicode”和“Unicode big endian”

單寫“Unicode”，根本就不是一種存儲方法的完整表達(dá)。因?yàn)檫@只包含編碼而沒有字節(jié)序列化。

M$出現(xiàn)這種錯誤，我一點(diǎn)都不覺得奇怪。死記結(jié)論就可以了：Windows Notepad的“Unicode”就是UTF-16。

Windows Notepad使用“Unicode” = 小端在先的UTF-16，存儲這個文件的結(jié)果如下：

 FF FE 1F 95 A4 65 F7 62 0D 00 0A 00 61 00 0D 00 0A 00  -BOM- ----- ----- ----- ----- ----- ----- ----- -----  U+FEFF  951F  65A4  62F7  000D  000A  0061  000D  000A <--Unicode原始值

Windows Notepad使用“Unicode big endian” = 大端在先的UTF-16，存儲這個文件的結(jié)果如下：

 FE FF 95 1F 65 A4 62 F7 00 0D 00 0A 00 61 00 0D 00 0A  -BOM- ----- ----- ----- ----- ----- ----- ----- -----  U+FEFF  951F  65A4  62F7  000D  000A  0061  000D  000A <--Unicode原始值

UTF-8

UTF-8是一種用1~4個字節(jié)表示1個Unicode字符的變長的字節(jié)序列化方法。具體的實(shí)現(xiàn)細(xì)節(jié)看這篇文章。UTF-8的好處在于：

1. 無論是IETF的推薦，還是實(shí)際業(yè)界的執(zhí)行，UTF-8都是互聯(lián)網(wǎng)的標(biāo)準(zhǔn)。
2. 向下兼容，ASCII字符UTF-8序列化后仍是原樣，任何ASCII文件也是有效的UTF-8文件。
3. 沒有字節(jié)序問題。UTF-8的字節(jié)序是由RFC3629定死的。

Windows Notepad使用UTF-8存儲這個文件的結(jié)果如下：

 EF BB BF  E9 94 9F  E6 96 A4  E6 8B B7  0D   0A   61   0D   0A  --BOM---  --------  --------  --------  --   --   --   --   -- U+ FEFF      951F      65A4      62F7   000D 000A 0061 000D 000A <--Unicode原始值

注意UTF-8前邊仍然塞進(jìn)去了U+FEFF按照UTF-8序列化的結(jié)果EF BB BF，作為前邊提到過的BOM字節(jié)順序標(biāo)記。Windows Notepad存儲的UTF-8，是帶有BOM標(biāo)記的UTF-8。

但是如果僅僅對于UTF-8而言，字節(jié)序是沒有意義的。因?yàn)閁TF-8的字節(jié)序被規(guī)范寫死，U+FEFF編碼后必然得到EF BB FF，得不出其他的。沒有二義性，BOM就失去了原本的意義。也許只有區(qū)別UTF-8文件和UTF-16文件的用處……

如何對待UTF-8文件的BOM，RFC3629的第6章有詳細(xì)的規(guī)定，不加詳述。

值得一提的是，BOM我想很多php程序員都經(jīng)歷過并且恨之入骨——PHP不認(rèn)識文件中的BOM頭并會將其作為http Response的正文送出。這甚至在無緩沖的情況下，會導(dǎo)致header()等必須在Response開始前執(zhí)行的函數(shù)直接失效。

所以PHP程序員總是會喜歡UTF-8 without BOM的編碼方式——這基本也就宣布了Windows下的PHP開發(fā)，Windows Notepad完全的淘汰出局，哪怕是任何一星半點(diǎn)代碼的臨時(shí)修改。

番外：Notepad++的字符編碼測試

ANSI沒有區(qū)別，但Notepad++支持選擇多國編碼的不同ANSI編碼方式（類似瀏覽器里選編碼），可以輕松生成或讀取Shift-JIS等其他字符集的文件。適合用于對付日文老游戲的README等文檔。

UCS-2 Big Endian、UCS-2 Little Endian和前邊UTF-16的兩個例子一致。注意UTF-16的文件不提供“無BOM”的存儲方法（提供了就壞了）。

UTF-8仍然代表“帶有BOM標(biāo)記的UTF-8”。但同時(shí)提供PHP程序員最愛的UTF-8 without BOM，就像：

 E9 94 9F  E6 96 A4  E6 8B B7  0D   0A   61   0D   0A  --------  --------  --------  --   --   --   --   -- U+ 951F      65A4      62F7   000D 000A 0061 000D 000A <--Unicode原始值

Simple and clean.

注解
[注A] 對于一個雙(多)字節(jié)的數(shù)，一定會按8位截?cái)酁?字節(jié)后寫盤。那么寫盤時(shí)先寫最低8位還是先寫最高8位，就是所謂的“字節(jié)序”（Endian）問題。例如，數(shù)0x01020304寫盤時(shí)，是先寫最低8位的04 03 02 01，還是先寫最高8位的01 02 03 04？
?先寫低8位的叫做小端在先（little-endian），先寫高8位的叫做大端在先（big-endian）。實(shí)際采用何種字節(jié)序受系統(tǒng)環(huán)境、標(biāo)準(zhǔn)規(guī)范和軟件實(shí)際編寫的多方面控制，不一概而論。
[注B] 字節(jié)序如果我沒弄錯，是GB2312采用的EUC字符編碼方法控制的。
[注C] 本文并不嚴(yán)格區(qū)分UTF-16與UCS-2。
[注D] Unicode的最大值實(shí)際上達(dá)到了U+10FFFF，超出了兩個字節(jié)能夠存儲的限度。
?但Unicode由于歷史原因，留下了U+D800~U+DFFF這一段永久保留不用的空缺區(qū)域。
?因此對U+10000及以上的字符，UTF-16借助了這部分空缺區(qū)域，對這些編碼超大的字符打破2字節(jié)16位的慣例，特別的用4字節(jié)32位去表示之。
?這一部分編碼值太大的字符，超出了GBK的字符集范圍，因此本文將完全忽略。如有機(jī)會再進(jìn)一步測試。