Quelle est la différence entre UTF-8 et UTF-8 sans nomenclature?
Quelle est la différence entre UTF-8 et UTF-8 sans un BOM ? Ce qui est mieux?
La nomenclature UTF-8 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 qu'un fichier est codé en UTF-8.
Normalement, la nomenclature est utilisée pour signaler l’endianité d’un codage, mais l’endianité n’ayant pas d’importance pour UTF-8, elle n’est pas nécessaire.
Selon le standard Unicode , le BOM pour les fichiers UTF-8 n'est pas recommandé:
2.6 Schémas de codage
... L'utilisation d'une nomenclature n'est ni requise ni recommandée pour UTF-8, mais peut se produire dans des contextes où les données UTF-8 sont converties à partir d'autres formulaires de codage utilisant une nomenclature ou dans lesquels la nomenclature est utilisée comme signature UTF-8. . Reportez-vous à la sous-section "Byte Order Mark" dans Section 16.8, Spéciaux , pour plus d'informations.
Les autres excellentes réponses ont déjà répondu que:
- Il n'y a pas de différence officielle entre UTF-8 et BOM-ed UTF-8
- Une chaîne UTF-8 BOM-ed commencera 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, en tant qu’information supplémentaire, la nomenclature pour UTF-8 pourrait être un bon moyen de "sentir" si une chaîne était codée en UTF-8 ... Ou cela pourrait être une chaîne légitime dans tout autre codage ...
Par exemple, les données [EF BB BF 41 42 43] pourraient être:
- Le légitime ISO-8859-1 chaîne "ï" ¿ABC "
- Le légitime TF-8 chaîne "ABC"
Ainsi, même s'il peut être intéressant de reconnaître l'encodage d'un contenu de fichier en regardant les premiers octets, vous ne devriez pas vous en fier, comme le montre l'exemple ci-dessus.
Les codages doivent être connus et non devinés.
L'insertion d'une nomenclature dans des fichiers codés UTF-8 pose au moins trois problèmes.
- Les fichiers qui ne contiennent pas de texte ne sont plus vides, car ils contiennent toujours la nomenclature.
- Les fichiers contenant du texte contenu dans le sous-ensemble ASCII de UTF-8 ne sont plus eux-mêmes ASCII, car la nomenclature n’est pas ASCII, ce qui entraîne la défaillance de certains outils existants. impossible pour les utilisateurs de remplacer ces outils hérités.
- Il n'est pas possible de concaténer plusieurs fichiers 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:
- Cela ne suffit pas, car une séquence d'octets arbitraire peut arriver 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 au format UTF-8; Si cela réussit, il est, par définition, valide UTF-8.
C'est une vieille question avec beaucoup de bonnes réponses mais une chose devrait être ajoutée.
Toutes les réponses sont très générales. Ce que j'aimerais ajouter, ce sont des exemples d'utilisation de la nomenclature qui posent de véritables problèmes et pourtant, beaucoup de gens l'ignorent.
BOM rompt les scripts
Les scripts shell, les scripts Perl, les scripts Python, les scripts Ruby, les scripts Node.js ou tout autre fichier exécutable devant être exécuté par un interpréteur - commencent tous par un ligne Shebang qui ressemble à l'un de ceux-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 réalité le "#!" les personnages ne sont pas que des personnages. Ils sont en fait un nombre magique qui se compose de deux caractères ASCII. Si vous mettez quelque chose (comme une nomenclature) avant ces caractères, le fichier aura alors un numéro magique différent, ce qui peut entraîner des problèmes.
Voir Wikipedia, article: Shebang, section: Nombre magique :
Les caractères Shebang sont représentés par les mêmes deux octets dans les codages étendus ASCII, y compris UTF-8, qui est couramment utilisé pour les scripts et autres fichiers texte sur les systèmes de type Unix actuels. Toutefois, les fichiers UTF-8 peuvent commencer par la marque optionnelle d’octets (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 Shebang empêchera l'exécution de l'interpréteur de script. Certaines autorités recommandent de ne pas utiliser la marque d'ordre des octets dans les scripts POSIX (de type Unix) [14], pour cette raison et pour des raisons plus larges d'interopérabilité et de philosophie. De plus, une marque d'ordre d'octet n'est pas nécessaire dans UTF-8, car ce codage n'a pas de problèmes de finalité. il sert uniquement à identifier le codage comme UTF-8. [emphase ajoutée]
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'octet au début d'un texte JSON.
BOM est redondant dans JSON
Non seulement il est illégal en JSON, mais il est également inutile pour déterminez le codage des caractères car il existe des méthodes plus fiables pour déterminer sans ambiguïté à la fois le codage des caractères et l’endianité utilisés dans tout flux JSON (voir cette réponse pour plus de détails).
BOM rompt les analyseurs JSON
Non seulement il est illégal en JSON et n'est pas nécessaire , mais en réalité casse tous les logiciels qui déterminent le codage à l'aide de la méthode présentée dans RFC 4627 :
Déterminer l'encodage et l'endianité de JSON, en examinant les 4 premiers octets pour l'octet NUL:
00 00 00 xx - UTF-32BE
00 xx 00 xx - UTF-16BE
xx 00 00 00 - UTF-32LE
xx 00 xx 00 - UTF-16LE
xx xx xx xx - UTF-8
Maintenant, si le fichier commence par BOM, cela 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:
- UTF-32BE ne commence pas par trois NUL, il ne sera donc pas reconnu
- UTF-32LE le premier octet n'est pas suivi de 3 NUL afin qu'il ne soit pas reconnu
- UTF-16BE a seulement 1 NUL dans les 4 premiers octets, il ne sera donc pas reconnu
- UTF-16LE a seulement 1 NUL dans les 4 premiers octets, il ne sera donc pas reconnu
Selon l’implémentation, tous ces éléments peuvent être interprétés de manière incorrecte en tant que UTF-8 puis mal interprétés ou rejetés en tant que UTF-8 non valides, ou non reconnus du tout.
De plus, si l’implémentation teste le code JSON valide comme recommandé, il rejettera même l’entrée codée au format UTF-8 car elle ne commence pas par un caractère ASCII <128, contrairement à ce qu’elle devrait être en vertu de la RFC.
Autres formats de données
BOM en JSON n'est pas nécessaire, est illégal et casse un logiciel qui fonctionne correctement conformément à la RFC. Cela ne devrait pas être un enthousiasme de ne pas l'utiliser à ce moment-là et pourtant, il y a toujours des gens qui insistent pour rompre le JSON en utilisant des nomenclatures, des commentaires, des règles de citation différentes ou des types de données différents. Bien entendu, tout le monde est libre d'utiliser des éléments tels que les nomenclatures ou toute autre fonction, si vous en avez besoin. N'appelez pas cela JSON pour le moment.
Pour les formats de données autres que JSON, regardez à quoi ça ressemble vraiment. Si les seuls codages 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 le codage et l'endianité de vos données. L'ajout de nomenclatures, même en tant que fonctionnalité facultative, ne ferait que compliquer les choses et favoriser les erreurs.
Autres utilisations de la nomenclature
En ce qui concerne les utilisations en dehors de JSON ou de scripts, je pense qu’il existe 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 posant de réels problèmes.
Quelle est la différence entre UTF-8 et UTF-8 sans nomenclature?
Réponse courte: En UTF-8, une nomenclature est codée sous la forme d'octets EF BB BF au début du fichier.
Longue réponse:
À l'origine, il était prévu que nicode serait codé en UTF-16/UCS-2. La nomenclature a été conçue pour cette forme de codage. Lorsque vous avez des unités de code à 2 octets, il est nécessaire d'indiquer dans quel ordre se trouvent ces deux octets. Il est généralement convenu d'inclure le caractère U + FEFF en tant que "Marque d'ordre d'octet" au début des données. Le caractère U + FFFE est définitivement attribué, de sorte que sa présence peut être utilisée pour détecter le mauvais ordre d'octet.
UTF-8 a le même ordre d'octet quelle que soit son extrémité, donc une marque d'ordre d'octet n'est pas nécessaire. Toutefois, cela peut se produire (en tant que séquence d'octets EF BB FF) dans des données converties au format UTF-8 à partir d'UTF-16 ou sous forme de "signature" pour indiquer que les données sont au format UTF-8.
Ce qui est mieux?
Sans pour autant. Comme le disait Martin Côté, le standard Unicode ne le recommande pas. Cela pose des problèmes avec les logiciels non compatibles avec les nomenclatures.
Un meilleur moyen de détecter si un fichier est au format UTF-8 consiste à effectuer un contrôle de validité. UTF-8 a des règles strictes sur 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, c'est bien le cas.
UTF-8 avec nomenclature 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 , y compris les 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 avez ajouté "EF BB BF" à l'avant (par exemple, en le réenregistrant à l'aide de Notepad avec UTF-8; ou de Notepad ++ avec UTF-8 avec BOM), Excel l'ouvre parfaitement.
Le préfixe du caractère de la nomenclature dans les fichiers texte Unicode est recommandé par la RFC 3629: "UTF-8, format de transformation de l’ISO 10646", novembre 2003 à l'adresse http://tools.ietf.org/html/rfc3629 (cette dernière information trouvée à: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html )
La nomenclature tend à exploser (sans jeu de mots (sic)) quelque part, quelque part. Et quand il explose (par exemple, il n'est pas reconnu par les navigateurs, les éditeurs, etc.), il apparaît sous la forme de caractères étranges  au début du document (par exemple, fichier HTML, JSON réponse, RSS , etc.) et provoque le genre d'embarras comme le problème d'encodage récent rencontré lors de l'entretien d'Obama sur Twitter .
C'est très ennuyant quand il apparaît dans 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.
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 le marque d'ordre de byte (BOM) qui, je crois, offre une réponse solide à cette question.
Sur la signification de la nomenclature et de l'UTF-8:
La norme Unicode autorise BOM dans TF-8, mais n'exige ni ne recommande son utilisation. L'ordre des octets n'a aucune signification dans UTF-8, aussi son utilisation dans UTF-8 consiste-t-elle uniquement à signaler au début que le flux de texte est codé en UTF-8.
Argument pourPASen utilisant une nomenclature:
La principale motivation pour ne pas utiliser de nomenclature est une compatibilité ascendante avec des logiciels non compatibles Unicode ... Une autre motivation pour ne pas utiliser de nomenclature est d'encourager UTF-8 en tant que codage "par défaut".
Argument POURen utilisant 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 le type de codage de caractères utilisé par un fichier. Historiquement, une telle analyse permettant de distinguer différents codages 8 bits est complexe, sujette aux erreurs et parfois lente. Un certain nombre de bibliothèques sont disponibles pour faciliter la tâche, telles que le détecteur de chartes universel Mozilla et les composants internationaux pour Unicode.
Les programmeurs supposent à tort que la détection de UTF-8 est tout aussi difficile (ce n'est pas parce que la grande majorité des séquences d'octets est invalide UTF-8, alors que les codages que ces bibliothèques tentent de distinguer permettent toutes les séquences d'octets possibles). Par conséquent, tous les programmes compatibles Unicode ne réalisent pas une telle analyse et se basent plutôt sur la nomenclature.
En particulier, Microsoft compilateurs et interprètes, et de nombreux logiciels sous Microsoft Windows, tels que Notepad, ne liront pas correctement le texte UTF-8, à moins qu'il ne comporte que ASCII caractères ou qu'il commence par la nomenclature et ajoutera une nomenclature au début lors de l’enregistrement de texte au format UTF-8. Google Documents ajoute une nomenclature lorsqu'un document Microsoft Word est téléchargé en tant que fichier texte brut.
Sur lequel est le meilleur,AVECoSANSla nomenclature:
Le IETF recommande que si un protocole soit (a) utilise toujours UTF-8, soit (b) dispose d'un autre moyen d'indiquer quel codage est utilisé, alors il "DEVRAIT interdire l'utilisation de U + FEFF comme une signature. "
Ma conclusion:
Utilisez la nomenclature uniquement si la compatibilité avec une application logicielle est absolument essentielle.
Notez également que si l'article Wikipedia référencé indique que de nombreuses applications Microsoft utilisent la nomenclature pour détecter correctement UTF-8, il n'en va pas de même pour toutes les applications Microsoft. Par exemple, comme indiqué par @ barlop , lors de l'utilisation de l'invite de commande Windows avec UTF-8†, Les commandes telles que type et more ne s’attendent pas à ce que la nomenclature soit présente. Si la nomenclature est présente , cela peut être problématique, comme pour d'autres applications.
† La commande chcp offre une prise en charge de UTF-8 ( sans la nomenclature) via la page de codes 65001 .
Il convient de noter que pour certains fichiers, vous ne devez pas posséder la nomenclature, même sous Windows. Des exemples sont les fichiers SQL*plus ou VBScript. Si de tels fichiers contiennent une nomenclature, vous obtenez une erreur lorsque vous essayez de les exécuter.
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 se produire dans des contextes où les données UTF-8 sont converties à partir d'autres formes de codage utilisant une nomenclature ou dans lesquelles la nomenclature est utilisée comme signature UTF-8."
UTF-8 avec nomenclature n'est utile que si le fichier contient des caractères non-ASCII. S'il est inclus et qu'il n'y en a pas, il supprimera probablement les anciennes applications qui auraient autrement interprété le fichier en tant qu'ASCII simple. Ces applications échoueront certainement lorsqu'elles rencontreront un caractère non ASCII. Par conséquent, à mon avis, la nomenclature ne devrait être ajoutée que lorsque le fichier peut et ne doit plus être interprété comme de l'ASCII ordinaire.
Edit: Je veux juste préciser que je préfère ne pas avoir de nomenclature du tout, ajoutez-la au cas où de vieilles ordures se briseraient avec elle, et le remplacement de cette application héritée n'est pas réalisable.
Ne faites rien attendre à une nomenclature pour UTF8.
Cette question a déjà un million de réponses, et bon nombre d'entre elles sont assez bonnes, mais je voulais essayer de préciser quand une nomenclature devrait ou non être utilisée.
Comme mentionné précédemment, toute utilisation de la nomenclature UTF (marque d'ordre d'octet) pour déterminer si une chaîne est au format UTF-8 ou non constitue une conjecture éclairée. Si des métadonnées appropriées sont disponibles (comme charset="utf-8"), alors vous savez déjà ce que vous êtes censé utiliser, mais sinon, vous devrez tester et émettre certaines 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 qu'il s'agit de l'UTF-8 et que vous pouvez partir de là. Cependant, une fois de plus contraint de deviner, une vérification d'erreur supplémentaire lors de la lecture serait toujours une bonne idée au cas où quelque chose se brouillait. Vous ne devez supposer qu'une BOM n'est pas UTF-8 (c'est-à-dire latin-1 ou ANSI) si l'entrée ne devrait certainement pas l'être UTF-8 en fonction de sa source. S'il n'y a pas de nomenclature, vous pouvez simplement déterminer s'il est censé être UTF-8 en validant par rapport à l'encodage.
Pourquoi une nomenclature n'est-elle pas recommandée?
- Les logiciels non conformes à Unicode ou peu conformes peuvent présumer être de type latin-1 ou ANSI et ne vont pas effacer la nomenclature de la chaîne, ce qui peut évidemment causer des problèmes.
- Ce n'est pas vraiment nécessaire (vérifiez simplement si le contenu est conforme et utilisez toujours UTF-8 comme solution de secours quand aucun codage conforme ne peut être trouvé)
Quand devrait vous encodez avec une nomenclature?
Si vous ne pouvez pas enregistrer les métadonnées d'une autre manière (via une balise de jeu de caractères ou une méta de système de fichiers) et que les programmes utilisés ressemblent à des nomenclatures, vous devez encoder avec une nomenclature. Cela est particulièrement vrai sous Windows où tout ce qui ne contient pas de nomenclature est généralement supposé utiliser une page de code existante. La nomenclature indique aux programmes tels qu'Office que, oui, le texte de ce fichier est Unicode; voici l'encodage utilisé.
Au final, les seuls fichiers avec lesquels je rencontre vraiment des problèmes sont les fichiers CSV. Selon le programme, il doit ou non avoir une nomenclature. Par exemple, si vous utilisez Excel 2007+ sous Windows, celui-ci doit être codé avec une nomenclature si vous souhaitez l'ouvrir en douceur et ne pas avoir à importer d'importer les données.
Lorsque vous souhaitez afficher des informations codées en UTF-8, vous ne pouvez pas rencontrer de problèmes. Déclarez par exemple un document HTML au format UTF-8 et tout ce qui sera affiché dans votre navigateur, contenu dans le corps du document.
Mais ce n'est pas le cas lorsque nous avons du texte, CSV et des fichiers XML, sous Windows ou Linux.
Par exemple, un fichier texte sous Windows ou Linux, l’une des choses les plus faciles à imaginer, ce n’est pas (en général) le format UTF-8.
Enregistrez-le au format XML et déclarez-le au format 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é comme 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 dès le début (modification des options dans IDE et "Créer un nouveau fichier") ni 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.
UTF-8 sans nomenclature n'a pas de nomenclature, ce qui ne le rend pas meilleur que UTF-8 avec nomenclature, sauf si le consommateur du fichier a besoin de savoir (ou gagnerait à savoir) si le fichier est codé en UTF-8. ou pas.
La nomenclature est généralement utile pour déterminer la finalité du codage, ce qui n'est pas nécessaire dans la plupart des cas d'utilisation.
En outre, la nomenclature peut être source de bruit et de douleur inutiles pour les clients qui ne le connaissent pas ou qui s'en soucient et peut entraîner la confusion de l'utilisateur.
Je regarde cela sous un angle différent. Je pense que UTF-8 avec nomenclature est préférable car il fournit plus d'informations sur le fichier. J'utilise UTF-8 sans nomenclature uniquement si je rencontre des problèmes.
J'utilise plusieurs langues (même cyrillique ) sur mes pages pendant longtemps et lorsque les fichiers sont enregistrés sans nomenclature, je les rouvre pour les éditer avec un éditeur (comme cherouvim é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.
Personnellement, je sauvegarde des fichiers de script (.asp, .ini, .aspx) côté serveur avec des fichiers BOM et . Html. sans nomenclature .
Une différence pratique réside dans le fait que si vous écrivez un script Shell pour Mac OS X et le sauvegardez au format UTF-8, vous obtiendrez la réponse suivante:
#!/bin/bash: No such file or directory
en réponse à la ligne Shebang spécifiant le shell que vous souhaitez utiliser:
#!/bin/bash
Si vous enregistrez au format UTF-8, aucune nomenclature (par exemple, BBEdit ) tout ira bien.
La FAQ Unicode FAQ fournit une réponse concise:
Q: Comment dois-je traiter les nomenclatures?
A: Voici quelques directives à suivre:
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 des fichiers. Lorsque vous devez vous conformer à un tel protocole, utilisez une nomenclature.
Certains protocoles autorisent des nomenclatures optionnelles dans le cas de texte non balisé. Dans ces cas,
Lorsque l'on sait qu'un flux de données de texte est en texte brut mais que son codage est inconnu, la nomenclature peut être utilisée comme signature. S'il n'y a pas de nomenclature, l'encodage peut être n'importe quoi.
Lorsqu'un flux de données de texte est connu pour être du texte Unicode pur (mais pas quel endian), la nomenclature peut être utilisée comme signature. S'il n'y a pas de nomenclature, le texte doit être interprété en tant que big-endian.
Certains protocoles orientés octets attendent ASCII caractères au début d'un fichier. Si vous utilisez UTF-8 avec ces protocoles, évitez d'utiliser la nomenclature comme signature de formulaire de codage.
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é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.
Comme mentionné ci-dessus, UTF-8 avec nomenclature peut entraîner des problèmes avec les logiciels non compatibles avec la nomenclature (ou compatibles). Une fois, j'ai édité des fichiers HTML codés au format UTF-8 + BOM avec le programme KompoZer basé sur Mozilla, car un client avait besoin de ce programme WYSIWYG .
Invariablement, la mise en page serait détruite lors de la sauvegarde. Il m'a fallu du temps pour me débrouiller. Ces fichiers fonctionnaient alors bien dans Firefox, mais montraient à nouveau une bizarrerie CSS dans Internet Explorer, détruisant ainsi la présentation. Après avoir manipulé les fichiers CSS liés pendant des heures sans résultat, j'ai découvert qu'Internet Explorer n'aimait pas le fichier HTML BOMfed. Plus jamais.
En outre, je viens de trouver ceci dans Wikipedia:
Les caractères Shebang sont représentés par les mêmes deux octets dans les codages étendus ASCII, y compris UTF-8, qui est couramment utilisé pour les scripts et autres fichiers texte sur les systèmes de type Unix actuels. Toutefois, les fichiers UTF-8 peuvent commencer par la marque optionnelle d’octets (BOM); si la fonction "exec" détecte spécifiquement les octets 0x23 0x21, alors la présence de la nomenclature (0xEF 0xBB 0xBF) avant Shebang empêchera l'exécution de l'interpréteur de script. Certaines autorités recommandent de ne pas utiliser la marque d'ordre des octets dans les scripts POSIX (de type Unix) [15], pour cette raison et pour des raisons d'interopérabilité et philosophiques plus larges.
De http://en.wikipedia.org/wiki/Byte-order_mark :
La marque d'ordre d'octet (BOM) est un caractère Unicode utilisé pour signaler la finalité (ordre d'octet) d'un fichier texte ou d'un flux. Son 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 en tant qu'indicateur d'ordre d'octet, le caractère de nomenclature peut également indiquer laquelle des nombreuses représentations Unicode dans lesquelles le texte est codé.
Toujours utiliser une nomenclature dans votre fichier garantira qu'il s'ouvre toujours correctement dans un éditeur prenant en charge les formats UTF-8 et BOM.
Mon vrai problème avec l'absence de nomenclature est le suivant. Supposons que nous ayons un fichier qui contient:
abc
Sans nomenclature, cela s'ouvre en tant qu'ANSI dans la plupart des éditeurs. Donc, un autre utilisateur de ce fichier l'ouvre et ajoute des caractères natifs, 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 et cela cause d'autres problèmes plus tard dans la chaîne de développement.
Voici mon expérience des demandes d'extraction Visual Studio, SourceTree et Bitbucket, ce qui m'a posé quelques problèmes:
Ainsi, la nomenclature avec signature inclura un caractère point rouge sur chaque fichier lors de l'examen d'une demande d'extraction (peut être assez gênant).
Si vous survolez dessus, il affichera un caractère comme "ufeff", mais finalement, sourcetree n'indique pas ce type de marques de sous-marques. Il se retrouvera donc probablement dans vos demandes d'extraction, ce qui devrait être correct, car c'est ainsi que VS 2017 encode. nouveaux fichiers maintenant, alors peut-être que bitbucket devrait l'ignorer ou le faire apparaître d'une autre manière, plus d'infos ici: