Question Quelle est la différence entre UTF-8 et UTF-8 sans nomenclature?


Qu'est-ce qui est différent entre UTF-8 et UTF-8 sans Nomenclature? Ce qui est mieux?


636
2018-02-08 18:26


origine


Réponses:


La nomenclature UTF-8 est une séquence d'octets (EF BB BF) qui permet au lecteur d'identifier un fichier comme codé en UTF-8.

Normalement, la nomenclature est utilisée pour signaler l'endianness d'un codage, mais comme l'endianness n'est pas pertinent pour UTF-8, la nomenclature n'est pas nécessaire.

Selon le Unicode standard, la La nomenclature des fichiers UTF-8 n'est pas recommandée:

2.6 Schémas d'encodage

... L'utilisation d'une nomenclature n'est ni requise ni recommandée pour UTF-8, mais peut être   rencontrés dans des contextes où les données UTF-8 sont converties à partir d'autres   encoder des formulaires qui utilisent une nomenclature ou lorsque la nomenclature est utilisée comme UTF-8   Signature. Voir la sous-section «Byte Order Mark» dans Section 16.8,   Promotions,   pour plus d'informations.


599
2018-02-08 18:33



Les autres excellentes réponses ont déjà répondu que:

  • Il n'y a pas de différence officielle entre UTF-8 et BOM-ed UTF-8
  • Une chaîne UTF-8 BOM-ed commencera avec les trois octets suivants. EF BB BF
  • Ces octets, s'ils sont présents, doivent être ignorés lors de l'extraction de la chaîne à partir du fichier / flux.

Mais, pour plus d'informations, la nomenclature pour UTF-8 pourrait être un bon moyen de "sentir" si une chaîne était encodée en UTF-8 ... Ou cela pourrait être une chaîne légitime dans tout autre encodage ...

Par exemple, les données [EF BB BF 41 42 43] pourraient être soit:

  • Le légitime ISO-8859-1 chaîne "ï" ¿ABC "
  • Le légitime UTF-8 chaîne "ABC"

Donc, même s'il peut être cool de reconnaître l'encodage d'un contenu de fichier en regardant les premiers octets, vous ne devriez pas vous fier à cela, comme le montre l'exemple ci-dessus

Les encodages doivent être connus, pas devinés.


195
2018-02-08 18:42



Il y a au moins trois problèmes avec la mise en place d'une nomenclature dans des fichiers codés en UTF-8.

  1. Les fichiers qui ne contiennent aucun texte ne sont plus vides car ils contiennent toujours la nomenclature.
  2. Les fichiers qui contiennent du texte appartenant au sous-ensemble ASCII de UTF-8 ne sont plus eux-mêmes ASCII car la nomenclature n'est pas ASCII, ce qui désactive certains outils existants et empêche les utilisateurs de remplacer ces outils hérités.
  3. Il n'est pas possible de concaténer plusieurs fichiers ensemble car chaque fichier a maintenant une nomenclature au début.

Et, comme d'autres l'ont mentionné, il n'est ni suffisant ni nécessaire d'avoir une nomenclature pour détecter que quelque chose est UTF-8:

  • Ce n'est pas suffisant car une séquence arbitraire d'octets peut arriver avec la séquence exacte qui constitue la nomenclature.
  • Ce n'est pas nécessaire parce que vous pouvez simplement lire les octets comme s'ils étaient UTF-8; si cela réussit, il est, par définition, valide UTF-8.

103
2017-11-15 13:28



C'est une vieille question avec beaucoup de bonnes réponses mais une chose devrait être ajoutée.

Toutes les réponses sont très générales. Ce que je voudrais ajouter, ce sont des exemples d'utilisation de la nomenclature qui causent réellement de vrais problèmes et pourtant beaucoup de gens ne le savent pas.

BOM rompt les scripts

Des scripts Shell, des scripts Perl, des scripts Python, des scripts Ruby, des scripts Node.js ou tout autre exécutable qui doit être exécuté par un interpréteur - tous commencent par un ligne de shebang qui ressemble à l'un de ceux:

