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


818

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


77
UTF-8 peut être détecté automatiquement mieux par son contenu que par sa 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 du CP1252 (ou d'un autre codage 8 bits). Tout codage huit bits non UTF-8 contiendra presque certainement des séquences qui ne sont pas autorisées par UTF-8. ASCII pur (7 bits) est interprété comme UTF-8, mais le résultat est également correct.
Tronic

39
La numérisation de fichiers volumineux pour le contenu UTF-8 prend du temps. Une nomenclature accélère ce processus. En pratique, vous devez souvent faire les deux. De nos jours, le coupable est que beaucoup de contenu texte n'est pas Unicode, et je rencontre toujours des outils qui disent qu'ils font Unicode (par exemple UTF-8) mais émettent leur contenu sur une page de code différente.
Jeroen Wiert Pluimers

10
@Tronic Je ne pense pas vraiment que "mieux" rentre dans ce cas. Cela dépend de l'environnement. Si vous êtes sûr que tous les fichiers UTF-8 sont marqués avec une nomenclature, vérifiez la nomenclature est la "meilleure" façon, car elle est plus rapide et plus fiable.
mg30rg

32
UTF-8 n'a pas de nomenclature. Lorsque vous placez un point de code U + FEFF au début d'un fichier UTF-8, une attention particulière doit être apportée à son traitement. Ce n'est qu'un de ces mensonges de nommage Microsoft, comme appeler un codage "Unicode" quand il n'y a rien de tel.
tchrist

7
"Le Mainframe moderne (et AIX) est peu conscient de l' UTF-8 " Endian UTF-8 n'a pas de fin ! 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'une séquence à plusieurs octets "codepoint" (les octets qui ne sont PAS des caractères ASCII "simples") a le bit MS défini et tous un à trois de plus bits successivement moins significatifs suivis d'un bit de réinitialisation. Le nombre total de ces bits définis est un octet de moins qui se trouvent dans ce point de code et ils auront TOUS le MSB défini ...
SlySven

Réponses:


773

La nomenclature 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 un fichier comme étant codé en UTF-8.

Normalement, la nomenclature est utilisée pour signaler l' endianité d'un codage, mais comme l'endianité n'est pas pertinente pour UTF-8, la nomenclature est inutile.

Selon le norme Unicode , 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ée dans des contextes où les données UTF-8 sont converties à partir d'autres formes de codage qui utilisent une nomenclature ou lorsque la nomenclature est utilisée comme signature UTF-8 . Voir la sous-section «Byte Order Mark» de la Section 16.8, Specials , pour plus d'informations.


114
Il n'est peut-être pas recommandé, mais d'après mon expérience dans les conversions en hébreu, la nomenclature est parfois cruciale pour la reconnaissance UTF-8 dans Excel, et peut faire la différence entre Jibrish et l'hébreu
Matanya

26
Il n'est peut-être pas recommandé, mais il a fait des merveilles à mon script PowerShell lors de la tentative de sortie de "æøå"
Marius

63
Même si ce n'est pas recommandé par la norme, c'est autorisé, et je préfère grandement avoir quelque chose pour agir comme une signature UTF-8 plutôt que des alternatives de supposer ou de deviner. Un logiciel compatible Unicode doit / doit être capable de gérer sa présence, donc j'encourage personnellement son utilisation.
martineau

30
@ bames53: Oui, dans un monde idéal, stocker le codage des fichiers texte en tant que métadonnées du système de fichiers serait un meilleur moyen de le conserver. Mais la plupart d'entre nous vivant dans le monde réel ne peuvent pas changer le système de fichiers du ou des systèmes d'exploitation sur lesquels nos programmes s'exécutent - donc l'utilisation de la signature de nomenclature indépendante de la plate-forme de la norme Unicode semble être la meilleure et la plus pratique alternative à mon humble avis.
martineau

34
@martineau Hier encore, j'ai rencontré un fichier avec une nomenclature UTF-8 qui n'était pas UTF-8 (c'était CP936). Ce qui est regrettable, c'est que ceux qui sont responsables de l'immense quantité de douleur causée par la nomenclature UTF-8 l'ignorent largement.
bames53

243

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

  • Il n'y a pas de différence officielle entre UTF-8 et UTF-8 BOM-ed
  • Une chaîne UTF-8 de nomenclature commencera par 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 du fichier / flux.

Mais, comme information supplémentaire à cela, la nomenclature pour UTF-8 pourrait être un bon moyen de "sentir" si une chaîne était encodée en UTF-8 ... Ou elle pourrait être une chaîne légitime dans tout autre encodage ...

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

  • L' ISO-8859-1 légitime chaîne "ï» ¿ABC "
  • La chaîne UTF-8 légitime "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 y fier, comme le montre l'exemple ci-dessus

Les encodages doivent être connus et non divins.


60
@Alcott: Vous avez bien compris. 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é codés en utilisant ISO-8859-1, alors la chaîne est "ï» ¿ABC ". Si vous pensez que ces octets ont été encodés en UTF-8, alors c'est "ABC". Si vous ne le savez pas, vous devez essayer de le découvrir. La nomenclature pourrait être un indice. L'absence de caractère invalide lorsqu'il est décodé en UTF-8 pourrait en être une autre ... En fin de compte, à moins que vous ne 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

19
@paercebal Bien que "ï» ¿"soit 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, vous ne pouvez jamais savoir.
user877329

16
@deceze C'est probablement linguistiquement invalide: d'abord ï (ce qui est ok), puis un guillemet sans espace entre les deux (pas ok). ¿Indique qu'il est espagnol mais ï n'est pas utilisé en espagnol. Conclusion: il n'est pas latin-1 avec une certitude bien au-dessus de la certitude sans lui.
user877329

20
@user Bien sûr, cela n'a pas nécessairement de sens. Mais si votre système repose sur des suppositions , c'est là qu'interviennent les incertitudes. Un utilisateur malveillant soumet volontairement du texte commençant par ces 3 lettres, et votre système suppose soudain qu'il regarde UTF-8 avec une nomenclature, traite le texte comme UTF-8 où il doit utiliser Latin-1 et une injection Unicode a lieu. Juste un exemple hypothétique, mais certainement possible. Vous ne pouvez pas juger un encodage de texte par son contenu, point final.
décomposer

40
"Les encodages doivent être connus et non divins." Le cœur et l'âme du problème. +1, bon monsieur. En d'autres termes: soit standardisez votre contenu et dites: "Nous utilisons toujours cet encodage. Période. Écrivez-le de cette façon. Lisez-le de cette façon", ou développez un format étendu qui permet de stocker l'encodage en tant que métadonnées. (Ce dernier a probablement besoin d'un "encodage standard bootstrap" aussi. Comme dire "La partie qui vous indique l'encodage est toujours ASCII.")
jpmc26

135

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

  1. Les fichiers qui ne contiennent aucun texte ne sont plus vides car ils contiennent toujours la nomenclature.
  2. Les fichiers contenant du texte qui se trouve dans le sous-ensemble ASCII d'UTF-8 ne sont plus eux-mêmes ASCII car la nomenclature n'est pas ASCII, ce qui entraîne la panne de certains outils existants, et il peut être impossible pour 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 d'octets arbitraire peut arriver pour commencer avec la séquence exacte qui constitue la nomenclature.
  • Ce n'est pas nécessaire car vous pouvez simplement lire les octets comme s'ils étaient UTF-8; si cela réussit, c'est, par définition, un UTF-8 valide.

8
Concernant le point 1 "Les fichiers qui ne contiennent pas de texte ne sont plus vides car ils contiennent toujours la nomenclature", cela (1) confond le niveau du système de fichiers du système d'exploitation avec le niveau de contenu interprété, plus (2) suppose à tort que l'utilisation de la nomenclature doit mettre un BOM également dans chaque fichier par ailleurs vide. La solution pratique à (1) est de ne pas faire (2). Essentiellement, la réclamation se réduit à "il est possible de placer de manière impraticable une nomenclature dans un fichier autrement vide, empêchant ainsi la détection la plus facile d'un fichier logiquement vide (en vérifiant la taille du fichier)". Encore un bon logiciel devrait pouvoir y faire face, car il a un but.
Bravo et hth. - Alf

7
Concernant le point 2, "Les fichiers contenant du texte ASCII ne sont plus eux-mêmes ASCII", cela confond ASCII avec UTF-8. Un fichier UTF-8 qui contient du texte ASCII n'est pas ASCII, c'est UTF-8. De même, un fichier UTF-16 qui contient du texte ASCII n'est pas ASCII, c'est UTF-16. Etc. ASCII est un code à un octet unique. UTF-8 est une extension de longueur variable 8 bits de l'ASCII. Si les "outils tombent en panne" en raison de> 127 valeurs, ils ne sont tout simplement pas adaptés à un monde 8 bits. Une solution pratique simple consiste à utiliser uniquement des fichiers ASCII avec des outils qui se décomposent pour les valeurs d'octets non ASCII. Une meilleure solution est probablement d'abandonner ces mauvais outils.
Bravo et hth. - Alf

8
Le point 3, "Il n'est pas possible de concaténer plusieurs fichiers ensemble car chaque fichier a maintenant une nomenclature au début" est tout simplement faux. Je n'ai aucun problème à concaténer des fichiers UTF-8 avec BOM, il est donc clairement possible. Je pense que vous vouliez peut-être dire que la terre Unix catne vous donnera pas un résultat net , un résultat qui n'a de nomenclature qu'au début. Si vous vouliez dire cela, c'est parce que cela catfonctionne au niveau des octets, pas au niveau du contenu interprété, et de la même manière catne peut pas traiter des photographies, par exemple. Pourtant, cela ne fait pas beaucoup de mal. En effet, la nomenclature code un espace insécable de largeur nulle.
Bravo et hth. - Alf

20
@ Cheersandhth.-Alf Cette réponse est correcte. Vous signalez simplement des bogues Microsoft.
tchrist

9
@brighty: la situation ne s'améliore pas du tout en ajoutant une nomenclature.
Déduplicateur

84

Voici 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 casse les scripts

Scripts Shell, scripts Perl, scripts Python, scripts Ruby, scripts Node.js ou tout autre exécutable qui doit être exécuté par un interprète - tout commence par une ligne shebang qui ressemble à l'une de celles-ci:

#!/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 encodé en UTF-8, on peut être tenté d'inclure une nomenclature au début. Mais en fait, le "#!" les personnages ne sont pas seulement des personnages. Il s'agit en fait d'un nombre magique qui se trouve être composé de deux caractères ASCII. Si vous mettez quelque chose (comme une nomenclature) avant ces caractères, le fichier ressemblera à un numéro magique différent et cela peut entraîner des problèmes.

Voir Wikipedia, article: Shebang, section: Nombre magique :

Les caractères shebang sont représentés par les deux mêmes octets dans les codages ASCII étendus, y compris UTF-8, qui est couramment utilisé pour les scripts et 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 facultative (BOM); si la fonction "exec" détecte spécifiquement les octets 0x23 et 0x21, alors la présence de la nomenclature (0xEF 0xBB 0xBF) avant le shebang empêchera l'exécution de l'interpréteur de script.Certaines autorités déconseillent d'utiliser la marque d'ordre des octets dans les scripts POSIX (de type Unix), [14] pour cette raison et pour une plus grande interopérabilité et des préoccupations philosophiques. De plus, une marque d'ordre d'octets n'est pas nécessaire en UTF-8, car ce codage n'a pas de problèmes d'endianité; il sert uniquement à identifier l'encodage comme UTF-8. [non souligné dans l'original]

La nomenclature est illégale dans JSON

Voir RFC 7159, section 8.1 :

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

La nomenclature est redondante dans JSON

Non seulement il est illégal dans JSON, mais il n'est pas non plus nécessaire de déterminer l'encodage des caractères car il existe des moyens plus fiables pour déterminer sans ambiguïté à la fois l'encodage des caractères et l'endianness utilisés dans n'importe quel flux JSON (voir cette réponse pour plus de détails).

BOM casse les analyseurs JSON

Non seulement il est illégal dans JSON et non nécessaire , il casse en fait tous les logiciels qui déterminent l'encodage en utilisant la méthode présentée dans RFC 4627 :

Détermination du codage et de l'endianité de JSON, examen des quatre 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 démarre pas avec trois NUL, il ne sera donc pas reconnu
  2. UTF-32LE le premier octet n'est pas suivi de trois NULs, il ne sera donc pas reconnu
  3. UTF-16BE n'a qu'un seul NUL dans les quatre premiers octets, il ne sera donc pas reconnu
  4. UTF-16LE n'a qu'un seul NUL dans les quatre premiers octets, il ne sera donc pas reconnu

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

De plus, si l'implémentation teste un JSON valide comme je le recommande, elle rejettera même l'entrée qui est en effet encodée en UTF-8, car elle ne commence pas par 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. Cela devrait être un nobrainer de ne pas l'utiliser à ce moment-là et pourtant, il y a toujours des gens qui insistent pour casser JSON en utilisant des nomenclatures, des commentaires, différentes règles de citation ou différents types de données. Bien sûr, tout le monde est libre d'utiliser des choses comme les nomenclatures ou autre chose si vous en avez besoin - ne l'appelez pas JSON alors.

Pour d'autres formats de données que JSON, regardez à quoi il ressemble vraiment. Si les seuls encodages sont UTF- * et que le premier caractère doit être un caractère ASCII inférieur à 128, vous disposez déjà de toutes les informations nécessaires pour déterminer à la fois l'encodage et l'endianité de vos données. L'ajout de nomenclatures même en tant que fonctionnalité facultative ne ferait que le rendre plus compliqué et sujet aux erreurs.

Autres utilisations de la nomenclature

Quant aux 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 des informations plus détaillées sur les scripts et la sérialisation, car il s'agit d'un exemple de caractères de nomenclature causant de réels problèmes.


5
rfc7159 qui remplace rfc4627 suggère en fait que le support de la nomenclature n'est peut-être pas si mal. Fondamentalement, le fait de ne pas avoir de nomenclature est juste une erreur ambiguë, de sorte que les anciens logiciels Windows et Unix qui ne sont pas compatibles avec Unicode peuvent toujours traiter utf-8.
Eric Grange

2
Il semble que JSON doive être mis à jour pour le prendre en charge, de même pour les scripts Perl, les scripts Python, les scripts Ruby, Node.js. Ce n'est pas parce que ces plates-formes ont choisi de ne pas inclure de support que l'utilisation de la nomenclature n'est pas nécessairement supprimée. Apple essaie de tuer Adobe depuis quelques années maintenant, et Adobe est toujours là. Mais un message instructif.
htm11h

13
@EricGrange, vous semblez soutenir très fortement la nomenclature, mais vous ne réalisez pas que cela rendrait le format "texte brut" omniprésent, universellement utile et optimal-minimum une relique du passé pré-UTF8! L'ajout de toute sorte d'en-tête (intrabande) au flux de texte brut imposerait, par définition, un protocole obligatoire aux fichiers texte les plus simples, ce qui ne le rendrait plus jamais "le plus simple"! Et pour quel gain? Pour prendre en charge tous les autres , anciens codages de CP qui aussi n'ont des signatures, de sorte que vous pouvez les confondre avec UTF-8? (BTW, ASCII est également UTF-8. Donc, une nomenclature pour ceux-là aussi?;) Allez.)
Sz.

2
Cette réponse est la raison pour laquelle je suis venu à cette question! Je crée mes scripts bash dans Windows et rencontre beaucoup de problèmes lors de la publication de ces scripts sur Linux! Même chose avec les fichiers Jason.
Tono Nam

2
J'aimerais pouvoir voter cette réponse une cinquantaine de fois. Je veux également ajouter qu'à ce stade, l'UTF-8 a remporté la guerre des normes, et presque tout le texte produit sur Internet est UTF-8. Certains des langages de programmation les plus populaires (tels que C # et Java) utilisent UTF-16 en interne, mais lorsque les programmeurs utilisant ces langages écrivent des fichiers dans des flux de sortie, ils les codent presque toujours en UTF-8. Par conséquent, il n'est plus logique d'avoir une nomenclature pour marquer un fichier UTF-8; UTF-8 doit être la valeur par défaut que vous utilisez lors de la lecture et n'essayez d'autres codages qu'en cas d'échec du décodage UTF-8.
rmunn

51

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 BFau début du fichier.

Longue réponse:

À l'origine, il était prévu que Unicode soit 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 à 2 octets, il est nécessaire d'indiquer l'ordre dans lequel ces deux octets sont, et une convention courante pour ce faire est d'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 n'est pas affecté de façon permanente de sorte que sa présence peut être utilisée pour détecter le mauvais ordre d'octets.

UTF-8 a le même ordre d'octets indépendamment de l'endianité de la plateforme, donc une marque d'ordre d'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 d'UTF-16, ou comme une "signature" pour indiquer que les données sont 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 est d'effectuer un contrôle de validité. UTF-8 a des règles strictes sur 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.


8
cela invaliderait également l'UTF-8 valide avec un seul octet erroné, cependant: /
endolith

8
-1 re "Cela cause des problèmes avec les logiciels non compatibles avec la nomenclature.", Cela n'a jamais été un problème pour moi, mais au contraire, cette absence de nomenclature cause des problèmes avec les logiciels compatibles avec la nomenclature (en particulier Visual C ++) a été un problème. Cette déclaration est donc très spécifique à la plate-forme , un point de vue étroit sur Unix-land, mais est présentée à tort comme si elle s'appliquait en général. Ce qui n'est pas le cas.
Bravo et hth. - Alf

6
Non, UTF-8 n'a pas de nomenclature. Cette réponse est incorrecte. Voir la norme Unicode.
tchrist

2
Vous pouvez même penser que vous avez un fichier ASCII pur en regardant simplement les octets. Mais cela pourrait aussi être un fichier utf-16 où vous devriez regarder des mots et non des octets. Les logiciels modernes doivent connaître les nomenclatures. La lecture de utf-8 peut échouer si la détection de séquences non valides, de points de code pouvant utiliser une séquence plus petite ou de points de code qui sont des substituts. Pour utf-16, la lecture peut également échouer en cas de substitution orpheline.
brighty

1
@Alf, je suis en désaccord avec votre interprétation d'une attitude non-BOM comme " spécifique à la plate-forme , un point de vue étroit sur Unix-land". Pour moi, la seule façon dont l'étroitesse d'esprit pouvait résider avec "Unix land" était si MS et Visual C ++ arrivaient avant * NIX, ce qu'ils n'ont pas fait. Le fait que MS (je suppose en connaissance de cause) a commencé à utiliser une nomenclature en UTF-8 plutôt que UTF-16 me suggère que ils ont favorisé la rupture sh, perl, g++et beaucoup d' autres outils gratuits et puissants. Vous voulez que les choses fonctionnent? Achetez simplement les versions MS. MS a créé le problème spécifique à la plate-forme, tout comme le désastre de leur gamme \ x80- \ x95.
bballdave025

30

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

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

La pré-extension du caractère BOM aux fichiers texte Unicode est recommandée par la RFC 3629: "UTF-8, un format de transformation ISO 10646", novembre 2003 sur http://tools.ietf.org/html/rfc3629 (ces dernières informations se trouvent sur: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html )


6
Merci pour cet excellent conseil au cas où l'on créerait des fichiers UTF-8 pour une utilisation par Excel. Dans d'autres circonstances cependant, je continuerais à suivre les autres réponses et à sauter la nomenclature.
barfuin

5
Il est également utile si vous créez des fichiers qui contiennent uniquement de l'ASCII et que des versions ultérieures non ASCII peuvent y être ajoutées. Je viens de rencontrer un tel problème: un logiciel qui attend utf8, crée un fichier avec des données pour l'édition par l'utilisateur. Si le fichier initial ne contient que de l'ASCII, est ouvert dans certains éditeurs puis enregistré, il finit en latin-1 et tout se casse. Si j'ajoute la nomenclature, elle sera détectée comme UTF8 par l'éditeur et tout fonctionne.
Roberto Alsina

1
J'ai trouvé plusieurs outils liés à la programmation qui nécessitent que la nomenclature reconnaisse correctement les fichiers UTF-8 correctement. Visual Studio, SSMS, SoureTree ....
kjbartel

5
Où lisez-vous une recommandation pour l'utilisation d'une nomenclature dans ce RFC? Tout au plus, il est fortement recommandé de ne pas l'interdire dans certaines circonstances où il est difficile de le faire.
Déduplicateur

8
Excel pense que c'est ANSI et affiche du charabia alors le problème est dans Excel.
Isaac

17

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

C'est très ennuyeux quand il apparaît à des endroits difficiles à déboguer ou lorsque les tests sont négligés. Il est donc préférable de l'éviter, sauf si vous devez l'utiliser.


Oui, je viens de passer des heures à identifier un problème causé par un fichier encodé en UTF-8 au lieu d'UTF-8 sans BOM. (Le problème ne s'est présenté que dans IE7, ce qui m'a conduit à une chasse aux oies. J'ai utilisé le "include" de Django.)
user984003

Futurs lecteurs: notez que le problème de tweet que j'ai mentionné ci-dessus n'était pas strictement lié à la nomenclature, mais s'il l'était, le tweet serait tronqué de la même manière, mais au début du tweet.
Halil Özgür

12
@ user984003 Non, le problème est que Microsoft vous a induit en erreur. Ce qu'il appelle UTF-8 n'est pas UTF-8. Ce qu'il appelle UTF-8 sans nomenclature est ce qu'est vraiment UTF-8.
tchrist

qu'est-ce que le «sic» ajoute à votre «sans jeu de mots»
JoelFan

2
@JoelFan Je ne me souviens plus mais je suppose que le jeu de mots aurait pu être voulu malgré la réclamation de l'auteur :)
Halil Özgür

17

Question: Quelle est la différence entre UTF-8 et UTF-8 sans nomenclature? Ce qui est mieux?

Voici quelques extraits de l'article de Wikipedia sur la marque d'ordre des octets (BOM) qui, je crois, offrent une réponse solide à cette question.

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

La norme Unicode permet la nomenclature en UTF-8 , mais ne requiert ni ne recommande son utilisation. L'ordre des octets n'a pas de sens en UTF-8, donc sa 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 utiliser de nomenclature:

La principale motivation pour ne pas utiliser de nomenclature est la rétrocompatibilité avec un logiciel qui n'est pas compatible Unicode ... Une autre motivation pour ne pas utiliser de nomenclature est d'encourager UTF-8 comme encodage "par défaut".

Argument POUR utiliser une nomenclature:

L'argument en faveur de l'utilisation d'une nomenclature est que sans elle, une analyse heuristique est nécessaire pour déterminer quel caractère codant un fichier utilise. Historiquement, une telle analyse, pour distinguer divers codages 8 bits, est compliquée, sujette aux erreurs et parfois lente. Un certain nombre de bibliothèques sont disponibles pour faciliter la tâche, comme le détecteur de charset universel Mozilla et les composants internationaux pour Unicode.

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

En particulier, les compilateurs et interprètes Microsoft et de nombreux logiciels sous Microsoft Windows tels que le Bloc-notes ne liront pas correctement le texte UTF-8, sauf s'il ne contient que des caractères ASCII ou s'il commence par la nomenclature, et ajoutera une nomenclature au début lors de l'enregistrement texte en UTF-8. Google Docs ajoutera une nomenclature lorsqu'un document Microsoft Word est téléchargé en tant que fichier texte brut.

Sur quel est le meilleur, AVEC ou SANS la nomenclature:

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

Ma conclusion:

N'utilisez la nomenclature que si la compatibilité avec une application logicielle est absolument essentielle.

Notez également que bien que l'article Wikipedia référencé indique que de nombreuses applications Microsoft s'appuient sur la nomenclature pour détecter correctement UTF-8, ce n'est pas le cas pour toutes les applications Microsoft. Par exemple, comme l'a souligné @barlop , lors de l'utilisation de l'invite de commandes Windows avec UTF-8 , des commandes telles que typeet morene s'attendent pas à ce que la nomenclature soit présente. Si la nomenclature est présente, elle peut être problématique comme pour d'autres applications.


† La chcpcommande prend en charge UTF-8 ( sans la nomenclature) via la page de codes 65001 .


5
Je ferais mieux de strict à SANS la nomenclature . J'ai trouvé que .htaccesset gzip compressionen combinaison avec UTF-8 BOM donne une erreur d'encodage Changer en Encodage en UTF-8 sans BOM suivre une suggestion comme expliqué ici résoudre les problèmes
Chetabahana

1
«Une autre motivation pour ne pas utiliser de nomenclature est d'encourager l'UTF-8 comme encodage« par défaut ».» - Ce qui est un argument si fort et valable, que vous auriez pu arrêter la réponse ici! ...; -o À moins que vous n'ayez une meilleure idée de la représentation universelle du texte, c'est-à-dire. ;) (Je ne sais pas quel âge vous avez, combien d'années vous avez dû souffrir à l'époque pré-UTF8 (lorsque les linguistes ont désespérément envisagé de changer leur alphabet), mais je peux vous dire qu'à chaque seconde, nous nous rapprochons du débarras le gâchis de tous les anciens codages à un octet sans métadonnées, au lieu d'avoir "l'un" est une pure joie.)
Sz.

