Re: Latin n½uf

En news:487e55f8$0$30969$426a74cc@news.free.fr, Nicolas Dejoie va escriure:
> Patrick Lamaizière a écrit :
>> Éric Marillier :
>>> Merci du renseignement. Ça pourrait valoir le coup d'activer
>>> l'UTF-8 pour ce genre de cas ?
>>
>> Je dirais que c'est plus politiquement correct que le windows-1252.
>> L'UTF-8 est autorisé et ce genre de cas est assez rare.
>
> En même temps, un lecteur qui sait lire de l'UTF-8 est probablement
> full-Unicode

Pas sûr : il est aussi possible que l'on ait greffé une verrue «
décodage-utf8 » à un programme purement 8bits.
C'est même de très loin le plus courant, en fait.

> et ça saura aussi lire du 1252 bien déclaré.

Je ne vois pas pourquoi.
Je passe sur le cas Plan9 ou assimilés, où le programme est né purement
UTF-8 et donc n'a aucune raison d'être compatible avec le passé obsolète et
tordu (contrairement à iso-8859-1).
Si le programme vient du monde (E)BCDIC, ou du monde *nix tendance 8859-x,
ou du monde IBMPC et ses pages 85x, ou du monde Mac, il peut parfaitement
évoluer vers le haut et devenir full-Unicode ; cela ne l'oblige pas à devoir
gérer _en plus_ un encodage _devenant obsolète_ qui n'est compatible avec
personne (1252 au départ dans Win3.0 est une extension de 8859-1 uniquement
pour rajouter les guillemets courbés; et la version Win3.1 n'a pas réussi à
intégrer tous les caractères du jeu TrueType d'Apple), diffusé par quelqu'un
qui de son côté snobe consciencieusement les autres.

Par ailleurs, il y a largement plus de contenu en 1252 mal déclaré (parce
qu'avant de snober consciencieusement, le «quelqu'un» a commencé par essayer
de tordre le cou du standard pour imposer une version maison d'une norme
internationale _sans_ en changer la référence) que de bien déclaré ; donc si
tu te casses le *** à implémenter une couche complémentaire de compatibilité
windows-1252, dans la pratique tu es obligé de rajouter une logique qui «
surclassse » en windows-1252 tout le contenu marqué iso-8859-1 contenant des
caractères codés entre 128 et 159 (et t'es bien em****é quand tu trouves du
8859-15 avec des caractères 128).

Pour finir, la cerise c'est que la définition de 1252 n'est pas figée ; même
si aujourd'hui il semble que les éventuels projets soient mis sous le
boisseau, on a connu au moins 4 versions de cet encodage (en mettant de côté
les autres variations 125x, sachant que tout cela s'appelle «Ansi» dans les
spécifications, sans différencier outre mesure) :
- la version de Win3.0 (toujours présente dans les polices VGAx.FON de votre
système de marque Microsoft, vous-savez-bien, la police System qui ne sait
pas représenter le ½...)
- la version de Win3.1
- la version avec euro (en 128) _et_ ´/¸ (en 142/158)
- la version avec euro mais _sans_ les ´/¸ des Estoniens
Ceci sans compter les différences d'interprétations qui ont amenés certains
à classer les deux caractères petit-^ et petit-~ comme étant les versions
« combinantes » (U+030x), alors qu'en fait il s'agit de versions avec chasse
(U+02Cx)



> Et les lecteurs qui ne savent pas s'en sortiront mieux avec
> du 1252 qu'avec de l'UTF-8, non ?

Tu supposes erronément qu'un lecteur sur {longue liste de machines incluant
tout-le-monde sauf Windows} aura plus de facilité avec 1252 qu'avec UTF-8.

Pour te montrer en quoi c'est délirant, c'est la même position que ceux qui
vers 1975 demandait à ce que l'on se défausse vers EBCDIC lorsque l'on ne
savait pas manipuler de l'ASCII, ou encore ceux qui vers 1992 demandait à ce
l'on se défausse vers iso-2022 ou Roman-8 (HP) lorsque l'on ne savait pas
interpréter iso-8859-1.


Antoine