#!/bin/sh
#!/usr/bin/python
#!/usr/local/bin/perl
#!/usr/bin/env node

Il indique au système quel interpréteur doit être exécuté lors de l'appel d'un tel script. Si le script est codé en UTF-8, on peut être tenté d'inclure une nomenclature au début. Mais en fait le "#!" les caractères ne sont pas seulement des caractères. Ils sont en fait un nombre magique qui se trouve être composé de deux caractères ASCII. Si vous mettez quelque chose (comme une nomenclature) devant ces caractères, alors le fichier aura l'air d'avoir un nombre magique différent et cela peut entraîner des problèmes.

Voir Wikipedia, article: Shebang, section: Numéro magique:

Les caractères shebang sont représentés par les mêmes deux octets   codages ASCII étendus, y compris UTF-8, qui est couramment utilisé pour   des scripts et d'autres fichiers texte sur les systèmes actuels de type Unix. cependant,   Les fichiers UTF-8 peuvent commencer par la marque d'ordre des octets optionnelle (BOM); si la   La fonction "exec" détecte spécifiquement les octets 0x23 et 0x21, puis la   présence de la nomenclature (0xEF 0xBB 0xBF) avant que le shebang empêche   l'interpréteur de script est en cours d'exécution. Certaines autorités recommandent   contre l'utilisation de la marque d'ordre des octets dans les scripts POSIX (Unix-like), [14]   pour cette raison et pour une plus grande interopérabilité et philosophique   préoccupations. De plus, une marque d'ordre d'octet n'est pas nécessaire en UTF-8,   comme cet encodage n'a pas de problèmes d'endianness; il sert seulement à   identifier l'encodage comme UTF-8. [Nous soulignons]

La nomenclature est illégale dans JSON

Voir RFC 7159, section 8.1:

Les implémentations NE DOIVENT PAS ajouter une marque d'ordre d'octet au début d'un texte JSON.

La nomenclature est redondante dans JSON

Non seulement c'est illégal en JSON, c'est aussi pas besoin pour déterminer le codage de caractères car il existe des moyens plus fiables de déterminer sans ambiguïté à la fois le codage de caractères et l'endianness utilisés dans tout flux JSON (voir cette réponse pour plus de détails).

La nomenclature rompt les analyseurs JSON

Non seulement c'est illégal en JSON et pas besoin, en fait casse tous les logiciels qui déterminent le codage en utilisant la méthode présentée dans RFC 4627:

Détermination de l'encodage et de l'endianness de JSON, en examinant les 4 premiers octets pour l'octet NUL:

00 00 00 xx - UTF-32BE
00 xx 00 xx - UTF-16BE
xx 00 00 00 - UTF-32LE
xx 00 xx 00 - UTF-16LE
xx xx xx xx - UTF-8

Maintenant, si le fichier commence par BOM, il ressemblera à ceci:

00 00 FE FF - UTF-32BE
FE FF 00 xx - UTF-16BE
FF FE 00 00 - UTF-32LE
FF FE xx 00 - UTF-16LE
EF BB BF xx - UTF-8

Notez que:

  1. UTF-32BE ne commence pas avec trois NUL, donc il ne sera pas reconnu
  2. UTF-32LE le premier octet n'est pas suivi par 3 NULs donc il ne sera pas reconnu
  3. UTF-16BE a seulement 1 NUL dans les 4 premiers octets donc il ne sera pas reconnu
  4. UTF-16LE n'a que 1 NUL dans les 4 premiers octets donc il ne sera pas reconnu

En fonction de l'implémentation, tous ces éléments peuvent être interprétés de manière incorrecte comme UTF-8, puis mal interprétés ou rejetés comme non valides UTF-8, ou ne pas être reconnus du tout.

De plus, si l'implémentation teste pour JSON valide comme je le recommande, elle rejettera même l'entrée qui est codée en UTF-8 parce qu'elle ne démarre pas avec un caractère ASCII <128 comme il se doit selon la RFC.

Autres formats de données