Voir également ce commentaire sur la façon dont l'ajout d'une nomenclature (ou quoi que ce soit!) Au format de fichier texte le plus simple, "texte brut", signifierait empêcher exactement le meilleur format de codage de texte universel d'être "clair" et "simple" (c'est-à-dire "sans frais généraux")! ...
Sz.

La nomenclature est généralement problématique sous Linux car de nombreux utilitaires ne prennent pas vraiment en charge Unicode pour commencer (ils seront heureusement tronqués au milieu des points de code par exemple). Pour la plupart des autres environnements logiciels modernes, utilisez la nomenclature chaque fois que l'encodage n'est pas sans ambiguïté (via des spécifications ou des métadonnées).
Eric Grange

9

Cette question a déjà un million et une réponses et beaucoup d'entre elles sont assez bonnes, mais je voulais essayer de clarifier quand une nomenclature doit ou ne doit pas être utilisée.

Comme mentionné, toute utilisation de la nomenclature UTF (Byte Order Mark) pour déterminer si une chaîne est UTF-8 ou non est une supposition éclairée. Si des métadonnées appropriées sont disponibles (comme charset="utf-8"), vous savez déjà ce que vous êtes censé utiliser, mais sinon vous devrez tester et faire des hypothèses. Cela implique de vérifier si le fichier dont provient une chaîne commence par le code octet hexadécimal, EF BB BF.

