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

StackOverflow https://stackoverflow.com/questions/2223882

Question

Ce qui est différent entre UTF-8 et UTF-8 sans nomenclature ? Ce qui est mieux?

Était-ce utile?

La solution

Le UTF-8 BOM est une séquence d'octets au début d'un flux de texte (EF BB BF) qui permet au lecteur de deviner de manière plus fiable un fichier en cours de codage UTF-8.

Normalement, la nomenclature est utilisée pour signaler à l'endianness d'un codage, mais depuis endianness est sans rapport avec UTF-8, la nomenclature est inutile.

Selon le , nomenclature pour fichiers UTF-8 n'est pas recommandé :

  

2.6 Schémas de codage

     

... Utilisation d'une nomenclature n'est ni nécessaire ni recommandé pour UTF-8, mais peut-être   rencontrés dans des contextes où les données UTF-8 est converti à partir d'autres   formes de codage qui utilisent une nomenclature ou lorsque la nomenclature est utilisée comme UTF-8   Signature. Voir le « Byte Order Mark » dans le paragraphe Section 16.8,   Promotions ,   pour plus d'informations.

Autres conseils

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

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

, comme complément d'information à cela, la nomenclature UTF-8 pourrait être un bon moyen de « sentir » si une chaîne a été codée en UTF-8 ... Ou peut-être une chaîne légitime dans tout autre encodage. ..

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

Ainsi, alors qu'il peut être cool de reconnaître le codage d'un contenu de fichier en regardant les premiers octets, vous ne devriez pas compter sur ce point, comme le montrent par l'exemple ci-dessus

codages doivent être connus, pas devinée.

Il y a au moins trois problèmes avec mettre une nomenclature dans les fichiers encodés UTF-8.

  1. Les fichiers qui contiennent aucun texte ne sont plus vides car ils contiennent toujours la nomenclature.
  2. Les fichiers qui contiennent du texte qui se trouve dans le sous-ensemble ASCII UTF-8 ne sont eux-mêmes plus ASCII, car la nomenclature n'est pas ASCII, ce qui rend certains outils existants se décomposent, et il peut être impossible pour les utilisateurs de remplacer ces outils existants.
  3. Il est impossible de concaténer plusieurs fichiers ensemble parce que chaque fichier a maintenant une nomenclature au début.

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

  • Il ne suffit pas, car une séquence d'octets arbitraire peut arriver à commencer par la séquence exacte qui constitue la nomenclature.
  • Il ne faut pas que vous pouvez simplement lire les octets comme si elles étaient UTF-8; si cela réussit, il est, par définition, UTF-8 valide.

It'a une vieille question avec beaucoup de bonnes réponses, mais une chose doit être ajouté.

Toutes les réponses sont très générales. Ce que je voudrais ajouter des exemples de l'utilisation de la nomenclature qui causent effectivement des problèmes réels et encore beaucoup de gens ne savent pas.

BOM scripts casse

scripts Shell, Perl, scripts Python, scripts Ruby, des scripts Node.js ou tout autre exécutable qui doit être exécuté par un interprète - commencent tous par un ligne tralala qui ressemble à un de ceux-ci: 

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

Il indique au système qui interprète 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 « #! » personnages ne sont pas seulement des personnages. Ils sont en fait un qui se trouve être composé de deux caractères ASCII. Si vous mettez quelque chose (comme une nomenclature) avant que ces caractères, le fichier ressemblera il y avait un nombre magique différent et qui peut conduire à des problèmes.

Voir Wikipedia, l'article :

  

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   scripts et autres fichiers texte sur les systèmes Unix actuels. cependant,   fichiers UTF-8 peuvent commencer par la marque d'ordre d'octets en option (BOM); si la   fonction « exec » détecte spécifiquement les octets 0x23 et 0x21, puis   présence de la nomenclature (0xEF 0xBB 0xBF) avant que le tralala empêchera   l'interpréteur de script en cours d'exécution. Certaines autorités recommandent   contre l'utilisation de la marque d'ordre d'octet dans les scripts POSIX (Unix), [14]   pour cette raison et pour élargir l'interopérabilité et philosophique   préoccupations. En outre, une marque d'ordre d'octet n'est pas nécessaire en UTF-8,   que celui codant pour ne pas les questions endianness; elle ne sert qu'à   identifier le codage UTF-8. [Italiques ajoutés]

