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 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: References: <0kBuqSbAxmlqmwDZO30oD0QcWok@jntp> 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: 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