Discussion :

[corrector]

En fait, plus j'y pense, plus je penche du côté de corrector pour ce point...

A un moment, mon argument logique repose sur le fait que "la donnée D est au format F" permet d'interpréter D (d'écrire un programme qui décode D). A partir de là, on prouve la disjonction mentionnée ci-dessus, l'absence de BOM en UTF-8, le caractère non-optionnel du BOM dans tous les cas.

Peut-être que tout le désaccord et les difficultés de communication viennent de là.

(Je peux aussi justifier certaines choses sur la base de la norme, mais ça m'intéresse moins.)

[Médinoc]

Je suis d'accord sur le fait que quand on sait hors-bande qu'un texte est en UTF-8, il n'y a pas de BOM.
Mais dans un texte dont on ignore le type, une "BOM UTF-8" peut signaler en-bande que la suite du texte est en UTF-8...

Edit au sujet du message #23: En effet, ce message saisit parfaitement ma pensée.

[corrector]

Je suis d'accord sur le fait que quand on sait hors-bande qu'un texte est en UTF-8, il n'y a pas de BOM.
Mais dans un texte dont on ignore le type, une "BOM UTF-8" peut signaler en-bande que la suite du texte est en UTF-8...

Je résume (tu m'arrêtes si je comprends de travers ce que tu voulais dire) : tu as un fichier, c'est de l'UTF-8, ça peut être indiqué à des programmes "hors-bande", mais certains programmes ne savent pas que c'est de l'UTF-8 (ils n'ont pas de canal hors-bande adéquat), donc on met une BOM comme "magic-number" pour identifier le format ("en-bande").

Donc ces derniers programmes voient une "BOM UTF-8", passent en mode UTF-8, et continuent à lire.

Les autres, qui ont déjà l'information hors-bande, commencent à lire en UTF-8 depuis le début du fichier (puisque la BOM n'est pas obligatoire en UTF-8), décodent les séquences à commencer par celle qui code la BOM, qui est alors considérée comme de l'UTF-8, pas annonçant de l'UTF-8, donc il décode un ZWNBSP, puis le reste du fichier comme précédemment. Tandis que les autres programmes, qui ne savaient pas que c'était de l'UTF-8 n'ont décodé que le reste du fichier. Il y a un caractère (ou code-point) en trop.

Mais ce n'est pas juste un artéfact comme les diacritiques combinant vs. les formes pré-combinées : on peut normaliser, qu'on passe en NFC, NFD, NFKC, NFKD, le ZWNBSP sera toujours là et heureusement parce qu'il a une sémantique, il ne fait pas juste de la figuration, ni du remplissage (sauf quand c'est une BOM, mais un ZWNBSP n'est jamais une BOM puisque l'un est un code-point, l'autre n'est... rien du tout, c'est comme les torchons et les serviettes, faut pas mélanger).

[corrector]

If U+FEFF had only the semantics of a signature code point,

On sent une note de regret...

it could be freely deleted from text without affecting the interpretation of the rest of the text. Carelessly appending files together, for example, can result in a signature code point in the middle of text.

En bref, ça risque d'être le bordel.

Unfortunately, U+FEFF also has significance as a character. As a zero width no-break space, it indicates that line breaks are not allowed between the adjoining characters. Thus U+FEFF affects the interpretation of text and cannot be freely deleted. The overloading of semantics for this code point has caused problems for programs and protocols.

Ils sont honnêtes au moins.

The new character U+2060 word joiner has the same semantics in all cases as U+FEFF, except that it cannot be used as a signature.

Maintenant, ils essaient de réparer leur erreur.

Implementers are strongly encouraged to use word joiner in those circumstances whenever word joining semantics are intended.

Ben oui, mais on ne peut pas remonter le temps.

En fait, je suis d'accord sur le fond avec eux.