Quelle est la différence entre un UTF-8 et un UTF-8 sans un NOMENCLATURE ? Lequel est le meilleur ?
La nomenclature UTF-8 est une séquence de octets au début d'un flux de texte ( 0xEF, 0xBB, 0xBF ) qui permet au lecteur de deviner de manière plus fiable qu'un fichier est encodé en UTF-8.
Normalement, le NOMENCLATURE est utilisé pour signaler le endiveté d'un encodage, mais comme l'endianness n'est pas pertinent pour UTF-8, le BOM est inutile.
Selon le Norme Unicode le La nomenclature pour les fichiers UTF-8 n'est pas recommandée. :
2.6 Schémas de codage
... L'utilisation d'une BOM 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 qui utilisent une BOM ou lorsque la BOM est utilisée comme signature UTF-8. Voir la sous-section "Marque d'ordre des octets" dans le document Section 16.8, Spéciaux pour plus d'informations.
Ce n'est peut-être pas recommandé, mais d'après mon expérience des conversions en hébreu, la nomenclature est parfois cruciale pour la reconnaissance UTF-8 dans Excel, et peut faire la différence entre le jibrish et l'hébreu.
Ce n'est peut-être pas recommandé mais cela a fait des merveilles à mon script de powershell en essayant de sortir "æøå".
Même si ce n'est pas recommandé par la norme, c'est autorisé, et je préfère de loin avoir quelque chose pour agir comme une signature UTF-8 plutôt que les alternatives de supposer ou de deviner. Les logiciels compatibles avec Unicode devraient/doivent être capables de gérer sa présence, et j'encourage donc personnellement son utilisation.
Les autres excellentes réponses ont déjà répondu à cette question :
EF BB BF
Mais, à titre d'information complémentaire, le BOM pour UTF-8 pourrait être un bon moyen de "sentir" si une chaîne a été encodée en UTF-8... Ou bien il pourrait s'agir d'une chaîne légitime dans tout autre encodage...
Par exemple, les données [EF BB BF 41 42 43] pourraient être soit :
Ainsi, bien qu'il puisse être intéressant de reconnaître l'encodage du contenu d'un fichier en regardant les premiers octets, vous ne devez pas vous fier à cela, comme le montre l'exemple ci-dessus.
Les codages doivent être connus, et non devinés.
Désolé monsieur, mais je ne comprends pas bien l'exemple que vous venez de donner. Si je reçois une chaîne de caractères [EF BB BF 41 42 43], comment puis-je l'interpréter ? En utilisant ISO-8859-1 ou UTF-8 ? Parce que, comme le dit votre exemple, les deux donnent une chaîne légitime : "ï "¿ABC" et "ABC".
@Alcott : Vous avez bien compris. La chaîne [EF BB BF 41 42 43] est juste un tas d'octets. Vous avez besoin d'informations externes pour choisir comment l'interpréter. Si vous pensez que ces octets ont été codés en utilisant la norme ISO-8859-1, alors la chaîne est "ï "¿ABC". Si vous pensez que ces octets ont été codés en UTF-8, alors la chaîne est "ABC". Si vous ne le savez pas, vous devez essayer de le découvrir. La nomenclature peut être un indice. L'absence de caractère invalide lorsqu'il est décodé en UTF-8 pourrait en être un autre... En fin de compte, à moins que vous puissiez mémoriser/trouver l'encodage d'une manière ou d'une autre, un tableau d'octets est juste un tableau d'octets.
@paercebal Alors que "ï "¿" est valide en latin-1, il est très Il est peu probable qu'un fichier texte commence par cette combinaison. Il en va de même pour les marqueurs ucs2-le/be ÿþ et þÿ. Vous pouvez également jamais savoir.
L'insertion d'une nomenclature dans les fichiers codés en UTF-8 pose au moins trois problèmes.
Et, comme d'autres l'ont mentionné, il n'est ni suffisant ni nécessaire d'avoir une nomenclature pour détecter qu'un élément est UTF-8 :
@cheers-and-hth-alf J'ai maintenant clarifié la déclaration ci-dessus ; ce sont des faits, aucune logique n'est impliquée.
Après la modification des points 1 et 2, ces deux points ne sont plus directement contradictoires. C'est une amélioration. Je vais discuter chaque point à tour de rôle.
Concernant le point 1 "Les fichiers qui ne contiennent pas de texte ne sont plus vides parce qu'ils contiennent toujours la nomenclature", ceci (1) confond le niveau du système de fichiers du système d'exploitation avec le niveau du contenu interprété, et (2) suppose à tort qu'en utilisant la nomenclature, on doit mettre une nomenclature dans chaque fichier autrement vide. La solution pratique à (1) est de ne pas faire (2). Essentiellement, la plainte se réduit à "il est possible de mettre une nomenclature dans un fichier vide, ce qui empêche la détection la plus facile d'un fichier logiquement vide (en vérifiant la taille du fichier)". Un bon logiciel devrait tout de même être capable de gérer ce problème, puisqu'il a un but.
Quelle est la différence entre UTF-8 et UTF-8 sans nomenclature ?
Réponse courte : En UTF-8, une nomenclature est encodée sous la forme des octets suivants EF BB BF au début du fichier.
Longue réponse :
À 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 courante pour ce faire consiste à inclure le caractère U+FEFF comme "marque d'ordre d'octet" au début des données. Le caractère U+FFFE n'est pas attribué de façon permanente, de sorte que sa présence peut être utilisée pour détecter l'ordre incorrect des octets.
UTF-8 a le même ordre d'octet indépendamment de l'endiannage de la plate-forme, donc une marque d'ordre d'octet n'est pas nécessaire. Cependant, cela peut arriver (comme la séquence d'octets EF BB FF ) dans les données qui ont été converties en UTF-8 à partir d'UTF-16, ou comme "signature" pour indiquer que les données sont UTF-8.
Lequel est le meilleur ?
Sans. Comme l'a répondu Martin Cote, la norme Unicode ne le recommande pas. Cela pose des problèmes avec les logiciels qui ne tiennent pas compte de la nomenclature.
Une meilleure façon de détecter si un fichier est UTF-8 est d'effectuer un contrôle de validité. UTF-8 a des règles strictes concernant les séquences d'octets valides, la probabilité d'un faux positif est donc négligeable. Si une séquence d'octets ressemble à UTF-8, elle l'est probablement.
-1 re " Cela pose des problèmes avec les logiciels non compatibles avec la nomenclature ", cela n'a jamais été un problème pour moi, mais au contraire, le fait que l'absence de nomenclature pose des problèmes avec les logiciels compatibles avec la nomenclature (en particulier Visual C++) a été un problème. Cette affirmation est donc très spécifique à la plate-forme L'objectif de ce document est de donner un point de vue étroit sur Unix, mais il est présenté de manière trompeuse comme s'il s'appliquait de manière générale. Ce qui n'est pas le cas.
UTF-8 avec BOM est mieux identifié. Je suis arrivé à cette conclusion de la manière la plus dure. Je travaille sur un projet dont l'un des résultats est un fichier CSV y compris les caractères Unicode.
Si le fichier CSV est enregistré sans nomenclature, Excel pense qu'il s'agit d'un fichier ANSI et affiche du charabia. Une fois que vous avez ajouté "EF BB BF" au début (par exemple, en le réenregistrant en utilisant Notepad avec UTF-8 ; ou Notepad++ avec UTF-8 et nomenclature), Excel l'ouvre correctement.
L'ajout du caractère BOM dans les fichiers texte Unicode est recommandé par la RFC 3629 : "UTF-8, a transformation format of ISO 10646", novembre 2003. à l'adresse http://tools.ietf.org/html/rfc3629 (cette dernière information a été trouvée à l'adresse suivante http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html )
Merci pour cet excellent conseil en cas de création de fichiers UTF-8 destinés à être utilisés par Excel. Dans d'autres circonstances, cependant, je suivrais les autres réponses et ne tiendrais pas compte de la nomenclature.
Il est également utile si vous créez des fichiers qui ne contiennent que de l'ASCII et auxquels on peut ajouter ultérieurement du non-ascii. Je viens de rencontrer un tel problème : un logiciel qui s'attend à utf8, crée un fichier avec certaines données à éditer par l'utilisateur. Si le fichier initial ne contient que de l'ASCII, qu'il est ouvert dans certains éditeurs puis enregistré, il se retrouve en latin-1 et tout se casse la figure. Si j'ajoute la nomenclature, elle sera détectée comme UTF8 par l'éditeur et tout fonctionne.
J'ai trouvé plusieurs outils liés à la programmation qui nécessitent la nomenclature pour reconnaître correctement les fichiers UTF-8. Visual Studio, SSMS, SoureTree....
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
82 votes
L'UTF-8 est mieux détecté par le contenu que par la nomenclature. La méthode est simple : essayez de lire le fichier (ou une chaîne) en UTF-8 et si cela réussit, supposez que les données sont UTF-8. Sinon, supposez qu'il s'agit de CP1252 (ou d'un autre encodage 8 bits). Tout codage 8 bits non UTF-8 contiendra presque certainement des séquences qui ne sont pas autorisées par UTF-8. L'ASCII pur (7 bits) est interprété comme UTF-8, mais le résultat est correct de cette façon aussi.
42 votes
La recherche du contenu UTF-8 dans des fichiers volumineux prend du temps. Une nomenclature rend ce processus beaucoup plus rapide. En pratique, vous devez souvent faire les deux. Le coupable aujourd'hui est qu'une grande partie du contenu textuel n'est pas Unicode, et je rencontre encore des outils qui disent faire de l'Unicode (par exemple UTF-8) mais qui émettent leur contenu dans une autre page de code.
11 votes
@Tronic Je ne pense pas vraiment que "mieux" convient dans ce cas. Cela dépend de l'environnement. Si vous êtes sûr que tous les fichiers UTF-8 sont marqués d'un signe NOMENCLATURE que de vérifier le NOMENCLATURE est le "mieux" parce qu'elle est plus rapide et plus fiable.
32 votes
L'UTF-8 n'a pas de nomenclature. Lorsque vous placez un point de code U+FEFF au début d'un fichier UTF-8, vous devez prendre des précautions particulières pour le traiter. Il s'agit d'un de ces mensonges de Microsoft en matière de dénomination, comme le fait d'appeler un encodage "Unicode" alors qu'il n'existe pas.
3 votes
Il n'existe pas de méthode qui fonctionne tout le temps. Les métadonnées peuvent être erronées - elles peuvent indiquer Latin1 mais être en réalité UTF-8 ou vice-versa. Les données peuvent être corrompues ou mal générées. Le fait qu'il s'agisse d'un UTF-8 invalide ne signifie pas qu'il ne vaut pas mieux l'interpréter comme "UTF-8 avec un peu de corruption". C'est souvent ce qu'il sera. La BOM permet de distinguer entre "UTF-8 corrompu/invalide" et "Latin1 corrompu/invalide".
0 votes
Vous ne le souhaitez généralement pas, sauf si vous avez un besoin spécifique. Il peut être répercuté dans votre HTML à partir d'un fragment PHP par exemple. L'ordinateur central moderne (et AIX) est conscient de l'UTF-8 little endian, même si ce n'est pas "natif". Tant que vous standardisez, tout devrait bien se passer.
8 votes
"L'ordinateur central moderne (et AIX) est compatible avec le format little endian UTF-8". UTF-8 n'a pas de finalité ! il n'y a pas de brassage d'octets pour mettre des paires ou des groupes de quatre dans le bon "ordre" pour un système particulier ! Pour détecter une séquence d'octets UTF-8, il peut être utile de noter que le premier octet d'un "point de code" d'une séquence de plusieurs octets (les octets qui ne sont PAS des octets ASCII "ordinaires") a le bit MS activé et tous les un à trois autres bits successivement moins significatifs suivis d'un bit de réinitialisation. Le nombre total de ces bits activés est égal à un octet en moins dans ce point de code et ils auront TOUS le MSB activé...
3 votes
Il n'y a pas de différence, car l'utf-8 n'a pas de BOM. Utf-8 + BOM est utf-8+ BOM, un non standard : utilisé par Microsoft, et peut-être quelques autres.
0 votes
Au cas où cela pourrait aider quelqu'un d'autre, j'ai remarqué que (pour les sites web au moins), dans IIS sur les serveurs Windows, il faut toujours enregistrer vos fichiers en UTF-8 avec un BOM (et le bloc-notes ordinaire le fait lorsque vous le sélectionnez dans le menu déroulant Encodage de la boîte de dialogue "Enregistrer sous"). Mais sur les serveurs Unix, j'enregistre toujours mes fichiers en UTF-8 sans BOM (car j'avais des problèmes d'encodage lorsque mon serveur Apache lisait mes fichiers PHP s'ils avaient le BOM). Notepad++ possède un excellent menu "Encodage" qui permet de convertir l'un ou l'autre.
0 votes
En lisant cette discussion sur l'utilité (supposée) d'ajouter une nomenclature, je m'interroge : Comme la plupart des autres codepages n'ont pas ou n'ont (soi-disant) pas besoin d'une identification de codepage, pourquoi l'UTF en a une ? Pourquoi la (les) seule(s) page(s) de code qui doit (doivent) être modifiée(s) est (sont) UTF ? Pourquoi pas un BOM (ou équivalent pour détecter le codage) pour Windows-1252 ou DOS-852 ou ISO 8859-1 ? C'est une exigence très injuste. Une exigence que seul Microsoft veut imposer. :-(
4 votes
L'ordre des octets est utilisé lorsque vous avez deux octets ou plus représentant un seul caractère et que vous devez savoir dans quel sens ils se trouvent pour pouvoir les lire correctement. Windows-1252, ISO-8859-1, etc. sont tous des encodages à un seul octet, il n'y a qu'un octet par caractère, donc il n'y a pas besoin d'une marque d'ordre d'octet pour dire dans quel sens les lire. Ils ne sont pas destinés à détecter quel encodage est utilisé ; ils sont utilisés à cette fin parce qu'il n'y a pas de moyen automatique de le savoir. Mais elles ne sont pas fiables pour cela. Les BOMs sur les encodages multi-octets ne sont pas un truc de Microsoft, seul UTF8+BOM l'est.
1 votes
Fait 1 : UTF-8 est un encodage orienté octet transmis dans l'ordre du réseau, n'a pas d'"ordre d'octet", ne nécessite pas d'"ordre d'octet". Fait 2 : L'utilisation par Windows de l'UCS-2, assez similaire à l'UTF-16, est un encodage multi-octet pour lequel Microsoft ne spécifie aucun BOM. Vérifiez vos faits @TessellatingHeckler .
1 votes
@Flèche : "Je veux des faits exacts" ? Quels faits ai-je mal interprétés ? Vos faits ne contredisent pas ce que j'ai dit.
2 votes
C'est vous qui avez introduit le concept d'"ordre des octets", pas moi (mon commentaire initial n'en parle pas). Mais UTF-8 n'a pas besoin de détection ou de description de l'ordre des octets. Il est formé par une séquence d'octets. Il n'y a donc pas besoin d'une marque d'ordre des octets dans UTF-8. ... Pour l'identification : UTF-8 étant l'encodage le plus fiable pour être correctement détecté (lorsque des codepoints UNICODE supérieurs à 128 sont utilisés) n'a pas besoin de BOM. ... Encore une fois : Fait-1 : UTF-8 n'a pas besoin de "byte order". Fait-2 : Microsoft utilise un encodage (supposé) de 2 octets sans BOM. Pourquoi le BOM est-il nécessaire dans d'autres encodages ? @TessellatingHeckler
1 votes
Utf-8 est un flux d'octets, il n'a donc pas vraiment d'ordre d'octets, mais dans ce cas, le BOM de 3 octets agit de toute façon comme une signature. Le logiciel doit savoir si l'encodage est ANSI ou utf-8. Si le contenu utf-8 est traité comme un encodage ANSI, les caractères résultants seront erronés car les octets des séquences sont traités comme s'ils étaient des caractères uniques, ce qui est faux. D'autre part, si le logiciel traite les fichiers codés ANSI comme utf-8, il y aura des erreurs à cause de séquences brisées ou incomplètes.
1 votes
Arrow Vous vous opposez à des choses que je n'ai jamais dites. Les codages qui /nécessitent/ une nomenclature en ont besoin pour /vous indiquer l'ordre des octets/. Les codages qui n'ont pas /besoin/ d'une BOM n'en ont pas besoin pour vous indiquer l'ordre des octets. UTF-8 a une BOM optionnelle dans la spécification qui peut être utilisée de manière abusive pour détecter l'utilisation d'UTF-8. Il ne s'agit pas de "changer la norme", c'est pourquoi il est différent des codepages classiques. Il ne s'agit pas de détecter l'ordre des octets d'UTF-8, et je n'ai jamais dit cela. VOUS avez introduit l'ordre des octets lorsque vous avez dit " l'utilitaire (supposé) pour ajouter une nomenclature ". Où Microsoft utilise-t-il la nomenclature à 2 octets/aucune nomenclature ? DOTNet utilise 2 octets + BOM pour un exemple.