Si un code d'octet correspondant à la nomenclature UTF-8 est trouvé, la probabilité est suffisamment élevée pour supposer que c'est UTF-8 et vous pouvez y aller. Cependant, une fois obligé de faire cette supposition, une vérification d'erreur supplémentaire pendant la lecture serait toujours une bonne idée au cas où quelque chose se brouille. Vous ne devez supposer qu'une nomenclature n'est pas UTF-8 (c'est-à-dire latin-1 ou ANSI) si l'entrée ne doit certainement pas être UTF-8 en fonction de sa source. S'il n'y a pas de nomenclature, cependant, vous pouvez simplement déterminer s'il est censé être UTF-8 en validant par rapport au codage.

Pourquoi une nomenclature n'est-elle pas recommandée?

  1. Un logiciel non compatible Unicode ou peu conforme peut supposer qu'il s'agit de latin-1 ou ANSI et ne supprimera pas la nomenclature de la chaîne, ce qui peut évidemment causer des problèmes.
  2. Ce n'est pas vraiment nécessaire (vérifiez simplement si le contenu est conforme et utilisez toujours UTF-8 comme solution de rechange quand aucun encodage conforme ne peut être trouvé)

Quand faut- il encoder avec une nomenclature?

Si vous ne parvenez pas à enregistrer les métadonnées d'une autre manière (via une balise charset ou une méta du système de fichiers) et les programmes utilisés comme des nomenclatures, vous devez coder avec une nomenclature. Cela est particulièrement vrai sous Windows où tout élément sans nomenclature est généralement supposé utiliser une page de codes héritée. La nomenclature indique à des programmes comme Office que, oui, le texte de ce fichier est Unicode; voici l'encodage utilisé.

