[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian et l'oe (variation sur le thème de l'euro)



On Fri, Feb 15, 2002 at 11:37:47AM +0100, Nicolas Le Novere wrote:
> N'utiliseriez-vous pas l'encodage de caractères is8859-1 par hasard? Il
> ne contient pas OE, oe et Y tréma. C'est un des exemple les plus fameux 
> de ratage francophone (il contient pas contre Ù, qui est une lettre qui 
> n'existe pas à ma connaisance).

C'est un accent qui sert sans doute dans une autre langue. Et aussi pour
l'entrée en majuscules de phrases (je suppose).

> Il faut utiliser iso8859-15 (qui fourni en plus le caractère euro).

Oui, et non.

Il utilise effectivement l'encodage iso8859-1, mais il l'affiche en
iso8859-15. Je ne sais pas à quel point potato supporte bien qu'on la
mette en encodage natif -15, mais on peut faire illusion longtemps (sauf
pour 2-3 trucs, comme le courrier avec mutt, et encore).

Pour woody, ce qu'il faut, c'est changer les codes envoyés par le
clavier. Vous ne le savez peut-être pas, mais on peut dire à X11
d'envoyer des codes pour un caractère de n'importe quel jeu de caractère
(par exemple, avec suffisamment de touches, je pourrais envoyer les
caractères grecs et latins depuis mon clavier). Ce qui compte après,
c'est de savoir si les applications sont capables de les recevoir, et
comment elle les interprètent. Et ensuite, comment elle les affichent.

Jusqu'à récemment, la plupart des terminaux ne vérifiaient pas la
cohérence entre l'entrée (interprétation) et sortie (affichage). Un
caractère était interprété (selon la locale) comme étant un certain
numéro (disons 223 pour un ß, et 189 pour le 1/2). Ensuite, une autre
partie se chargeait de l'affichait (et si la police de sortie avait été
du cyrillique, le ß serait devenu un LATIN SMALL LETTER SHARP S, c'est à
dire un s accent aigu, et le 1/2 serait affiché comme un double accent
aigu.) Si la police de sortie, au lieu d'être latin-1, est latin-9, le ß
s'affiche bien ß car c'est le même caractère dans les deux cas, et le
1/2 s'affiche oe (œ).

Bien. Bien. Après tout, tout le monde s'en fout, sauf que si on veut
taper un oe, il faut dire au clavier d'envoyer le code 1/2.

Depuis la dernière libc et vague d'internationalisation, pour préparer
le support d'Unicode entre autre, il est devenu nécessaire de faire la
différence. Après tout, on pourrait vouloir taper dans un même texte un
1/2 et un oe. Ou un €uro et un currency (symbole rond avec quatre
petites pattes) dans le même fichier.

Pour cela, il y maintenant (woody) interprétation stricte: si on tape
un symbole 1/2, le terminal sait que c'est un 1/2, et donc si on lui dit
que l'affichage se fait iso-8859-15, il affiche un ?, car il sait qu'il
ne peut pas afficher le 1/2 (iconv() s'occupe de ça). Donc, si on veut
taper un oe (œ), il faut vraiment que l'on rentre un oe et qu'on affiche
un oe. D'où le réglage de l'ENTRÉE et de la SORTIE nécessaire.

On peut toutefois quand même voir un oe même si on est avec une entrée
1/2: il suffit de le sauvegarder. Comme l'encodage n'est pas sauvegardé
dans les fichiers, 99,9% des programmes supposent que le fichier est
dans l'encodage (de sortie) courant. Et donc affichent joyeusement des
é à la place de « é » quand le document est en fait en Unicode.

Un jour viendra, où les fichiers se souviendront de leur encodage. Non,
il ne viendra pas, mais tant pis...

On peut donc aussi voir un oe et un euro même sans être passé à l'Euro.
Il suffit pour cela de dire qu'on tape en Latin-1, sans sourciller, et
de se contenter de faire afficher en Latin-9. Les 1/2 deviennent oe, les
cédilles deviennent Z-caron, les currency deviennent euros.

Moralité: sur potato, si j'ai bien compris, on peut encore se contenter
d'une illusion d'euro. Sur woody, beaucoup d'applications sont devenues
plus formelles dans leur façon de faire, et il faut vraiment avoir des
vrais euros (et des vrais oe). On ne le dirait pas, mais c'est un
progrès.

-- 
Jean-Christophe Dubacq -- ATER en informatique à la faculté d'Orsay.
Tel: 01 69 15 76 43 / 06 64 86 10 56 --- Email: jcdubacq@lri.fr



Reply to: