Quelle est la différence entre UTF-8 et UTF-8 avec BOM ?
Le BOM UTF-8 est une séquence d'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 BOM est utilisé pour signaler l'endianness d'un encodage, mais comme l'endianness est sans importance pour l'UTF-8, le BOM est inutile.
Conformément à la norme Unicode, le BOM pour les fichiers UTF-8 n'est pas recommandé:
2.6 Systèmes de codage
... L'utilisation d'un BOM n'est ni requise ni recommandée pour l'UTF-8, mais peut être rencontrée dans des contextes où des données UTF-8 sont converties à partir d'autres formes d'encodage qui utilisent un BOM ou lorsque le BOM est utilisé comme une signature UTF-8. Consultez la sous-section "Marque d'ordre de bytes" dans Section 16.8, Caractères spéciaux pour plus d'informations.
Il se peut que ce ne soit pas recommandé, mais d'après mon expérience dans les conversions en hébreu, le BOM est parfois crucial pour la reconnaissance en UTF-8 dans Excel, et peut faire la différence entre du charabia et de l'hébreu
Il se peut que ce ne soit pas recommandé, mais cela a fait des merveilles pour mon script powershell en essayant de produire la sortie "æøå"
Peu importe qu'il ne soit pas recommandé par la norme, c'est autorisé, et je préfère grandement avoir quelque chose agir en tant que signature UTF-8 plutôt que les alternatives de supposition ou de devinette. Le logiciel conforme à Unicode devrait / doit pouvoir gérer sa présence, donc j'encourage personnellement son utilisation.
Les autres excellentes réponses ont déjà répondu que :
EF BB BFMais, en tant qu'information additionnelle à cela, le BOM pour UTF-8 pourrait être une bonne façon de "détecter" si une chaîne a été encodée en UTF-8... Ou cela pourrait être une chaîne légitime dans n'importe quel autre encodage...
Par exemple, les données [EF BB BF 41 42 43] pourraient être :
Alors, même s'il peut être intéressant de reconnaître l'encodage du contenu d'un fichier en regardant les premiers octets, vous ne devriez pas vous fier à cela, comme le montre l'exemple ci-dessus
Les encodages devraient être connus, pas devinés.
Désolé monsieur, mais je ne comprends pas très bien l'exemple que vous venez de donner. Si j'ai une chaîne [EF BB BF 41 42 43], comment pourrais-je l'interpréter? En utilisant ISO-8859-1 ou UTF-8? Parce que, tout comme votre exemple le disait, les deux donneront une chaîne légitime : "ABC" and "ABC".
@Alcott : Vous avez compris correctement. La chaîne [EF BB BF 41 42 43] n'est qu'un tas d'octets. Vous avez besoin d'informations externes pour choisir comment l'interpréter. Si vous pensez que ces octets ont été encodés en utilisant ISO-8859-1, alors la chaîne est "ABC". Si vous pensez que ces octets ont été encodés en utilisant UTF-8, alors c'est "ABC". Si vous ne savez pas, alors vous devez essayer de trouver. Le BOM pourrait être un indice. L'absence de caractères invalides lors de la décodage 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 n'est qu'un tableau d'octets.
@paercebal Alors que "" est valide en latin-1, il est très peu probable qu'un fichier texte commence par cette combinaison. Il en va de même pour les marqueurs ucs2-le/be ÿþ et þÿ. De plus, on ne peut jamais savoir.
Il existe au moins trois problèmes associés au fait de mettre un BOM dans des fichiers encodés en UTF-8.
Et, comme d'autres l'ont mentionné, il n'est ni suffisant ni nécessaire d'avoir un BOM pour détecter qu'un fichier est en UTF-8 :
@cheers-and-hth-alf J'ai maintenant clarifié la déclaration ci-dessus; ce sont des faits, pas de logique impliquée.
Après la modification des points 1 et 2, ces deux points ne sont plus contradictoires en soi. C'est une amélioration. Je discuterai chaque point à tour de rôle.
Re point 1 "Les fichiers qui ne contiennent aucun texte ne sont plus vides car ils contiennent toujours le BOM", cela (1) confond le niveau du système de fichiers OS avec le niveau du contenu interprété, plus cela (2) suppose incorrectement qu'en utilisant le BOM on doit également mettre un BOM dans chaque fichier autrement vide. La solution pratique à (1) est de ne pas faire (2). Essentiellement, la plainte se résume à "il est possible de mettre de manière peu pratique un BOM dans un fichier par ailleurs vide, empêchant ainsi la détection la plus facile de fichier logiquement vide (en vérifiant la taille du fichier)". Malgré tout, un bon logiciel devrait pouvoir gérer cela, car il a un but.
Quelle est la différence entre UTF-8 et UTF-8 sans BOM?
Réponse courte : En UTF-8, un BOM est encodé sous forme des octets EF BB BF au début du fichier.
Réponse longue :
À l'origine, il était prévu que Unicode soit encodé en UTF-16/UCS-2. Le BOM a été conçu pour cette forme d'encodage. Lorsque vous avez des unités de code sur 2 octets, il est nécessaire d'indiquer l'ordre de ces deux octets, et une convention courante pour le faire est d'inclure le caractère U+FEFF en tant que "Marque d'ordre de byte" au début des données. Le caractère U+FFFE est définitivement non attribué afin que sa présence puisse être utilisée pour détecter le mauvais ordre de byte.
UTF-8 a le même ordre d'octets quel que soit le type de processeur, donc une marque d'ordre de byte n'est pas nécessaire. Cependant, elle peut apparaître (sous forme de séquence d'octets EF BB FF) dans des données qui ont été converties en UTF-8 à partir d'UTF-16, ou en tant que "signature" pour indiquer que les données sont en UTF-8.
Lequel est meilleur?
Sans. Comme l'a répondu Martin Cote, la norme Unicode ne le recommande pas. Cela pose problème pour les logiciels qui ne reconnaissent pas le BOM.
Une meilleure façon de détecter si un fichier est en UTF-8 est d'effectuer une vérification de validité. UTF-8 a des règles strictes sur les séquences d'octets qui sont valides, donc la probabilité d'un faux positif est négligeable. Si une séquence d'octets ressemble à de l'UTF-8, c'est probablement le cas.
-1 re "Cela provoque des problèmes avec les logiciels non conçus pour le BOM.", cela n'a jamais été un problème pour moi, au contraire, l'absence de BOM provoque des problèmes avec les logiciels conçus pour le BOM (en particulier Visual C++) a été un problème. Donc, cette déclaration est très spécifique à la plateforme, un point de vue étroit de l'univers Unix, mais est présentée de manière trompeuse comme si elle s'appliquait en général. Ce qui n'est pas le cas.
L'UTF-8 avec BOM est mieux identifié. J'en suis arrivé à cette conclusion de manière difficile. Je travaille sur un projet où l'un des résultats est un fichier CSV, incluant des caractères Unicode.
Si le fichier CSV est enregistré sans BOM, Excel le considère comme un fichier ANSI et affiche n'importe quoi. Une fois que vous ajoutez "EF BB BF" au début (par exemple, en le ré-enregistrant en utilisant le Bloc-notes avec UTF-8; ou Notepad++ avec UTF-8 avec BOM), Excel l'ouvre correctement.
Préfixer le caractère BOM aux fichiers texte Unicode est recommandé par le RFC 3629 : "UTF-8, un format de transformation de l'ISO 10646", Novembre 2003 sur https://www.rfc-editor.org/rfc/rfc3629 (cette dernière information trouvée sur : http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html)
Merci pour ce conseil excellent si l'on crée des fichiers UTF-8 destinés à être utilisés par Excel. Dans d'autres circonstances cependant, je suivrais toujours les autres réponses et sauterais le BOM.
Il est également utile si vous créez des fichiers ne contenant que de l'ASCII et que vous pouvez ensuite y ajouter des caractères non-ASCII. Je viens de rencontrer un tel problème : un logiciel qui attend de l'UTF-8, crée un fichier avec des données à modifier par l'utilisateur. Si le fichier initial ne contient que de l'ASCII, est ouvert dans certains éditeurs, puis enregistré, il se retrouve en latin-1 et tout se casse. Si j'ajoute le BOM, il sera détecté comme UTF-8 par l'éditeur et tout fonctionnera.
J'ai trouvé plusieurs outils liés à la programmation qui nécessitent le BOM pour reconnaître correctement les fichiers UTF-8. Visual Studio, SSMS, Sourcetree...
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.
85 votes
UTF-8 can be auto-detected better by contents than by BOM. The method is simple: try to read the file (or a string) as UTF-8 and if that succeeds, assume that the data is UTF-8. Otherwise assume that it is CP1252 (or some other 8 bit encoding). Any non-UTF-8 eight bit encoding will almost certainly contain sequences that are not permitted by UTF-8. Pure ASCII (7 bit) gets interpreted as UTF-8, but the result is correct that way too.
46 votes
Analyser de gros fichiers à la recherche de contenu UTF-8 prend du temps. Un BOM rend ce processus beaucoup plus rapide. En pratique, vous avez souvent besoin de faire les deux. Le coupable de nos jours est que beaucoup de contenu textuel n'est toujours pas Unicode, et je tombe encore sur des outils qui prétendent faire de l'Unicode (par exemple UTF-8) mais qui émettent leur contenu dans une autre page de codes.
11 votes
@Tronic Je ne pense pas vraiment que "mieux" soit approprié 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 BOM, alors vérifier le BOM est la façon "meilleure", car c'est plus rapide et plus fiable.
38 votes
UTF-8 n'a pas de BOM. Lorsque vous placez un point de code U+FEFF au début d'un fichier UTF-8, il faut prendre des précautions particulières pour le traiter. Il s'agit simplement de l'un de ces mensonges de dénomination de Microsoft, comme appeler un encodage "Unicode" alors qu'il n'existe pas.
3 votes
@Tronic Il n'existe pas de méthode qui fonctionne tout le temps. Les métadonnées peuvent être incorrectes - elles peuvent indiquer Latin1 mais être en réalité du UTF-8 ou vice versa. Les données peuvent être corrompues ou mal générées, donc simplement parce qu'elles sont invalides en UTF-8 ne signifie pas qu'elles ne devraient pas être interprétées comme "UTF-8 avec un peu de corruption". Souvent, c'est ce que ce sera. Le BOM aide à distinguer entre "corrompu/invalidé en UTF-8" et "corrompu/invalidé en Latin1"
0 votes
Vous ne voulez généralement pas faire cela à moins d'avoir un besoin spécifique. Cela peut être renvoyé dans votre HTML depuis un fragment PHP par exemple. Le Mainframe moderne (et AIX) est conscient de l'UTF-8 en "little endian", même si ce n'est pas "natif". Tant que vous standardisez, vous devriez être OK.
10 votes
Le Mainframe moderne (et AIX) est conscient de l'UTF-8 petit boutiste UTF-8 n'a pas de boutisme! il n'y a pas de permutation des 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'une séquence de plusieurs octets "codepoint" (les octets qui ne sont PAS des caractères ASCII "simples") a le bit MS réglé et trois autres bits successivement moins significatifs suivis d'un bit de réinitialisation. Le nombre total de ces bits définis est un octet de moins que celui dans ce codepoint et ils auront TOUS le MSB réglé...
3 votes
Il n'y a pas de différence, car utf-8 n'a pas de BOM. Utf-8 + BOM est utf-8 + BOM, un non standard : utilisé par Microsoft, et peut-être par d'autres.
0 votes
En cas où cela aide quelqu'un d'autre, j'ai remarqué que (pour les sites web au moins), dans IIS sur les serveurs Windows, toujours enregistrer vos fichiers en UTF-8 avec un BOM (et le bloc-notes normal le fait lorsque vous le sélectionnez dans le menu déroulant "Encodage" dans la boîte de dialogue "Enregistrer sous"). Mais sur les serveurs Unix, j'enregistre toujours mes fichiers en UTF-8 sans BOM (parce que j'avais des problèmes d'encodage lorsque mon serveur Apache lisait mes fichiers PHP s'ils avaient le BOM). Notepad++ a un excellent menu "Encodage" pour aider à convertir de l'un à l'autre.
0 votes
En lisant cette discussion sur l'utilité (supposée) d'ajouter un BOM, je me demande : Comme la plupart des autres jeux de caractères n'ont pas besoin d'une identification de jeu de caractères, pourquoi l'UTF en a-t-il besoin ? Pourquoi le seul jeu de caractères qui doit être modifié est-il l'UTF ? Pourquoi pas un BOM (ou équivalent pour détecter l'encodage) pour windows-1252 ou DOS-852 ou ISO 8859-1 ? C'est une exigence très injuste. Une que seul Microsoft veut imposer. :-(
4 votes
@Arrow "l'ordre des octets" est utilisé lorsque vous avez deux octets ou plus représentant un seul caractère, et vous devez savoir dans quel sens ils sont disposés pour pouvoir les lire correctement. Windows-1252, ISO-8859-1, etc. sont tous des encodages sur un octet, il n'y a qu'un seul octet par caractère, donc il n'est pas nécessaire d'utiliser un marqueur d'ordre des octets pour indiquer dans quel sens les lire. Ils ne sont pas conçus pour détecter quel encodage est utilisé ; ils sont utilisés à cette fin car il n'existe aucun moyen automatique de le déterminer autrement. Mais ils ne sont pas fiables à cet égard. Les marqueurs d'ordre des octets sur les encodages multioctets ne sont pas une chose de Microsoft, seul UTF8+BOM l'est.
1 votes
Fact 1: UTF-8 est un encodage orienté octet transmis dans un ordre réseau, n'a pas d'"ordre d'octets", n'a besoin d'aucun "ordre d'octets". Fact 2: l'utilisation de UCS-2 par windows, assez similaire à UTF-16, est un encodage multioctet pour lequel Microsoft ne spécifie aucun BOM. Obtenez vos faits corrects @TessellatingHeckler.
1 votes
@Flèche "avoir mes faits corrects" ? Quels faits ai-je mal compris ? Vos faits ne contredisent pas ce que j'ai dit.
2 votes
Vous êtes celui qui introduit le concept d'"ordre des octets", pas moi (mon commentaire initial n'aborde pas cela). Mais l'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. Par conséquent, il n'est pas nécessaire d'utiliser un marqueur d'ordre des octets en UTF-8. ... Pour l'identification : l'UTF-8 étant le codage le plus fiable pour être détecté correctement (lorsque des points de code UNICODE supérieurs à 128 sont utilisés), il n'a pas besoin de BOM. ... Encore une fois : fait n°1 : l'UTF-8 n'a pas besoin d'"ordre des octets". Fait n°2 : Microsoft utilise un codage sur 2 octets (supposément) sans BOM. Pourquoi le BOM est-il nécessaire dans d'autres codages ? @TessellatingHeckler
1 votes
Utf-8 est un flux d'octets donc il n'a pas vraiment d'ordre d'octets mais dans ce cas, le BOM de 3 octets agit quand même comme une signature. Le logiciel devrait savoir si le codage est ANSI ou utf-8. Dans le cas où le contenu utf-8 est traité comme un codage ANSI, les caractères résultants seront incorrects car les octets des séquences sont traités comme s'ils étaient des caractères uniques, ce qui est incorrect. D'autre part, si le logiciel traite les fichiers encodés en ANSI comme utf-8, il y aura des erreurs en raison de séquences brisées ou incomplètes.
1 votes
@Arrow Vous argumentez contre des choses que je n'ai jamais dites. Les encodages qui /ont besoin/ d'un BOM en ont besoin pour /vous dire l'ordre des octets/. Les encodages qui n'ont pas besoin d'un BOM n'ont pas besoin de vous dire l'ordre des octets. UTF-8 possède un BOM facultatif dans la spécification qui peut être abusé pour détecter l'utilisation d'UTF-8. Ce n'est pas "changer la norme", c'est pourquoi c'est différent des pages de code classiques. Il ne s'agit pas de détecter l'ordre des octets de l'UTF-8, et je ne l'ai jamais dit. VOUS avez introduit l'ordre des octets lorsque vous avez dit "l'utilité (supposée) d'ajouter un BOM". Où Microsoft utilise-t-il 2 octets/pas de BOM ? DOTNet utilise 2 octets + BOM par exemple.
0 votes
Au moins, il y a un bon point pour bom : Des applications comme les créateurs de fichiers rar/zip ne perdent pas de temps à analyser tous les fichiers avant de les compresser, donc compresser les fichiers sans bom entraînerait probablement une perte de données.