Aller au contenu principal

6. Byte order mark (BOM) (Marque d'ordre d'octets)

Définition​

Le caractère UCS U+FEFF « ZERO WIDTH NO-BREAK SPACE » est également connu informellement sous le nom de « BYTE ORDER MARK » (abrégé « BOM »). Ce caractère peut être utilisé comme un véritable « ZERO WIDTH NO-BREAK SPACE » dans le texte, mais le nom BOM suggère une deuxième utilisation possible du caractère : préfixer un caractère U+FEFF à un flux de caractères UCS comme une « signature ».

Utilisation comme signature​

Un récepteur d'un tel flux sérialisé peut alors utiliser le caractère initial comme une indication que :

  • Le flux consiste en caractères UCS
  • Pour reconnaître quel codage UCS est impliqué
  • Avec les codages ayant une unité de codage multi-octets, comme un moyen de reconnaître l'ordre de sérialisation des octets

UTF-8 et BOM​

UTF-8 ayant une unité de codage à un seul octet, cette dernière fonction est inutile et le BOM apparaîtra toujours comme la séquence d'octets EF BB BF.

Règles d'interprétation​

La position compte​

Il est important de comprendre que le caractère U+FEFF apparaissant à toute position autre que le début d'un flux doit (MUST) être interprété avec la sémantique de l'espace sans saut de largeur nulle, et ne doit pas (MUST NOT) être interprété comme une signature.

Considérations sur la suppression​

Lorsqu'il est interprété comme une signature, la norme Unicode suggère qu'un caractère U+FEFF initial peut être supprimé avant le traitement du texte. Une telle suppression est nécessaire dans certains cas (par exemple, lors de la concaténation de deux chaînes, car sinon la chaîne résultante peut contenir un « ZERO WIDTH NO-BREAK SPACE » non intentionnel au point de connexion), mais pourrait affecter un processus externe à une couche différente (comme une signature numérique ou un décompte des caractères) qui s'appuie sur la présence de tous les caractères dans le flux.

Recommandation​

Il est donc recommandé (RECOMMENDED) de :

  • Éviter de supprimer un U+FEFF initial interprété comme une signature sans bonne raison
  • L'ignorer plutôt que de le supprimer lorsque c'est approprié (comme pour l'affichage)
  • Le supprimer uniquement lorsque c'est vraiment nécessaire

Problèmes d'ambiguïté​

U+FEFF dans la première position d'un flux peut (MAY) être interprété comme un espace sans saut de largeur nulle, et n'est pas toujours une signature.

Ajout Unicode 3.2​

Dans une tentative de diminuer cette incertitude, Unicode 3.2 ajoute un nouveau caractère, U+2060 « WORD JOINER », avec exactement la même sémantique et utilisation que U+FEFF sauf pour la fonction de signature, et recommande fortement son utilisation exclusive pour exprimer la sémantique de jonction de mots.

Clarté future​

Finalement, suivre cette recommandation rendra presque certain que tout U+FEFF initial est une signature, et non un « ZERO WIDTH NO-BREAK SPACE » intentionnel.

Directives pour les protocoles​

En attendant, l'incertitude reste malheureusement et peut affecter les protocoles Internet. Les spécifications de protocole peuvent (MAY) restreindre l'utilisation de U+FEFF comme signature afin de réduire ou d'éliminer les effets négatifs potentiels de cette incertitude.

Dans l'intérêt d'un équilibre entre les avantages (réduction de l'incertitude) et les inconvénients (perte de la fonction de signature) de telles restrictions, il est utile de distinguer quelques cas :

Cas 1 : UTF-8 obligatoire​

Un protocole devrait (SHOULD) interdire l'utilisation de U+FEFF comme signature pour les éléments de protocole textuels que le protocole impose d'être toujours en UTF-8, la fonction de signature étant totalement inutile dans ces cas.

Cas 2 : Mécanismes d'identification fiables​

Un protocole devrait (SHOULD) également interdire l'utilisation de U+FEFF comme signature pour les éléments de protocole textuels pour lesquels le protocole fournit des mécanismes d'identification de codage de caractères, lorsqu'on s'attend à ce que les implémentations du protocole soient en mesure d'utiliser toujours correctement les mécanismes.

Cela sera le cas lorsque les éléments de protocole sont maintenus étroitement sous le contrôle de l'implémentation depuis le moment de leur création jusqu'au moment de leur transmission (correctement étiquetée).

Cas 3 : Pas de mécanismes d'identification​

Un protocole ne devrait pas (SHOULD NOT) interdire l'utilisation de U+FEFF comme signature pour les éléments de protocole textuels pour lesquels le protocole ne fournit pas de mécanismes d'identification de codage de caractères, lorsque :

  • Une interdiction serait inapplicable, ou
  • On s'attend à ce que les implémentations du protocole ne soient pas en mesure d'utiliser toujours correctement les mécanismes

Ces deux derniers cas sont susceptibles de se produire avec des éléments de protocole plus grands tels que les entités MIME, en particulier lorsque les implémentations du protocole obtiendront de telles entités à partir de :

  • Systèmes de fichiers
  • Protocoles qui n'ont pas de mécanismes d'identification de codage pour les charges utiles (comme FTP)
  • Autres protocoles qui ne garantissent pas l'identification correcte du codage de caractères (comme HTTP)

Conseils d'implémentation​

Lorsque interdit​

Lorsqu'un protocole interdit l'utilisation de U+FEFF comme signature pour un certain élément de protocole, alors tout U+FEFF initial dans cet élément de protocole doit (MUST) être interprété comme un « ZERO WIDTH NO-BREAK SPACE ».

Lorsque non interdit​

Lorsqu'un protocole n'interdit pas l'utilisation de U+FEFF comme signature pour un certain élément de protocole, alors les implémentations devraient (SHOULD) être préparées à :

  • Gérer une signature dans cet élément
  • Réagir de manière appropriée : utiliser la signature pour identifier le codage de caractères si nécessaire
  • Supprimer ou ignorer la signature de manière appropriée

Liens connexes​

Dernière mise à jour le