Path: ...!news.roellig-ltd.de!open-news-network.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!.POSTED!not-for-mail
From: Olivier Miakinen <om+news@miakinen.net>
Newsgroups: fr.comp.infosystemes
Subject: Distinguer UTF-8 d'un autre encodage (was: Mauvais encodage)
Date: Sun, 17 Nov 2024 12:57:08 +0100
Organization: There's no cabale
Lines: 44
Message-ID: <vhclmk$2jf9$1@cabale.usenet-fr.net>
References: <0kBuqSbAxmlqmwDZO30oD0QcWok@jntp> <vg2hnb$3888u$1@dont-email.me>
 <vg2j0t$38evc$1@dont-email.me> <ntlWEBYnVt0ftbQiWgp5kmVJjMA@jntp>
 <lopmrrF6b21U1@mid.individual.net> <TtNIVb-xyl19P1uhiWzduR6NEY4@jntp>
 <vh544g$2s7ba$1@dont-email.me> <dZNKgxNd80Qv1gVBFDC9KoHURpw@jntp>
 <vh57hq$2skdk$2@dont-email.me>
 <AABnN0JWQPQAAB+N.A3.flnews@yamo.pasdenom.info>
 <vh7v49$ehf$1@rasp.pasdenom.info> <vh8dlh$jif$4@rasp.pasdenom.info>
 <vha324$1i6r$1@cabale.usenet-fr.net> <vha3vt$jif$9@rasp.pasdenom.info>
 <vha5uu$1j36$1@cabale.usenet-fr.net> <vhcfdg$dtt$4@rasp.pasdenom.info>
 <vhck0e$2j24$1@cabale.usenet-fr.net>
NNTP-Posting-Host: 200.89.28.93.rev.sfr.net
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: cabale.usenet-fr.net 1731844628 85481 93.28.89.200 (17 Nov 2024 11:57:08 GMT)
X-Complaints-To: abuse@usenet-fr.net
NNTP-Posting-Date: Sun, 17 Nov 2024 11:57:08 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Firefox/52.0 SeaMonkey/2.49.4
In-Reply-To: <vhck0e$2j24$1@cabale.usenet-fr.net>
Bytes: 3835

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