這篇文章就簡單測試一下Windows Notepad的行為。
▲ Windows Notepad的編碼包含ANSI、Unicode、Unicode big endian和UTF-8。
警告
本文僅闡述一個廣泛使用的軟體的技術事實，不代表作者支持或反對使用該軟體。
事實上作者推薦任何時候都不使用 Windows Notepad 來處理電腦程式碼。
本文僅在某一個簡體中文版64位元Windows 7的實例下驗證，僅供參考。不保證在其他相同或相異系統下能夠重現一致的結果。
注意
本文嚴格區分Unicode的編碼和位元組序列化。
Unicode的編碼僅指使用數字（通常寫成16進位數）來一對一的代表字元的工作。這個數的範圍只受Unicode標準的約束，與電腦毫無關聯。
Unicode的位元組序列化指為了能夠寫入電腦記憶體，而把一個Unicode標準範圍內的數，表示成N個位元組的工作。
測試案例
測試案例為：「錟斤拷【斷行】a【斷行】」。 （錟斤拷貝是一種信仰。）
所有字元的GBK和Unicode編碼為：
- 錟GBK=
EFBFUnicode=U 951F - 斤GBK=
BDEFUnicode=U 65A4 - 拷GBK=
BFBDUnicode=U 62F7
以下ASCII字元的GBK和Unicode編碼與ASCII一致：
a=
0x61# CR=0x0DLF=0x0A
# （Windows一個換行符佔有兩個字元：CR LF）
ANSI
在簡體中文系統下，ANSI就是中華人民共和國國家標準定義的GBK編碼。
Windows Notepad使用ANSI儲存這個檔案的結果如下：
EF BF BD EF BF BD 0D 0A 61 0D 0A ----- ----- ----- -- -- -- -- --
簡單的使用GBK編碼儲存了所有的字元。最高位元不是1的單字節並等同於ASCII，否則雙位元組。
這裡要注意位元組序（Endian）的問題[註A]。可以看到這裡的字節序是大端在先（big-endian）的。
但不必刻意強調「大端在先的GBK」－因為從GB2312開始，標準就規定了儲存方式是大端在先的[註B]。後來的GBK和GB18030-2000向下相容。
ANSI的麻煩就是依賴系統－其他語言系統的ANSI就不是GBK了，開啟GBK的檔案必然亂碼。且GBK的字元集本身也太小。
（千萬不要說「我只用中文」－少了Unicode那些符號，網路上那些顏文字都打不出來）
Unicode系列
Windows Notepad所說的「Unicode」、「Unicode big endian」和UTF-8，全都是同樣的Unicode編碼的不同的位元組序列化儲存方法。
UTF-16 和 BOM
這裡的Unicode指UTF-16[註C]。 UTF-16是極為簡單粗暴的序列化方法－絕大多數的Unicode字元都在U 0000~U FFFF的範圍內[註D]，那就每個字元用兩個位元組，把Unicode編碼的原始值寫盤。
注意ASCII字元也必須浪費一倍的空間儲存高8位元的0x00－因為如果把高8位元的0略了，解析時就再也沒有其他的依據去斷字。
對於UTF-16就存在大端和小端的問題了－UTF-16並不規定位元組的大端在前還是小端在前。但UTF-16並不包含表示字節序的訊息，總不能人工看看哪個解析是不亂碼的吧…
Unicode提供的解決方式是，把一個零寬無斷字空格符（U FEFFZERO WIDTH NO-BREAK SPACE）以UTF-16的方式序列化之後，塞到檔案的最前邊。這樣UTF-16解析器讀取檔案的前兩個位元組，如果是FE FF就是大端在前，FF FE就是小端在前。
這個塞進去的東西就叫BOM（Byte Order Mark，位元組順序標記）。
值得一提的是，零寬無斷字空格符也常用於充當1個有效字符，破拆各種場合的字數限制。包括SegmentFault的問答和評論內容在內。
記事本的“Unicode”和“Unicode big endian”
單寫“Unicode”，根本就不是一種儲存方法的完整表達。因為這只包含編碼而沒有位元組序列化。
M$出现这种错误，我一点都不觉得奇怪。死记结论就可以了：Windows Notepad的“Unicode”就是UTF-16。
Windows Notepad使用“Unicode” = 小端在先的UTF-16，存储这个文件的结果如下：
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 000AWindows Notepad使用“Unicode big endian” = 大端在先的UTF-16，存储这个文件的结果如下：
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 000AUTF-8
UTF-8是一种用1~4个字节表示1个Unicode字符的变长的字节序列化方法。具体的实现细节看这篇文章。UTF-8的好处在于：
- 无论是IETF的推荐，还是实际业界的执行，UTF-8都是互联网的标准。
- 向下兼容，ASCII字符UTF-8序列化后仍是原样，任何ASCII文件也是有效的UTF-8文件。
- 没有字节序问题。UTF-8的字节序是由RFC3629定死的。
Windows Notepad使用UTF-8存储这个文件的结果如下：
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注意UTF-8前边仍然塞进去了
U+FEFF按照UTF-8序列化的结果EF BB BF，作为前边提到过的BOM字节顺序标记。Windows Notepad存储的UTF-8，是带有BOM标记的UTF-8。但是如果仅仅对于UTF-8而言，字节序是没有意义的。因为UTF-8的字节序被规范写死，
U+FEFF编码后必然得到EF BB FF，得不出其他的。没有二义性，BOM就失去了原本的意义。也许只有区别UTF-8文件和UTF-16文件的用处……如何对待UTF-8文件的BOM，RFC3629的第6章有详细的规定，不加详述。
值得一提的是，BOM我想很多PHP程序员都经历过并且恨之入骨——PHP不认识文件中的BOM头并会将其作为HTTP Response的正文送出。这甚至在无缓冲的情况下，会导致
header()等必须在Response开始前执行的函数直接失效。所以PHP程序员总是会喜欢UTF-8 without BOM的编码方式——这基本也就宣布了Windows下的PHP开发，Windows Notepad完全的淘汰出局，哪怕是任何一星半点代码的临时修改。
番外：Notepad++的字符编码测试
ANSI没有区别，但Notepad++支持选择多国编码的不同ANSI编码方式（类似浏览器里选编码），可以轻松生成或读取Shift-JIS等其他字符集的文件。适合用于对付日文老游戏的
README等文档。UCS-2 Big Endian、UCS-2 Little Endian和前边UTF-16的两个例子一致。注意UTF-16的文件不提供“无BOM”的存储方法（提供了就坏了）。
UTF-8仍然代表“带有BOM标记的UTF-8”。但同时提供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 000ASimple and clean.
注解
[注A]对于一个双(多)字节的数，一定会按8位截断为1字节后写盘。那么写盘时先写最低8位还是先写最高8位，就是所谓的“字节序”（Endian）问题。例如，数0x01020304写盘时，是先写最低8位的04 03 02 01，还是先写最高8位的01 02 03 04？
先写低8位的叫做小端在先（little-endian），先写高8位的叫做大端在先（big-endian）。实际采用何种字节序受系统环境、标准规范和软件实际编写的多方面控制，不一概而论。[注B]字节序如果我没弄错，是GB2312采用的EUC字符编码方法控制的。[注C]本文并不严格区分UTF-16与UCS-2。[注D]Unicode的最大值实际上达到了U+10FFFF，超出了两个字节能够存储的限度。
但Unicode由于历史原因，留下了U+D800~U+DFFF这一段永久保留不用的空缺区域。
因此对U+10000及以上的字符，UTF-16借助了这部分空缺区域，对这些编码超大的字符打破2字节16位的惯例，特别的用4字节32位去表示之。
这一部分编码值太大的字符，超出了GBK的字符集范围，因此本文将完全忽略。如有机会再进一步测试登入後複製
