警告
この記事は、広く使用されているソフトウェアの技術的事実を説明するだけであり、作成者がそのソフトウェアの使用を支持または反対することを意味するものではありません。
実際、著者は、コンピューター プログラム コードを扱う際には、いかなる場合でも Windows メモ帳を使用しないことをお勧めします。この記事は、64 ビット Windows 7 の簡体字中国語バージョンの特定のインスタンスでのみ検証されており、参照のみを目的としています。他の同一または異なるシステム上で一貫した結果を再現できるという保証はありません。
注
この記事では、Unicode の
と
バイト シリアル化 を厳密に区別します。 Unicode の Encoding は、数値 (通常は 16 進数で記述される) を使用して文字を 1 対 1 で表現する作業のみを指します。この数値の範囲は Unicode 標準によってのみ制限されており、コンピューターとは関係ありません。 Unicode の
バイト シリアル化 は、コンピュータ メモリに書き込めるようにするために、Unicode 標準範囲内の数値を N バイトに表現する作業を指します。
テスト ケーステスト ケースは「锟斤[改行]a[改行]」です。 (Kun Jin Kao は信念です。)
すべての文字の GBK および Unicode エンコードは次のとおりです:
锟GBK=EFBF
Unicode=- U 951F
-
金GBK=BDEFUnicode= U 65A4 -
copyGBK=BFBDUnicode= U 62F7 -
次の ASCII 文字の GBK および Unicode エンコードは ASCII と一致しています:
0x61
CR=0x0DLF=
簡体字中国語システムでは、ANSI は中華人民共和国の国家標準によって定義された GBK エンコードです。中国。0x0A(Windows では 1 つの改行文字が 2 文字を占めます: CR LF)ANSI
Windows メモ帳が ANSI を使用してこのファイルを保存した結果は次のとおりです。
EF BF BD EF BF BD 0D 0A 61 0D 0A ----- ----- ----- -- -- -- -- --
単純に GBK エンコードを使用してすべての文字を保存します。最上位ビットが 1 ではない 1 バイトで ASCII と同等、それ以外の場合は 2 バイト。
ここでバイトオーダー(エンディアン)の問題に注意する必要があります
[注A]。ここでのバイトオーダーは
big-endian であることがわかります。 ただし、「ビッグ エンディアンが最初の GBK」を特に強調する必要はありません。GB2312 以降、標準ではストレージ方式がビッグ エンディアン ファーストであることが規定されているためです。[注 B]。以降の GBK は GB18030-2000 と下位互換性があります。
ANSI の問題点は、システムに依存することです。他の言語システムの ANSI は GBK ではないため、GBK で開かれたファイルは必然的に文字化けします。そしてGBK自体の文字セットが小さすぎます。 (決して「中国語しか使わない」とは言わないでください。Unicode の記号がなければ、インターネット上の絵文字は入力できません。)
Windows のメモ帳で「Unicode」と表示されたもの、 「Unicode ビッグ エンディアン」と UTF-8 はすべて、同じ Unicode
の異なる
バイト シリアル化格納方法です。 UTF-16 と BOMここでの Unicode は、UTF-16
[注 C]を指します。 UTF-16 は非常に単純かつ粗雑なシリアル化方法です。ほとんどの Unicode 文字は U 0000 ~ U FFFF
[Note D] の範囲にあり、各文字は 2 バイトを使用し、Unicode エンコーディングの元の値を書き込みます。ディスクに。 ASCII 文字は、0x00 の上位 8 ビットを格納するために 2 倍のスペースを浪費する必要があることに注意してください。0 の上位 8 ビットが省略されると、解析中にハイフネーションを行うための他の根拠がなくなるからです。 UTF-16 には、ビッグ エンディアンとリトル エンディアンの問題があります。UTF-16 では、バイトが最初にビッグ エンディアンであるかリトル エンディアンであるかが指定されていません。ただし、UTF-16 にはバイト順序を示す情報が含まれていないため、どの解析が文字化けしていないかを手動で確認することはできません...
Unicode が提供する解決策は、
ゼロ幅の解読不可能な文字列を変換することです。文字スペース文字(
U FEFF ZERO WIDTH NO-BREAK SPACE) は UTF-16 でシリアル化され、ファイルの先頭に詰められます。このように、UTF-16 パーサーはファイルの最初の 2 バイトを読み取ります。FE FF の場合はビッグエンドが最初であることを意味し、FF FE はリトルエンドが最初であることを意味します。 この詰め込まれたものをBOM(Byte Order Mark、バイトオーダーマーク)といいます。
ゼロ幅のハイフンなしのスペース文字
は、さまざまな状況で単語制限を破るための有効な文字としてもよく使用されることに注意してください。 SegmentFault の Q&A とコメントが含まれます。encodingメモ帳の「Unicode」と「Unicode ビッグ エンディアン」
「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>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>