En fin de compte, les seuls fichiers avec lesquels j'ai vraiment eu des problèmes sont CSV. Selon le programme, il doit ou ne doit pas avoir de nomenclature. Par exemple, si vous utilisez Excel 2007+ sous Windows, il doit être codé avec une nomenclature si vous souhaitez l'ouvrir en douceur et ne pas avoir à recourir à l'importation des données.


2
La dernière section de votre réponse est 100% correcte: la seule raison d'utiliser une nomenclature est lorsque vous devez interagir avec un logiciel buggy qui n'utilise pas UTF-8 par défaut pour analyser des fichiers inconnus.
rmunn

8

Il convient de noter que pour certains fichiers, vous ne devez pas avoir la nomenclature même sous Windows. Les exemples sont SQL*plusou les VBScriptfichiers. Dans le cas où ces fichiers contiennent une nomenclature, vous obtenez une erreur lorsque vous essayez de les exécuter.


8

UTF-8 avec BOM n'est utile que si le fichier contient réellement des caractères non ASCII. S'il est inclus et qu'il n'y en a pas, cela cassera peut-être les applications plus anciennes qui auraient autrement interprété le fichier comme ASCII simple. Ces applications échoueront certainement lorsqu'elles rencontreront un caractère non ASCII, donc à mon avis, la nomenclature ne devrait être ajoutée que lorsque le fichier ne peut et ne doit plus être interprété comme du simple ASCII.

Je tiens à préciser que je préfère ne pas du tout avoir la nomenclature. Ajoutez-le si de vieilles ordures se cassent sans lui et remplacer cette application héritée n'est pas possible.

Ne vous attendez pas à une nomenclature pour UTF-8.


7

Cité au 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 qui utilisent une nomenclature ou lorsque la nomenclature est utilisée comme signature UTF-8"


2
Avez-vous un exemple où le logiciel décide d'utiliser UTF-8 avec / sans nomenclature, selon que le codage précédent à partir duquel il codait, avait ou non une nomenclature?! Cela semble être une affirmation absurde
barlop

7

UTF-8 sans BOM n'a pas de BOM, ce qui ne le rend pas meilleur que UTF-8 avec BOM, sauf lorsque le consommateur du fichier a besoin de savoir (ou gagnerait à savoir) si le fichier est encodé en UTF-8 ou pas.

La nomenclature est généralement utile pour déterminer l'endianité du codage, ce qui n'est pas requis dans la plupart des cas d'utilisation.

En outre, la nomenclature peut être un bruit / une douleur inutile pour les consommateurs qui ne la connaissent pas ou s'en soucient, et peut entraîner une confusion chez l'utilisateur.


2
"qui n'a aucune utilité pour UTF-8 car il est de toute façon 8 bits par glyphe." Euh ... non, seuls les glyphes ASCII-7 sont 8 bits en UTF-8. Tout ce qui va au-delà va être de 16, 24 ou 32 bits.
Powerlord

