Detaillierte Einführung in optionale Zeichenkodierungen im Windows Notepad

Dieser Artikel bietet Ihnen eine detaillierte Einführung in die optionale Zeichenkodierung im Windows Notepad. Ich hoffe, dass er für Freunde hilfreich ist.

Was bedeuten die Kodierungsoptionen zum Speichern von Dateien im Windows Notepad (Notepad)?

In diesem Artikel wird lediglich das Verhalten von Windows Notepad getestet.

Die Kodierung von Windows Notepad umfasst ANSI, Unicode, Unicode Big Endian und UTF-8.

Warnung

Dieser Artikel erläutert nur die technischen Fakten einer weit verbreiteten Software und bedeutet nicht, dass der Autor die Verwendung der 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 ein Glaube.)

Die GBK- und Unicode-Kodierungen aller Zeichen sind:

• 锟GBK=EFBF Unicode=U+951F

• GBK=BDEF Unicode=U+65A4

• Copy GBK=BFBD Unicode=U+62F7

Die GBK- und Unicode-Kodierungen der folgenden ASCII-Zeichen stimmen mit ASCII überein:

a=0x61 CR=0x0D LF=0x0A
(Ein Zeilenumbruchzeichen in Windows belegt zwei Zeichen: CR+LF)

ANSI

Im 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:

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

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.

Achten Sie hier auf die Frage der Bytereihenfolge (Endian)[注A]. Sie können sehen, dass die Bytereihenfolge hier Big-Endian (Big-Endian) ist.

Es besteht jedoch kein Grund, „Big Endian First GBK“ zu betonen – denn ab GB2312 schreibt der Standard vor, dass die Speichermethode Big Endian First ist [注B]. 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 die Symbole von Unicode können die Emojis im Internet nicht eingegeben werden)

Unicode-Serie

Was Windows Notepad sagte „Unicode“, „Unicode Big Endian“ und UTF-8 sind alle unterschiedliche Byte-Serialisierung Speichermethoden derselben UnicodeKodierung.

UTF-16 und BOM

Unicode bezieht sich hier auf UTF-16[注C]. UTF-16 ist eine äußerst einfache und grobe Serialisierungsmethode – die meisten Unicode-Zeichen liegen im Bereich von U+0000~U+FFFF [注D], dann werden für jedes Zeichen zwei Bytes zum Codieren verwendet Unicode Der Originalwert wird auf die Festplatte geschrieben.

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.

Für UTF-16 gibt es ein Big-Endian- und Little-Endian-Problem – UTF-16 gibt nicht an, ob das Byte zuerst Big-Endian oder Little-Endian ist. Allerdings enthält UTF-16 keine Informationen zur Bytereihenfolge, sodass Sie nicht manuell überprüfen können, welches Parsing nicht verstümmelt ist ... Die von

Unicode bereitgestellte Lösung besteht darin, eine Nullbreite ununterbrochen zu konvertieren Nachdem das Zeichen Leerzeichen (U+FEFF NULL WIDTH NO-BREAK SPACE) in UTF-16 serialisiert wurde, wird es am Anfang der Datei eingefügt. Auf diese Weise liest der UTF-16-Parser die ersten beiden Bytes der Datei. Wenn es FE FF ist, bedeutet dies, dass das große Ende zuerst und FF FE das kleine Ende zuerst ist.

Dieses gefüllte Ding heißt BOM (Byte Order Mark).

Es ist erwähnenswert, dass das Leerzeichen ohne Silbentrennung mit der Breite Null auch oft als gültiges Zeichen verwendet wird, um die Wortbeschränkung in verschiedenen Situationen zu überschreiten. Enthält Fragen und Antworten sowie Kommentare von SegmentFault.

Notepads „Unicode“ und „Unicode Big Endian“

Das Schreiben von „Unicode“ allein ist überhaupt kein vollständiger Ausdruck einer Speichermethode. Denn dies beinhaltet nur Kodierung und nicht Byte-Serialisierung.

Ich bin überhaupt nicht überrascht, dass M$ einen solchen Fehler hat. Merken Sie sich einfach die Schlussfolgerung: Der „Unicode“ von Windows Notepad ist 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>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>番外：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>

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung in optionale Zeichenkodierungen im Windows Notepad. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!