Pourquoi Windows 7 fonctionne-t-il avec Unicode et non avec UTF-8?
Terminologie
Unicode et UTF-8 ne sont pas le même genre de chose: Unicode est un jeu de caractères qui définit un ensemble de caractères (un répertoire) et attribue des numéros (points de code) à chacun de ces caractères. UTF ‑ 8 est l'un des nombreux encodages pouvant être utilisés pour représenter un flux de caractères Unicode sur disque ou en transmission. Le même flux de caractères Unicode pourrait également être codé en UTF-16, UTF-32 ou UTF-7, par exemple.
Cependant, vous offre des options Bloc - notes « encodage » y compris ANSI, Unicode, Unicode big-endianet UTF-8. Les développeurs Microsoft qui ont écrit cela ont utilisé les mauvais termes. Quand ils disent "Unicode", ils signifient très probablement " UTF-16
little-endian ". Quand ils disent «ANSI», ils font référence à la page de code 1252 (CP-1252).
Bloc-notes Microsoft
Je crois que le bloc-notes de Microsoft écrit UTF-16 avec une marque d'ordre d'octets ( BOM ) et que le bloc-notes recherche la nomenclature lors de la lecture d'un fichier texte. La nomenclature indique à l'application que le fichier est UTF-16 et indique s'il s'agit d'un big-endian ou d'un petit-endian.
Si le Bloc-notes ne trouve pas la nomenclature, il appelle une fonction de bibliothèque IsTextUnicode, qui examine les données et tente de deviner quel encodage a été utilisé. Parfois (inévitablement), il devine incorrectement. Parfois, il suppose qu'un fichier "ANSI" est "Unicode". Essayer d'interpréter un fichier UTF-16 ou UTF-8 comme la page de codes 1252 entraînerait l'affichage de glyphes incorrects et l'incapacité de trouver des glyphes pour restituer des valeurs 8 bits - celles-ci seraient alors affichées sous forme de carrés.
Comme le dit Harryryc dans sa réponse , il existe de meilleures alternatives au Bloc-notes. Mais le Bloc-notes vous permet de choisir explicitement l'encodage lors de l'ouverture d'un fichier (plutôt que de laisser le Bloc-notes pour essayer de deviner).
Marques d'ordre des octets
Selon le consortium Unicode, les marques d'ordre des octets (BOM) sont facultatives. Cependant, Windows s'appuie sur les nomenclatures pour faire la distinction entre certains encodages.
Donc, en bref, peut-être que vos fichiers n'avaient pas de nomenclature pour une raison quelconque? Peut-être que la nomenclature a été perdue au cours du processus de mise à niveau?
Si vous avez toujours les fichiers d'origine qui s'affichent sous forme de carrés, vous pouvez en faire un vidage hexadécimal pour voir s'ils contiennent une nomenclature.
Normes de fichiers en texte brut
Le problème est qu'il n'y a en fait aucune - aucune norme universelle pour les fichiers en texte brut. Au lieu de cela, nous avons un certain nombre d'incompatibilités et d'inconnues.
Comment les fins de ligne ont-elles été marquées? Certaines plateformes utilisent les caractères de contrôle Carriage Return (CR) suivis de Line Feed (LF), certaines utilisent CR seul et d'autres utilisent LF seul.
Les terminateurs ou séparateurs ci-dessus sont-ils? Cela a un effet à la fin d'un fichier et est connu pour causer des problèmes.
Traitement des tabulations et autres caractères de contrôle. Nous pouvons supposer qu'un onglet est utilisé pour s'aligner sur un multiple de 8 largeurs de caractères standard depuis le début de la ligne, mais il n'y a vraiment aucune certitude à ce sujet. De nombreux programmes permettent de modifier la position des onglets.
Jeu de caractères et encodage? Il n'y a pas de norme universelle pour indiquer lesquelles ont été utilisées pour le texte du fichier. Le plus proche est de rechercher la présence d'une nomenclature qui indique que le codage est l'un de ceux utilisés pour Unicode. À partir de la valeur de nomenclature, le programme qui lit le fichier peut faire la distinction entre UTF-8 et UTF-16, etc., et entre les variantes Little-Endian et Big-Endian d'UTF-16, etc. Il n'y a pas de norme universelle pour indiquer qu'un fichier est codé dans tout autre codage populaire tel que CP-1252 ou KOI-8.
Etc. Aucune des métadonnées ci-dessus n'est écrite dans le fichier texte - l'utilisateur final doit donc informer le programme lors de la lecture du fichier. L'utilisateur final doit connaître les valeurs de métadonnées pour un fichier spécifique ou courir le risque que son programme utilise les valeurs de métadonnées incorrectes.
Bush a caché les faits
Essayez ceci sur Windows XP.
- Ouvrez le Bloc-notes.
- Définissez la police sur Arial Unicode MS. (Vous devrez peut-être l'installer d'abord; si vous ne le voyez pas dans le menu, cliquez sur "Afficher plus de polices".)
- Entrez le texte "Bush a caché les faits".
- Choisissez
Save As. Dans le Encodingmenu, sélectionnez ANSI.
- Fermez le bloc-notes.
- Rouvrez le document (par exemple, en utilisant
Start, My Recent Documents).
- Vous verrez 畂 桳 栠 摩 琠 敨 映 捡 獴 au lieu de "Bush a caché les faits".
Cela illustre que la IsTextUnicodefonction utilisée par le Bloc-notes suppose à tort que le texte ANSI (vraiment Code Page 1252) est Unicode UTF-16LE sans nomenclature. Il n'y a pas de nomenclature dans un fichier enregistré sous ANSI.
Windows 7
Avec Windows 7, Microsoft s'est ajusté IsTextUnicodepour que ce qui précède ne se produise pas. En l'absence d'une nomenclature, il est désormais plus probable de deviner ANSI (CP 1252) que Unicode (UTF-16LE). Avec Windows-7, je suppose que vous êtes donc plus susceptible d'avoir le problème inverse: un fichier contenant des caractères Unicode avec des points de code supérieurs à 255, mais sans nomenclature, est désormais plus susceptible d'être deviné comme étant ANSI - et donc affiché de manière incorrecte.
Prévention des problèmes d'encodage
Actuellement, la meilleure approche semble être d'utiliser UTF-8 partout. Idéalement, vous recoderiez tous les anciens fichiers texte en UTF-8 et n'enregistreriez que les fichiers texte au format UTF-8. Il existe des outils tels que recodage et iconv qui aide peut avec cela.