BOM est illégale dans JSON

Voir RFC 7159, Section 8.1 :

  

Implémentations NE DOIVENT PAS ajouter une marque d'ordre d'octets au début d'un texte JSON.

nomenclature est redondant dans JSON

Non seulement il est illégale dans JSON, il est également pas besoin pour déterminer le codage de caractères, car il existe des moyens plus fiables pour déterminer sans ambiguïté à la fois le codage des caractères et boutisme utilisés dans un cours d'eau JSON (voir cette réponse pour plus de détails).

nomenclature casse parseurs JSON

Non seulement il est illégale dans JSON et pas besoin , il fait casse tous les logiciels qui déterminent le codage en utilisant la méthode présentée dans < a href = "https://tools.ietf.org/html/rfc4627" rel = "noreferrer"> RFC 4627 :

Détermination de l'encodage et du endianness JSON, en examinant les 4 premiers octets de 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 la nomenclature, 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 donc il ne sera pas reconnu
  2. UTF-32LE le premier octet n'est pas suivie par 3 NUL donc il ne sera pas reconnu
  3. UTF-16BE a seulement 1 NUL dans les 4 premiers octets il ne sera pas reconnu
  4. UTF-16LE a seulement 1 NUL dans les 4 premiers octets il ne sera pas reconnu

En fonction de la mise en œuvre, tous ceux qui peuvent être interprétés de manière incorrecte en UTF-8, puis mal interprété or rejeté comme non valide UTF-8, ou non reconnu du tout.

En outre, si les essais de mise en œuvre valable JSON comme je le recommande, il rejettera même l'entrée qui est en effet codé en UTF-8, car il ne commence pas par un caractère ASCII <128 comme il se doit selon la RFC.

Autres formats de données

nomenclature dans JSON est pas nécessaire, est un logiciel illégal et les pauses qui fonctionne correctement selon le RFC. Il devrait être un nobrainer à tout simplement pas l'utiliser alors et pourtant, il y a toujours des gens qui insistent sur la rupture JSON en utilisant, commentaires, BOM différentes règles ou différents citant des types de données. Bien sûr, tout le monde est libre d'utiliser des choses comme BOM ou toute autre chose si vous en avez besoin -. Il suffit de ne pas appeler JSON alors

Pour les autres formats de données que JSON, jetez un oeil à quoi il ressemble vraiment. Si les seuls encodages sont UTF- * et le premier caractère doit être inférieur à 128 caractères ASCII alors vous avez déjà toutes les informations nécessaires pour déterminer à la fois le codage et le boutisme de vos données. Ajout BOM même en option ne ferait que rendre plus complexe et sujette aux erreurs.

Autres utilisations de nomenclature

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

  

Ce qui est différent entre UTF-8 et UTF-8 sans BOM?

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

Réponse longue:

A l'origine, il était prévu que Unicode serait encodé en UTF-16 / UCS-2 . La nomenclature a été conçu pour cette forme de codage. Lorsque vous avez des unités de code 2 octets, il est nécessaire d'indiquer quel ordre ces deux octets sont, et une convention commune pour ce faire est d'inclure le caractère U + FEFF comme « Byte Order Mark » au début des données. Le caractère U + FFFE est en permanence non affecté de telle sorte que sa présence peut être utilisée pour détecter l'ordre mal d'octets.