3
"La nomenclature est généralement utile pour déterminer l'endianité du codage, ce qui n'est pas requis pour la plupart des cas d'utilisation." ... l'endianité ne s'applique tout simplement pas à UTF-8, quel que soit le cas d'utilisation
JoelFan

6

Je regarde cela sous un angle différent. Je pense que UTF-8 avec BOM est meilleur car il fournit plus d'informations sur le fichier. J'utilise UTF-8 sans BOM uniquement si je rencontre des problèmes.

J'utilise plusieurs langues (même cyrillique ) sur mes pages depuis longtemps et lorsque les fichiers sont enregistrés sans nomenclature et que je les rouvre pour les éditer avec un éditeur (comme cherouvim l'a également noté), certains caractères sont corrompus.

Notez que le Bloc-notes classique de Windows enregistre automatiquement les fichiers avec une nomenclature lorsque vous essayez d'enregistrer un fichier nouvellement créé avec le codage UTF-8.

Je sauvegarde personnellement les fichiers de script côté serveur (.asp, .ini, .aspx) avec les fichiers BOM et .html sans BOM .


4
Merci pour l'excellente astuce sur le bloc-notes classique de Windows. J'ai déjà passé quelque temps à découvrir exactement la même chose. Ma conséquence a été de toujours utiliser Notepad ++ au lieu du Notepad classique de Windows. :-)
barfuin

Vous feriez mieux d'utiliser madedit. C'est le seul éditeur qui - en mode hexadécimal - affiche un caractère si vous sélectionnez une séquence d'octets utf-8 au lieu d'une base 1: 1 entre octet et caractère. Un éditeur hexadécimal qui connaît un fichier UTF-8 devrait être utilisé comme madedit!
brighty

