Windows Notepad裡可選的字元編碼的詳細介紹

這篇文章帶給大家的內容是關於Windows Notepad裡可選的字元編碼的詳細介紹，有一定的參考價值，有需要的朋友可以參考一下，希望對你有所幫助。

Windows Notepad（記事本）中儲存檔案的程式碼選項都是什麼意思…

這篇文章就簡單測試一下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=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

#在簡體中文系統下，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 FEFF ZERO 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  000A <p>Windows Notepad使用<strong>“Unicode big endian” = 大端在先的UTF-16</strong>，存储这个文件的结果如下：</p><pre class="brush:php;toolbar:false"> 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 <h3 id="UTF">UTF-8</h3><p>UTF-8是一种用1~4个字节表示1个Unicode字符的<strong>变长的</strong>字节序列化方法。具体的实现细节看这篇文章。UTF-8的好处在于：</p><ol class=" list-paddingleft-2">
<li><p>无论是IETF的推荐，还是实际业界的执行，UTF-8都是互联网的标准。</p></li>
<li><p>向下兼容，ASCII字符UTF-8序列化后仍是原样，任何ASCII文件也是有效的UTF-8文件。</p></li>
<li><p>没有字节序问题。UTF-8的字节序是由RFC3629定死的。</p></li>
</ol><p>Windows Notepad使用UTF-8存储这个文件的结果如下：</p><pre class="brush:php;toolbar:false"> 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 <p>注意UTF-8前边仍然塞进去了<code>U+FEFF</code>按照UTF-8序列化的结果<code>EF BB BF</code>，作为前边提到过的<strong>BOM</strong>字节顺序标记。<strong>Windows Notepad存储的UTF-8，是带有BOM标记的UTF-8</strong>。</p><p>但是如果仅仅对于UTF-8而言，字节序是没有意义的。因为UTF-8的字节序被规范写死，<code>U+FEFF</code>编码后必然得到<code>EF BB FF</code>，得不出其他的。没有二义性，BOM就失去了原本的意义。也许只有区别UTF-8文件和UTF-16文件的用处……</p><p>如何对待UTF-8文件的BOM，RFC3629的第6章有详细的规定，不加详述。</p><p>值得一提的是，BOM我想很多PHP程序员都经历过并且恨之入骨——PHP不认识文件中的BOM头并会将其作为HTTP Response的正文送出。这甚至在无缓冲的情况下，会导致<code>header()</code>等必须在Response开始前执行的函数直接失效。</p><p>所以PHP程序员总是会喜欢<strong>UTF-8 without BOM</strong>的编码方式——这基本也就宣布了Windows下的PHP开发，Windows Notepad完全的淘汰出局，哪怕是任何一星半点代码的临时修改。</p><h2 id="番外-Notepad-的字符编码测试">番外：Notepad++的字符编码测试</h2><p>ANSI没有区别，但Notepad++支持选择多国编码的不同ANSI编码方式（类似浏览器里选编码），可以轻松生成或读取Shift-JIS等其他字符集的文件。适合用于对付日文老游戏的<code>README</code>等文档。</p><p>UCS-2 Big Endian、UCS-2 Little Endian和前边UTF-16的两个例子一致。注意UTF-16的文件不提供“无BOM”的存储方法（提供了就坏了）。</p><p>UTF-8仍然代表“带有BOM标记的UTF-8”。但同时提供PHP程序员最爱的UTF-8 without BOM，就像：</p><pre class="brush:php;toolbar:false"> E9 94 9F  E6 96 A4  E6 8B B7  0D   0A   61   0D   0A
 --------  --------  --------  --   --   --   --   --
U+ 951F      65A4      62F7   000D 000A 0061 000D 000A <p>Simple and clean.</p><p>注解<br>[注A] 对于一个双(多)字节的数，一定会按8位截断为1字节后写盘。那么写盘时先写最低8位还是先写最高8位，就是所谓的“字节序”（Endian）问题。例如，数0x01020304写盘时，是先写最低8位的04 03 02 01，还是先写最高8位的01 02 03 04？<br>
  先写低8位的叫做小端在先（little-endian），先写高8位的叫做大端在先（big-endian）。实际采用何种字节序受系统环境、标准规范和软件实际编写的多方面控制，不一概而论。<br>[注B] 字节序如果我没弄错，是GB2312采用的EUC字符编码方法控制的。<br>[注C] 本文并不严格区分UTF-16与UCS-2。<br>[注D] Unicode的最大值实际上达到了U+10FFFF，超出了两个字节能够存储的限度。<br>
  但Unicode由于历史原因，留下了U+D800~U+DFFF这一段永久保留不用的空缺区域。<br>
  因此对U+10000及以上的字符，UTF-16借助了这部分空缺区域，对这些编码超大的字符打破2字节16位的惯例，特别的用4字节32位去表示之。<br>
  这一部分编码值太大的字符，超出了GBK的字符集范围，因此本文将完全忽略。如有机会再进一步测试。</p><p class="comments-box-content"></p>

以上是Windows Notepad裡可選的字元編碼的詳細介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！