▲ Die Windows Notepad-Kodierung umfasst ANSI, Unicode, Unicode Big Endian und UTF-8.
Warnung
Dieser Artikel erläutert lediglich die technischen Fakten einer weit verbreiteten Software und bedeutet nicht, dass der Autor die Verwendung dieser Software unterstützt oder ablehnt.
Tatsächlich empfiehlt der Autor, niemals Windows Notepad zu verwenden, um mit Computerprogrammcode zu arbeiten.
Dieser Artikel wurde nur für eine bestimmte Instanz der vereinfachten chinesischen Version von 64-Bit-Windows 7 überprüft und dient nur als Referenz. Es gibt keine Garantie dafür, dass konsistente Ergebnisse auf anderen identischen oder unterschiedlichen Systemen reproduziert werden können.
Hinweis
In diesem Artikel wird streng zwischen der Kodierung von Unicode und der Byte-Serialisierung unterschieden. Die
Codierung von Unicode bezieht sich einfach auf die Arbeit, Zahlen (normalerweise als Hexadezimalzahlen geschrieben) zu verwenden, um Zeichen eins zu eins darzustellen. Der Bereich dieser Zahl ist nur durch den Unicode-Standard begrenzt und hat nichts mit Computern zu tun.
Unicodes Byte-Serialisierung bezieht sich auf die Arbeit, eine Zahl innerhalb des Unicode-Standardbereichs in N Bytes darzustellen, damit sie in den Computerspeicher geschrieben werden kann.
Testfall
Der Testfall ist: „锟斤拷[Zeilenumbruch]a[Zeilenumbruch]“. (锟斤拷 ist eine Art Glaube.)
Die GBK- und Unicode-Kodierungen aller Zeichen sind:
- 锟GBK=
EFBFUnicode=U+951FEFBFUnicode=U+951F - 斤 GBK=
BDEFUnicode=U+65A4 - 拷 GBK=
BFBDUnicode=U+62F7
以下ASCII字符的GBK和Unicode编码与ASCII一致：
a=
0x61CR=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+FEFF ZERO WIDTH NO-BREAK SPACE）以UTF-16的方式序列化之后，塞到文件的最前边。这样UTF-16解析器读取文件的前两个字节，如果是FE FF就是大端在前，FF FEGBK=BDEF Unicode=U+65A4
BFBD Unicode=U+62F7<p>Die GBK- und Unicode-Kodierungen der folgenden ASCII-Zeichen stimmen mit ASCII überein: </p>
<blockquote><p>a=<code>0x61 CR=0x0D LF=0x0A
(Ein Zeilenumbruchzeichen in Windows belegt zwei Zeichen: CR+LF)ANSIUnter dem vereinfachten chinesischen System ist ANSI die GBK-Kodierung, die durch den nationalen Standard der Volksrepublik China definiert ist. Das Ergebnis, wenn Windows Notepad ANSI zum Speichern dieser Datei verwendet, ist wie folgt:
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 <strong>Verwenden Sie einfach die GBK-Codierung, um alle Zeichen zu speichern. Ein einzelnes Byte, dessen höchstes Bit nicht 1 ist und ASCII entspricht, andernfalls ein Doppelbyte. </strong>Achten Sie hier auf die Frage der Bytereihenfolge (Endian) <code>[Hinweis A]</code>. Sie können sehen, dass die Bytereihenfolge hier 🎜Big-Endian🎜 ist. 🎜🎜Aber „GBK mit Big Endian zuerst“ muss nicht betont werden – denn ab GB2312 schreibt der Standard vor, dass die Speichermethode „Big Endian zuerst“ ist <code>[Hinweis B]</code>. Später ist GBK abwärtskompatibel mit GB18030-2000. 🎜🎜Das Problem mit ANSI besteht darin, dass es vom System abhängt – ANSI anderer Sprachsysteme ist nicht GBK, und in GBK geöffnete Dateien werden unweigerlich verstümmelt. Und der Zeichensatz von GBK selbst ist zu klein. 🎜 (Sagen Sie niemals „Ich verwende nur Chinesisch“ – ohne diese Unicode-Symbole können die Emojis im Internet nicht eingegeben werden) 🎜🎜Unicode-Serie🎜🎜Was Windows Notepad „Unicode“, „Unicode Big Endian“ und UTF-8 nennt, alles die gleiche Unicode-Kodierung, aber unterschiedliche Speichermethoden für die Byte-Serialisierung. 🎜🎜UTF-16 und BOM🎜🎜Unicode bezieht sich hier auf UTF-16<code>[Anmerkung C]</code>. UTF-16 ist eine äußerst einfache und grobe Serialisierungsmethode – die überwiegende Mehrheit der Unicode-Zeichen liegt im Bereich von U+0000~U+FFFF <code>[Anmerkung D]</code>, dann benötigt jedes Zeichen zwei Bytes zum Schreiben der ursprüngliche Wert der Unicode-Kodierung auf der Festplatte. 🎜🎜Beachten Sie, dass ASCII-Zeichen auch doppelt so viel Platz verschwenden müssen, um die oberen 8 Bits von 0x00 zu speichern – denn wenn die oberen 8 Bits von 0 weggelassen werden, gibt es beim Parsen keine andere Grundlage für die Silbentrennung. 🎜🎜Bei UTF-16 gibt es das Problem von Big Endian und Little Endian – UTF-16 gibt nicht an, ob das Byte zuerst Big Endian oder Little Endian ist. Aber UTF-16 enthält keine Informationen zur Byte-Reihenfolge, sodass Sie nicht manuell überprüfen können, welches Parsing nicht verstümmelt ist ... Die von Unicode bereitgestellte Lösung besteht darin, ein 🎜Leerzeichen ohne Silbentrennung mit der Breite Null🎜() einzufügen U+FEFF ZERO WIDTH NO-BREAK SPACE) wird in UTF-16 serialisiert und an den Anfang der Datei gestopft. Auf diese Weise liest der UTF-16-Parser die ersten beiden Bytes der Datei. Wenn es sich um <code>FE FF</code> handelt, bedeutet dies, dass das große Ende zuerst und <code>FF FE</code> das kleine Ende bedeutet Erste. 🎜🎜Dieses eingefüllte Ding heißt BOM (Byte Order Mark). 🎜🎜🎜Es ist erwähnenswert, dass das 🎜Leerzeichen ohne Silbentrennung mit der Breite Null🎜 auch häufig als gültiges Zeichen verwendet wird, um in verschiedenen Situationen die Wortbeschränkung zu überschreiten. Enthält Fragen und Antworten sowie Kommentare von SegmentFault. 🎜🎜🎜„Unicode“ und „Unicode big endian“ im Notepad🎜🎜Das Schreiben von „Unicode“ allein ist überhaupt kein vollständiger Ausdruck einer Speichermethode. Denn dies beinhaltet nur 🎜Codierung🎜 und nicht 🎜Byte-Serialisierung🎜. 🎜<p>M$出现这种错误，我一点都不觉得奇怪。死记结论就可以了：<strong>Windows Notepad的“Unicode”就是UTF-16</strong>。</p><p>Windows Notepad使用<strong>“Unicode” = 小端在先的UTF-16</strong>，存储这个文件的结果如下：</p><pre class="brush:php;toolbar:false"> 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>UTF-8</h3><p>UTF-8是一种用1~4个字节表示1个Unicode字符的<strong>变长的</strong>字节序列化方法。具体的实现细节看这篇文章。UTF-8的好处在于：</p><ol> <li>无论是IETF的推荐，还是实际业界的执行，UTF-8都是互联网的标准。</li> <li>向下兼容，ASCII字符UTF-8序列化后仍是原样，任何ASCII文件也是有效的UTF-8文件。</li> <li>没有字节序问题。UTF-8的字节序是由RFC3629定死的。</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>番外：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><blockquote><p><strong>注解</strong><br><code>[注A]</code> 对于一个双(多)字节的数，一定会按8位截断为1字节后写盘。那么写盘时先写最低8位还是先写最高8位，就是所谓的“字节序”（Endian）问题。例如，数<code>0x01020304</code>写盘时，是先写最低8位的<code>04 03 02 01</code>，还是先写最高8位的<code>01 02 03 04</code>？<br> 先写低8位的叫做小端在先（little-endian），先写高8位的叫做大端在先（big-endian）。实际采用何种字节序受系统环境、标准规范和软件实际编写的多方面控制，不一概而论。<br><code>[注B]</code> 字节序如果我没弄错，是GB2312采用的EUC字符编码方法控制的。<br><code>[注C]</code> 本文并不严格区分<strong>UTF-16</strong>与<strong>UCS-2</strong>。<br><code>[注D]</code> Unicode的最大值实际上达到了U+10FFFF，超出了两个字节能够存储的限度。<br> 但Unicode由于历史原因，留下了U+D800~U+DFFF这一段永久保留不用的空缺区域。<br> 因此对U+10000及以上的字符，UTF-16借助了这部分空缺区域，对这些编码超大的字符打破2字节16位的惯例，特别的用4字节32位去表示之。<br> 这一部分编码值太大的字符，超出了GBK的字符集范围，因此本文将<strong>完全忽略</strong>。如有机会再进一步测试。</p></blockquote>