La nomenclature dans JSON n'est pas nécessaire, est illégale et casse un logiciel qui fonctionne correctement selon la RFC. Il devrait être un nobrainer de ne pas l'utiliser alors et pourtant, il y a toujours des gens qui insistent pour briser JSON en utilisant des nomenclatures, des commentaires, des règles de citations différentes ou des types de données différents. Bien sûr, n'importe qui est libre d'utiliser des choses telles que les nomenclatures ou toute autre chose si vous en avez besoin - ne l'appelez pas JSON alors.

Pour les autres formats de données que JSON, regardez à quoi cela ressemble vraiment. Si les seuls encodages sont UTF- * et que le premier caractère doit être un caractère ASCII inférieur à 128 alors vous avez déjà toutes les informations nécessaires pour déterminer à la fois l'encodage et l'endianness de vos données. L'ajout de nomenclatures, même en tant que fonctionnalité optionnelle, ne ferait que compliquer les choses et entraîner des erreurs.

Autres utilisations de la nomenclature

En ce qui concerne les utilisations en dehors de JSON ou de scripts, je pense qu'il y a déjà de très bonnes réponses ici. Je voulais ajouter plus d'informations détaillées spécifiquement sur les scripts et la sérialisation car c'est un exemple de caractères de nomenclature qui pose de vrais problèmes.


56
2018-06-26 11:34



Quelle est la différence entre UTF-8 et UTF-8 sans nomenclature?

Réponse courte: En UTF-8, une nomenclature est codée en octets EF BB BF au début du fichier.

Longue réponse:

A l'origine, il était prévu que Unicode serait codé en UTF-16 / UCS-2. La nomenclature a été conçue pour cette forme d'encodage. Lorsque vous avez des unités de code de 2 octets, il est nécessaire d'indiquer dans quel ordre se trouvent ces deux octets, et une convention commune consiste à inclure le caractère U + FEFF en tant que "marque d'ordre des octets" au début des données. Le caractère U + FFFE est définitivement non affecté de sorte que sa présence peut être utilisée pour détecter le mauvais ordre des octets.

UTF-8 a le même ordre des octets indépendamment de l'endianness de la plate-forme, donc une marque d'ordre des octets n'est pas nécessaire. Cependant, cela peut se produire (comme la séquence d'octets EF BB FF) dans les données qui ont été converties en UTF-8 à partir de UTF-16, ou en tant que «signature» pour indiquer que les données sont en UTF-8.

Ce qui est mieux?

Sans pour autant. Comme Martin Cote a répondu, la norme Unicode ne le recommande pas. Cela provoque des problèmes avec les logiciels non compatibles avec la nomenclature.

Une meilleure façon de détecter si un fichier est UTF-8 consiste à effectuer une vérification de validité. UTF-8 a des règles strictes concernant les séquences d'octets valides, donc la probabilité d'un faux positif est négligeable. Si une séquence d'octets ressemble à UTF-8, c'est probablement le cas.


43
2017-07-31 22:53



UTF-8 avec BOM est mieux identifié. J'ai atteint cette conclusion à la dure. Je travaille sur un projet où l'un des résultats est un CSV fichier, y compris les caractères Unicode.

Si le fichier CSV est enregistré sans nomenclature, Excel pense que c'est ANSI et affiche charabia. Une fois que vous ajoutez "EF BB BF" à l'avant (par exemple, en le réenregistrant en utilisant le Bloc-notes avec UTF-8, ou Notepad ++ avec UTF-8 avec BOM), Excel l'ouvre bien.

Le préfixe du caractère BOM aux fichiers texte Unicode est recommandé par RFC 3629: "UTF-8, un format de transformation de ISO 10646", novembre 2003 à http://tools.ietf.org/html/rfc3629 (cette dernière info trouvée sur: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html)


29
2018-06-28 17:34



La nomenclature a tendance à exploser (sans jeu de mots (sic)) quelque part, quelque part. Et quand il booms (par exemple, ne pas être reconnu par les navigateurs, les éditeurs, etc.), il apparaît comme les caractères étranges  au début du document (par exemple, un fichier HTML, JSON réponse, RSS, etc.) et provoque le genre d'embarras comme le problème d'encodage récent vécu lors de la conférence d'Obama sur Twitter.