UTF-8 a le même ordre d'octets quelle que soit la plate-forme boutisme, donc une marque d'ordre d'octet n'est pas nécessaire. Toutefois, il peut se produire (en tant que la séquence d'octets de EF BB FF) en données qui a été converti en UTF-8 à partir de UTF-16, ou comme une « signature » pour indiquer que les données sont UTF-8.

  

Quel est le meilleur?

Sans. Comme Martin Côté a répondu, le standard Unicode ne recommande pas. Il provoque des problèmes avec des logiciels non-BOM-courant.

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

BOM tend à flèche (sans jeu de mots (sic)) quelque part, quelque part. Et quand il booms (par exemple, ne soit pas reconnu par les navigateurs, éditeurs, etc.), il apparaît que les personnages étranges  au début du document (par exemple, un fichier HTML, JSON réponse , RSS , etc.) et provoque le genre de la .

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

  

Question: Ce qui est différent entre UTF-8 et UTF-8 sans BOM? Quel est le meilleur?

Voici quelques extraits de l'article de Wikipédia sur la marque d'ordre d'octet (BOM) que je crois offrir une réponse solide à cette question.

Sur le sens de la nomenclature et UTF-8:

  

Le standard Unicode permet BOM UTF-8 , mais ne nécessite pas   ou recommander son utilisation. L'ordre des octets n'a pas de sens en UTF-8, de sorte que son   utiliser uniquement en UTF-8 est de signaler au début que le flux de texte est   codé en UTF-8.

Argument pour PAS en utilisant une nomenclature:

  

La principale motivation pour ne pas utiliser une nomenclature est la rétrocompatibilité   avec le logiciel qui ne sont pas compatibles Unicode ... Une autre motivation pour ne pas   en utilisant une nomenclature est d'encourager UTF-8 comme encodage « par défaut ».

Argument pour en utilisant une nomenclature:

  

L'argument pour utiliser une nomenclature est que sans elle, l'analyse heuristique est   nécessaire pour déterminer ce codage de caractères d'un fichier est utilisé.   Historiquement, une telle analyse, pour distinguer différents codages 8 bits, est   complexe, sujette aux erreurs, et parfois lent. Un certain nombre de bibliothèques   sont disponibles pour faciliter la tâche, comme Mozilla Universal Charset   Détecteur et International Components for Unicode.

     

Les programmeurs supposent à tort que la détection de UTF-8 est également   difficile (il est pas à cause de la grande majorité des séquences d'octets   sont UTF-8, tandis que les encodages invalides ces bibliothèques essaient de   distinguer permettre à toutes les séquences d'octets possibles). Par conséquent, pas tous   programmes comprennent Unicode effectuer une telle analyse et comptent 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   correctement lire le texte UTF-8 à moins qu'il ne dispose que de caractères ASCII ou il   commence par la nomenclature, et ajoutera une nomenclature au début lorsque vous enregistrez du texte   comme UTF-8. Google Docs ajoutera une nomenclature lorsqu'un document Microsoft Word est   téléchargé sous forme de fichier texte brut.

qui est mieux, AVEC ou SANS la nomenclature:

  

IETF recommande que, si un protocole soit (a) utilise toujours UTF-8,   ou (b) a une autre façon d'indiquer ce que le codage est utilisé,   il « DOIT interdire l'utilisation de U + FEFF comme signature. »

Ma conclusion:

Utilisez la nomenclature uniquement si la compatibilité avec une application logicielle est absolument indispensable.

Notez également que si l'article de Wikipedia référencé indique que de nombreuses applications Microsoft comptent sur la nomenclature pour détecter correctement UTF-8, ce n'est pas le cas pour tous applications Microsoft. Par exemple, comme l'a souligné @barlop , lorsque vous utilisez l'invite de commande Windows avec UTF-8 † , des commandes telles type et more ne vous attendez pas la nomenclature à être présente. Si la nomenclature est présent, il peut être problématique que pour d'autres applications.

La commande † chcp offre un soutien pour UTF-8 ( sans la nomenclature) via la page de code 65001 .

Cité au bas de la page Wikipédia sur la nomenclature: http: // fr .wikipedia.org / wiki / octet-order_mark # cite_note-2

  

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

Il convient de noter que pour certains fichiers ne doit pas ont la nomenclature même sous Windows. Des exemples sont des fichiers SQL*plus ou VBScript. Dans le cas où ces fichiers contient une nomenclature que vous obtenez une erreur lorsque vous essayez de les exécuter.

Cette question a déjà un million et une réponse et beaucoup d'entre eux sont très bons, mais je voulais essayer de préciser quand une nomenclature doit ou ne doit pas être utilisé.

Comme mentionné précédemment, l'utilisation de la nomenclature UTF (Byte Order Mark) pour déterminer si une chaîne de caractères UTF-8 est ou non est conjecture instruite. S'il y a des métadonnées disponibles appropriée (comme charset="utf-8"), alors vous savez déjà ce que vous êtes censé être à l'aide, mais sinon, vous aurez besoin de tester et de faire quelques hypothèses. Cela implique de vérifier si le fichier une chaîne vient commence par le code octet hexadécimal, EF BB BF.

Si un code d'octet correspondant à l'UTF-8 BOM se trouve, la probabilité est assez élevée pour assumer UTF-8 et vous pouvez aller de là. Lorsque forcé de faire cette supposition, cependant, erreur supplémentaire de vérification lors de la lecture serait encore une bonne idée dans le cas où quelque chose arrive brouillées. Vous ne devez supposer une nomenclature n'est pas UTF-8 (à savoir latin-1 ou ANSI) si l'entrée ne doit certainement pas être UTF-8 sur la base 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 contre l'encodage.

Pourquoi une nomenclature déconseillés?

  1. non-Unicode-aware ou mal logiciel conforme peut supposer qu'il est latin-1 ou ANSI et ne supprimera pas la nomenclature de la chaîne, ce qui peut évidemment causer des problèmes.
  2. Il est pas vraiment nécessaire (juste vérifier si le contenu sont conformes et toujours utiliser UTF-8 comme serveur par défaut en l'absence de codage conforme peut être trouvé)

Lorsque devrait encoder avec une nomenclature?

Si vous ne parvenez pas à enregistrer les métadonnées de toute autre manière (par le biais d'une balise charset ou système de fichiers méta) et les programmes utilisés comme BOM, vous devez coder avec une nomenclature. Cela est particulièrement vrai sur Windows où tout sans une nomenclature est généralement supposé utiliser une page de code existant. La nomenclature dit des programmes comme Office que, oui, le texte dans ce fichier est Unicode; voici l'encodage utilisé.

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

UTF-8 avec BOM aide uniquement si le fichier contient effectivement des caractères non-ASCII. Si elle est incluse et il n'y a pas, alors il peut briser les anciennes applications qui auraient autrement interprété le fichier en ASCII. Ces applications vont certainement échouer quand ils viennent à travers un caractère non ASCII, donc à mon avis, la nomenclature ne doit être ajouté lorsque le fichier peut, et doit, plus être interprété comme ASCII.

Edit: Je veux juste préciser que je préfère ne pas avoir la nomenclature du tout, ajoutez si quelques vieux breaks ordures sans elle, et remplacer cette application héritée est impossible

.

Ne pas faire quoi que ce soit attendre une nomenclature pour UTF8.

UTF-8 sans BOM n'a pas de nomenclature, ce qui ne fait pas mieux que UTF-8 avec BOM, sauf si le consommateur du fichier doit savoir (ou bénéficierait de savoir) si le fichier est UTF- 8-codé ou non.

La nomenclature est généralement utile pour déterminer le boutisme du codage, qui ne sont pas requis pour la plupart des cas d'utilisation.

En outre, la nomenclature peut être le bruit / douleur inutile pour les consommateurs qui ne savent pas ou se soucient, et peut entraîner la confusion des utilisateurs.

Je regarde cela d'un point de vue différent. Je pense que UTF-8 avec BOM est mieux car il fournit plus d'informations sur le fichier. J'utilise UTF-8 sans BOM que si je fais face à des problèmes.

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

Notez que classique

Lorsque vous souhaitez afficher des informations codées en UTF-8 vous ne pouvez pas faire face à des problèmes. Déclarer par exemple un document HTML au format 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 du texte, CSV et les fichiers XML, soit sous Windows ou Linux.

Par exemple, un fichier texte sous Windows ou Linux, l'une des choses les plus simples qu'on puisse imaginer, ce n'est pas (en général) UTF-8.

Enregistrer comme XML et le déclarer comme UTF-8: 

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

Il ne sera pas affiché (il ne sera pas lire) correctement, même si elle est déclarée comme UTF-8.

J'ai eu une chaîne de données contenant des lettres françaises, qui devaient être sauvegardées au format XML pour la syndication. Sans créer un fichier UTF-8 dès le début (la modification des options en IDE et « Créer un nouveau fichier ») ou en ajoutant 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.

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

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

en réponse à la ligne de spécification tralala shell que vous souhaitez utiliser: 

#!/bin/bash

Si vous enregistrez en UTF-8, aucune nomenclature (par exemple dans BBEdit ) tout sera bien.

Comme mentionné ci-dessus, UTF-8 avec BOM peut causer des problèmes avec des logiciels non-BOM-Aware (ou compatible). Une fois, je modifié des fichiers HTML encodés en UTF-8 + nomenclature avec le Nvu , comme client exigeait que programme WYSIWYG .

Invariablement la mise en page serait être détruit lors de l'enregistrement. Il a fallu un certain temps pour mon violon ma façon de contourner cela. Ces fichiers ont ensuite travaillé bien dans Firefox, mais a montré une bizarrerie CSS dans Internet Explorer détruire la mise en page, encore une fois. Après jongler avec les fichiers CSS liés pendant des heures sans succès j'ai découvert que Internet Explorer n'a pas aimé le fichier HTML BOMfed. Plus jamais.

De plus, je viens de trouver ce dans Wikipedia:

  

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 les scripts et autres fichiers texte sur les systèmes Unix actuels. , Les fichiers UTF-8 peuvent toutefois commencer par la marque d'ordre d'octets en option (BOM); si la fonction « exec » détecte spécifiquement les octets 0x23 0x21, alors la présence de la nomenclature (0xEF 0xBB 0xBF) avant que le tralala empêchera l'interpréteur de script en cours d'exécution. Certaines autorités recommandent de ne pas utiliser la marque d'ordre des octets dans les scripts POSIX (Unix), [15] pour cette raison et pour élargir l'interopérabilité et les préoccupations philosophiques

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

  

Q: Comment dois-je traiter BOM

     

A: Voici quelques directives à suivre:

     
      

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

    2.   

  2. Certains protocoles permettent BOM en option dans le cas d'un texte non marqué. Dans ces cas,

         
        

    • Si un flux de données texte est connu pour être le texte brut, mais l'encodage inconnu, la nomenclature peut être utilisé comme une signature. S'il n'y a pas de nomenclature,   l'encodage pourrait être quelque chose.

      •   

    • Si un flux de données de texte est connu pour être texte Unicode simple (mais pas qui endian), puis nomenclature peut être utilisé comme une signature. S'il y a   est pas de nomenclature, le texte doit être interprété comme grand-boutiste.

      •   
    3.   

  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 du   Nomenclature comme la signature de forme de codage doit être évité.

    4.   

  4. Lorsque le type précis du flux de données est connu (par exemple Unicode big-endian ou Unicode little-endian), la nomenclature ne doit pas être utilisé. Dans   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é.

    5.   

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

  

La marque d'ordre d'octet (BOM) est un Unicode   caractère utilisé pour signaler la   boutisme (ordre des octets) d'un fichier texte   ou écouter. Son point de code est U + FEFF.   l'utilisation de nomenclature est facultative, et, le cas échéant,   devrait apparaître au début du texte   courant. Au-delà de son utilisation spécifique en tant que   indicateur d'ordre des octets, la nomenclature   caractère peut également indiquer quelles   les plusieurs représentations Unicode   le texte est codé dans.

Toujours en utilisant une nomenclature dans votre dossier fera en sorte qu'il ouvre toujours correctement dans un éditeur qui prend en charge UTF-8 et la nomenclature.

Mon vrai problème avec l'absence de nomenclature est la suivante. Supposons que nous avons un fichier qui contient: 

abc

Sans nomenclature cela ouvre ANSI dans la plupart des éditeurs. Donc, un autre utilisateur de ce fichier ouvre et certains caractères natifs ajoute, par exemple: 

abg-αβγ

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

Voici mon expérience avec les demandes de traction Visual Studio, et Bitbucket, sources du qui a été de me donner quelques problèmes:

se Ainsi, sur la nomenclature avec la signature comprendra un caractère de point rouge sur chaque fichier lors de l'examen d'une demande de traction (peut être assez ennuyeux).

Si vous passez la souris dessus, il affiche un caractère comme « ufeff », mais se révèle sources du ne montre pas ces types de bytemarks, il sera très probablement dans vos demandes de traction, ce qui devrait être ok parce que c'est comment VS 2017 encodent nouveaux fichiers maintenant bitbucket devrait peut-être ignorer ou faire apparaître dans une autre façon, plus d'infos ici:

marqueur de points rouges bitbucket diff voir

UTF avec BOM est mieux si vous utilisez UTF-8 dans les fichiers HTML, si vous utilisez en serbe cyrillique, serbe latin, l'allemand, le hongrois ou quelque chose langue exotique dans la même page. C'est mon avis (30 ans de l'informatique et de l'industrie informatique).

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top