Distinguer UTF-8 d'un autre encodage (was: Mauvais encodage)

Le 17/11/2024 12:28, j'écrivais :

 
Alors qu'il est possible de lire de l'UTF-8 et de l'interpréter comme si c'était
du Latin1 (plus probablement du Windows Latin1 à cause des caractères dans la
plage 80-9F), le contraire est impossible. Le moindre é écrit E9 est impossible
en UTF-8, ce qui indique que le charset, si non indiqué ou inconnu, ne peut pas
être UTF-8. Il est alors tout à fait normal que le navigateur se rabatte sur
un charset mono-octet, par exemple MacRoman sur Mac ou Latin1 partout.

Voici un exemple pour illustrer ce que je dis.


Supposons qu'une page HTML envoie les octets « 63 6F 64 C3 A9 ».

− Si l'encodage annoncé est UTF-8, le navigateur affichera « codé ».
− Si l'encodage annoncé est ISO-8859-1, ou ISO-8859-15, ou windows-1252,
le navigateur affichera « codé ».
− Mais si l'encodage annoncé est inconnu et que le navigateur doit deviner,
sachant que les deux interprétations sont valides il y a au moins deux
stratégies possibles : la stratégie prudente qui consiste à choisir
windows-1252 parce que c'est l'encodage qui a le moins de chances de
tomber sur un caractère inexistant ; la stratégie intelligente selon
laquelle si ça *peut* être de l'UTF-8 alors il y a statistiquement peu
de chances que ce soit autre chose.


Supposons maintenant qu'une page HTML envoie les octets « 63 6F 64 E9 ».

− Si l'encodage annoncé est ISO-8859-1, ou ISO-8859-15, ou windows-1252,
le navigateur affichera « codé ».
− Si l'encodage annoncé est UTF-8, le navigateur devrait afficher « cod� »
parce que, bien que le code E9 soit invalide en UTF-8, on lui a demandé
explicitement de le lire comme si c'était de l'UTF-8 ; ce n'est pas possible
alors il affiche le caractère de remplacement.
− Enfin, si l'encodage annoncé est inconnu, et même si on a configuré le
navigateur pour qu'il privilégie UTF-8 comme charset par défaut, il sait
que ça ne *peut* pas être de l'UTF-8 alors un choix raisonnable doit être
windows-1252, non pas parce que si c'est incorrect c'est forcément dû à
Windows, mais parce que cela englobe ISO-8859-1 qui est le standard favori
des charsets mono-octet.


--
Olivier Miakinen