C'est très énervant quand il apparaît à des endroits difficiles à déboguer ou quand les tests sont négligés. Il est donc préférable de l'éviter à moins que vous ne deviez l'utiliser.


15
2017-07-11 07:56



Question: Qu'est-ce qui est différent entre UTF-8 et UTF-8 sans nomenclature? Ce qui est mieux?

Voici quelques extraits de l'article Wikipedia sur le octet de commande (BOM) que je crois offrir une réponse solide à cette question.

Sur la signification de la nomenclature et de l'UTF-8:

La norme Unicode permet le Nomenclature dans UTF-8, mais ne nécessite pas   ou recommander son utilisation. L'ordre des octets n'a aucune signification en UTF-8, donc son   seule utilisation en UTF-8 est de signaler au début que le flux de texte est   codé en UTF-8.

Argument pour  NE PAS  en utilisant une nomenclature:

La principale motivation pour ne pas utiliser une nomenclature est la rétrocompatibilité   avec un logiciel qui n'est pas Unicode-conscient ... Une autre motivation pour ne pas   l'utilisation d'une nomenclature consiste à encourager UTF-8 en tant que codage "par défaut".

Argument  POUR  en utilisant une nomenclature:

L'argument pour utiliser une nomenclature est que sans elle, l'analyse heuristique est   requis pour déterminer le codage de caractères utilisé par un fichier.   Historiquement, une telle analyse, pour distinguer les divers encodages 8 bits, est   compliqué, sujet aux erreurs et parfois lent. Un certain nombre de bibliothèques   sont disponibles pour faciliter la tâche, tels que Mozilla Universal Charset   Détecteur et composants internationaux pour Unicode.

Les programmeurs supposent à tort que la détection de UTF-8 est également   difficile (ce n'est pas à cause de la grande majorité des séquences d'octets   sont invalides UTF-8, tandis que les encodages ces bibliothèques essaient de   distinguer autoriser toutes les séquences d'octets possibles). Donc pas tous   Les programmes Unicode-aware effectuent une telle analyse et s'appuient plutôt sur   la nomenclature

En particulier, Microsoft compilateurs et interprètes, et beaucoup   morceaux de logiciels sur Microsoft Windows tels que le Bloc-notes ne sera pas   lire correctement le texte UTF-8 à moins qu'il ne comporte que des caractères ASCII ou   commence avec la nomenclature et ajoute une nomenclature au début lors de la sauvegarde du texte   comme UTF-8. Google Docs ajoutera une nomenclature lorsqu'un document Microsoft Word est   téléchargé en tant que fichier texte brut.

Sur lequel est le meilleur,  AVEC  ou  SANS POUR AUTANT  la nomenclature:

le IETF recommande que si un protocole (a) utilise toujours UTF-8,   ou (b) a un autre moyen d'indiquer quel codage est utilisé,   alors il "DEVRAIT interdire l'utilisation de U + FEFF comme une signature."

Ma conclusion:

Utiliser la nomenclature seulement si la compatibilité avec une application logicielle est absolument essentielle.

Notez également que si l'article Wikipédia référencé indique que de nombreuses applications Microsoft s'appuient sur la nomenclature pour détecter correctement l'UTF-8, ce n'est pas le cas pour tout Applications Microsoft Par exemple, comme indiqué par @barlop, lors de l'utilisation de l'invite de commandes Windows avec UTF-8, commandes telles type et more ne vous attendez pas à ce que la nomenclature soit présente. Si la nomenclature est présent, il peut être problématique comme c'est le cas pour d'autres applications.


† Le chcp commande offre un support pour UTF-8 (sans pour autant la BOM) via la page de codes 65001.


12
2017-10-02 20:24



Cité en bas de la page Wikipedia sur BOM: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

"L'utilisation d'une nomenclature n'est ni requise ni recommandée pour UTF-8, mais peut être rencontrée dans des contextes où les données UTF-8 sont converties à partir d'autres formes de codage utilisant une nomenclature ou lorsque la nomenclature est utilisée comme signature UTF-8"


7
2018-02-08 18:35