Introduction détaillée aux codages de caractères facultatifs dans le Bloc-notes Windows

Cet article vous présente une introduction détaillée au codage de caractères facultatif dans le Bloc-notes Windows. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.

Que signifient les options d'encodage pour enregistrer les fichiers dans le Bloc-notes Windows (Notepad)...

Cet article testera simplement le comportement du Bloc-notes Windows.

Le codage du Bloc-notes Windows inclut ANSI, Unicode, Unicode big endian et UTF-8.

Avertissement

Cet article explique uniquement les faits techniques d'un logiciel largement utilisé et ne signifie pas que l'auteur soutient ou s'oppose à l'utilisation du logiciel.
En fait, l'auteur recommande de ne jamais utiliser le Bloc-notes Windows pour travailler avec du code de programme informatique.
Cet article n'est vérifié que sur une certaine instance de la version chinoise simplifiée de Windows 7 64 bits et est uniquement à titre de référence. Il n'y a aucune garantie que des résultats cohérents puissent être reproduits sur d'autres systèmes identiques ou différents.

Remarque

Cet article fait une distinction stricte entre le codage d'Unicode et la sérialisation d'octets.
Le codage d'Unicode fait simplement référence au travail d'utilisation de nombres (généralement écrits sous forme de nombres hexadécimaux) pour représenter les caractères un à un. La plage de ce numéro est limitée uniquement par la norme Unicode et n'a rien à voir avec les ordinateurs. La
La sérialisation d'octets d'Unicode fait référence au travail de représentation d'un nombre dans la plage standard Unicode en N octets afin de pouvoir être écrit dans la mémoire de l'ordinateur.

Cas de test

Le cas de test est : "锟斤拷[line break]a[line break]". (锟斤拷 est une croyance.)

Les encodages GBK et Unicode de tous les caractères sont :

• 锟GBK=EFBF Unicode=U+951F

• GBK=BDEF Unicode=U+65A4

• Copier GBK=BFBD Unicode=U+62F7

Les encodages GBK et Unicode des caractères ASCII suivants sont cohérents avec l'ASCII :

a=0x61 CR=0x0D LF=0x0A
(Un caractère de nouvelle ligne dans Windows occupe deux caractères : CR+LF)

ANSI

Dans le système chinois simplifié, ANSI est le codage GBK défini par la norme nationale de la République populaire de Chine.

Le résultat de l'utilisation du Bloc-notes Windows par ANSI pour stocker ce fichier est le suivant :

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

Utilisez simplement l'encodage GBK pour stocker tous les caractères. Un simple octet dont le bit le plus élevé n'est pas 1 et équivalent à ASCII, sinon un double octet.

Faites attention au problème de l'ordre des octets (Endian) ici[注A]. Vous pouvez voir que l'ordre des octets ici est big-endian (big-endian) .

Mais il n'est pas nécessaire d'insister sur "big endian first GBK" - car à partir de GB2312, la norme stipule que la méthode de stockage est big endian first [注B]. Le GBK ultérieur est rétrocompatible avec le GB18030-2000.

Le problème avec ANSI est que cela dépend du système - l'ANSI des autres systèmes linguistiques n'est pas GBK, et les fichiers ouverts en GBK seront inévitablement tronqués. Et le jeu de caractères de GBK lui-même est trop petit.
(Ne dites jamais "Je n'utilise que le chinois" - sans les symboles Unicode, les emojis sur Internet ne peuvent pas être tapés)

Série Unicode

Ce que le Bloc-notes Windows a dit "Unicode", "Unicode big endian" et UTF-8 sont tous des méthodes de stockage de sérialisation d'octets différentes du même codageUnicode.

UTF-16 et BOM

Unicode fait ici référence à UTF-16[注C]. UTF-16 est une méthode de sérialisation extrêmement simple et grossière - la plupart des caractères Unicode sont compris entre U+0000~U+FFFF [注D], puis utilisez deux octets pour chaque caractère pour encoder Unicode. La valeur d'origine est écrite sur le disque.

Notez que les caractères ASCII doivent également gaspiller deux fois plus d'espace pour stocker les 8 bits supérieurs de 0x00 - car si les 8 bits supérieurs de 0 sont omis, il n'y aura aucune autre base de césure lors de l'analyse.

Pour UTF-16, il existe un problème de gros-boutiste et de petit-boutiste - UTF-16 ne précise pas si l'octet est en premier gros-boutiste ou petit-boutiste. Mais UTF-16 ne contient pas d'informations indiquant l'ordre des octets, vous ne pouvez donc pas vérifier manuellement quelle analyse n'est pas tronquée... La solution fournie par

Unicode est de convertir un de largeur nulle incassable Après le caractère espace (U+FEFF ZERO WIDTH NO-BREAK SPACE) est sérialisé en UTF-16, il est placé au début du fichier. De cette façon, l'analyseur UTF-16 lit les deux premiers octets du fichier. Si c'est FE FF, cela signifie la grande fin en premier, et FF FE signifie la petite fin en premier.

Cette chose en peluche s'appelle BOM (Byte Order Mark).

Il convient de mentionner que le caractère espace sans césure de largeur nulle est également souvent utilisé comme caractère valide pour dépasser la limite de mots dans diverses situations. Comprend les questions et réponses et les commentaires de SegmentFault.

« Unicode » et « Unicode big endian » du Bloc-notes

L'écriture de « Unicode » à elle seule n'est pas du tout une expression complète d'une méthode de stockage. Parce que cela ne contient que du codage et non de la sérialisation d'octets.

Je ne suis pas du tout surpris que M$ ait ce genre d'erreur. Mémorisez simplement la conclusion : Le "Unicode" du Bloc-notes Windows est 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>

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!