@brighty Je ne pense pas que vous ayez besoin d'un à un pour le bien de la nomenclature. cela n'a pas d'importance, il ne faut pas grand-chose pour reconnaître qu'une nomenclature utf-8 est efbbbf ou fffe (de fffe si elle est mal lue). On peut simplement supprimer ces octets. Ce n'est pas mal cependant d'avoir un mappage pour le reste du fichier, mais aussi de pouvoir supprimer octet par octet aussi
barlop

@barlop Pourquoi voudriez-vous supprimer une nomenclature utf-8 si le contenu du fichier est encodé en utf-8? La nomenclature est reconnue par les visualiseurs de texte, les commandes de texte et les éditeurs de texte modernes. Une vue un à un d'une séquence utf-8 n'a aucun sens, car n octets donnent un caractère. Bien sûr, un éditeur de texte ou un éditeur hexadécimal devrait permettre de supprimer n'importe quel octet, mais cela peut conduire à des séquences utf-8 invalides.
brighty

@brighty utf-8 avec bom est un encodage, et utf-8 sans bom est un encodage. L'invite cmd utilise utf8 sans bom .. donc si vous avez un fichier utf8, vous exécutez la commande chcp 65001de support utf8, c'est utf8 sans bom. Si vous le faites, type myfileil ne s'affichera correctement que s'il n'y a pas de nomenclature. Si vous faites echo aaa>a.aou echo אאא>a.a pour sortir les caractères dans le fichier aa, et que vous avez chcp 65001, il sortira sans nomenclature.
barlop

6

Lorsque vous souhaitez afficher des informations encodées en UTF-8, vous ne pouvez pas rencontrer de problèmes. Déclarez par exemple un document HTML comme UTF-8 et vous aurez tout affiché dans votre navigateur qui est contenu dans le corps du document.

Mais ce n'est pas le cas lorsque nous avons des fichiers texte, CSV et XML, que ce soit sur Windows ou Linux.

Par exemple, un fichier texte sous Windows ou Linux, l'une des choses les plus faciles à imaginer, ce n'est pas (généralement) UTF-8.

Enregistrez-le en XML et déclarez-le en UTF-8:

<?xml version="1.0" encoding="UTF-8"?>

Il ne s'affichera pas (il ne sera pas lu) correctement, même s'il est déclaré UTF-8.

J'avais une chaîne de données contenant des lettres françaises, qui devaient être enregistrées au format XML pour la syndication. Sans créer un fichier UTF-8 depuis le tout début (changer les options dans IDE et "Créer un nouveau fichier") ou ajouter la nomenclature au début du fichier

$file="\xEF\xBB\xBF".$string;

Je n'ai pas pu enregistrer les lettres françaises dans un fichier XML.


1
FTM, en XML, je pense que vous devriez garder le fichier en ASCII et utiliser des entités à la place.
Alois Mahdal

4
Je sais que c'est une vieille réponse, mais je veux juste mentionner que c'est faux. Les fichiers texte sous Linux (ne peuvent pas parler pour les autres Unix) sont généralement / sont / UTF-8.
Functino

6

Une différence pratique est que si vous écrivez un script shell pour Mac OS X et l'enregistrez au format UTF-8, vous obtiendrez la réponse:

#!/bin/bash: No such file or directory

en réponse à la ligne shebang spécifiant quel shell vous souhaitez utiliser:

#!/bin/bash

Si vous enregistrez au format UTF-8, aucune nomenclature (par exemple dans BBEdit ) ne sera parfaite.


8
C'est parce que Microsoft a inversé le sens de ce que dit la norme. UTF-8 n'a pas de nomenclature: ils ont créé Microsoft UTF-8 qui insère une nomenclature parasite devant le flux de données, puis vous a dit que non, il s'agit en fait d'UTF-8. Ce n'est pas. Il ne fait qu'étendre et corrompre.
tchrist

4

Comme mentionné ci-dessus, UTF-8 avec BOM peut provoquer des problèmes avec des logiciels non compatibles avec BOM (ou compatibles). J'ai une fois édité des fichiers HTML encodés en UTF-8 + BOM avec le KompoZer basé sur Mozilla , en tant que client nécessitant ce programme WYSIWYG .

Invariablement, la mise en page serait détruite lors de l'enregistrement. Il m'a fallu un certain temps pour me débrouiller. Ces fichiers ont ensuite bien fonctionné dans Firefox, mais ont montré une bizarrerie CSS dans Internet Explorer détruisant à nouveau la mise en page. Après avoir manipulé les fichiers CSS liés pendant des heures en vain, j'ai découvert qu'Internet Explorer n'aimait pas le fichier HTML BOMfed. Plus jamais.

De plus, je viens de trouver cela sur Wikipedia:

Les caractères shebang sont représentés par les deux mêmes octets dans les codages ASCII étendus, y compris UTF-8, qui est couramment utilisé pour les scripts et 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 facultative (BOM); si la fonction "exec" détecte spécifiquement les octets 0x23 0x21, alors la présence de la nomenclature (0xEF 0xBB 0xBF) avant le shebang empêchera l'exécution de l'interpréteur de script. Certaines autorités déconseillent d'utiliser la marque d'ordre des octets dans les scripts POSIX (de type Unix), [15] pour cette raison et pour une interopérabilité et des préoccupations philosophiques plus larges.


4

La FAQ Unicode Byte Order Mark (BOM) fournit une réponse concise:

Q: Comment dois-je traiter les nomenclatures?

R: Voici quelques directives à suivre:

  1. Un protocole particulier (par exemple les conventions Microsoft pour les fichiers .txt) peut nécessiter l'utilisation de la nomenclature sur certains flux de données Unicode, tels que les fichiers. Lorsque vous devez vous conformer à un tel protocole, utilisez une nomenclature.

  2. Certains protocoles autorisent les nomenclatures facultatives dans le cas de texte non balisé. Dans ces cas,

    • Lorsqu'un flux de données texte est connu pour être du texte brut, mais d'un codage inconnu, la nomenclature peut être utilisée comme signature. S'il n'y a pas de nomenclature, le codage pourrait être n'importe quoi.

    • Lorsqu'un flux de données texte est connu pour être du texte Unicode simple (mais pas quel endian), alors la nomenclature peut être utilisée comme signature. S'il n'y a pas de nomenclature, le texte doit être interprété comme big-endian.

  3. Certains protocoles orientés octets attendent des caractères ASCII au début d'un fichier. Si UTF-8 est utilisé avec ces protocoles, l'utilisation de la nomenclature comme signature de formulaire de codage doit être évitée.

  4. Lorsque le type précis du flux de données est connu (par exemple, big-endian Unicode ou little-endian Unicode), la nomenclature ne doit pas être utilisée. En particulier, chaque fois qu'un flux de données est déclaré UTF-16BE, UTF-16LE, UTF-32BE ou UTF-32LE, une nomenclature ne doit pas être utilisée.


1

Depuis http://en.wikipedia.org/wiki/Byte-order_mark :

La marque d'ordre des octets (BOM) est un caractère Unicode utilisé pour signaler l'endianité (ordre des octets) d'un fichier texte ou d'un flux. Son point de code est U + FEFF. L'utilisation de la nomenclature est facultative et, si elle est utilisée, doit apparaître au début du flux de texte. Au-delà de son utilisation spécifique comme indicateur d'ordre des octets, le caractère BOM peut également indiquer dans laquelle des plusieurs représentations Unicode le texte est codé.

L'utilisation permanente d'une nomenclature dans votre fichier garantit qu'elle s'ouvre toujours correctement dans un éditeur prenant en charge UTF-8 et BOM.

Mon vrai problème avec l'absence de nomenclature est le suivant. Supposons que nous ayons un fichier contenant:

abc

Sans nomenclature, cela s'ouvre en tant qu'ANSI dans la plupart des éditeurs. Un autre utilisateur de ce fichier l'ouvre donc et ajoute quelques caractères natifs, par exemple:

abg-αβγ

Oups ... Maintenant, le fichier est toujours en ANSI et devinez quoi, "αβγ" n'occupe pas 6 octets, mais 3. Ce n'est pas UTF-8 et cela provoque d'autres problèmes plus tard dans la chaîne de développement.


9
Assurez-vous que les octets parasites apparaissent au début des logiciels non compatibles avec la nomenclature. Yay.
Romain

1
@ Romain Muller: par exemple, PHP 5 générera des erreurs "impossibles" lorsque vous essayez d'envoyer des en-têtes après la nomenclature.
Piskvor a quitté le bâtiment le

5
αβγ n'est pas ascii, mais peut apparaître dans les codages à 8 bits avec ascii. L'utilisation d'une nomenclature désactive un avantage de utf-8, sa compatibilité avec ascii (possibilité de travailler avec des applications de lagacy où ascii pur est utilisé).
ctrl-alt-delor

1
Ce n'est pas la bonne réponse. Une chaîne avec une nomenclature devant elle est tout autre chose. Il n'est pas censé être là et juste tout gâcher.
tchrist

Sans nomenclature, cela s'ouvre en tant qu'ANSI dans la plupart des éditeurs. Je suis absolument d'accord. Si cela se produit, vous avez de la chance si vous traitez avec la page de code correcte, mais en fait, ce n'est qu'une supposition, car la page de code ne fait pas partie du fichier. Une nomenclature est.
brighty

1

Voici mon expérience avec Visual Studio, Sourcetree les demandes d'extraction de et Bitbucket, ce qui m'a posé quelques problèmes:

Il s'avère donc que la nomenclature avec une signature inclura un caractère point rouge sur chaque fichier lors de l'examen d'une demande d'extraction (cela peut être assez ennuyeux).

Entrez la description de l'image ici

Si vous passez la souris dessus, il affichera un caractère comme "ufeff", mais il s'avère que Sourcetree n'affiche pas ces types de bytmarks, donc il se retrouvera très probablement dans vos requêtes de tirage, ce qui devrait être correct car c'est ainsi que Visual Studio 2017 encode de nouveaux fichiers maintenant, alors peut-être que Bitbucket devrait ignorer cela ou le faire apparaître d'une autre manière, plus d'informations ici:

Marqueur de point rouge BitBucket diff view


-4

UTF avec une nomenclature est préférable si vous utilisez UTF-8 dans des fichiers HTML et si vous utilisez le serbe cyrillique, le serbe latin, l'allemand, le hongrois ou une langue exotique sur la même page.

C'est mon avis (30 ans d'informatique et d'informatique).


1
Je trouve que cela est également vrai. Si vous utilisez des caractères en dehors du premier ensemble 255 ASCII et que vous omettez la nomenclature, les navigateurs l'interprètent comme ISO-8859-1 et vous obtenez des caractères tronqués. Compte tenu des réponses ci-dessus, cela semble être dû au fait que les fournisseurs de navigateurs font la mauvaise chose lorsqu'ils ne détectent pas de nomenclature. Mais à moins que vous ne travailliez sur Microsoft Edge / Mozilla / Webkit / Blink, vous n'avez pas d'autre choix que de travailler avec les défauts de ces applications.
asontu

UTF quoi? UTF-8? UTF-16? Autre chose?
Peter Mortensen
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.