Le Tue 3/08/2004, Laurent Giroud disait
> > > On pourrait alors dire que l'ISO8859-15 casse les logiciels qui ne
> > > g�rent que l'ASCII 7 bits am�ricain :)
> >
> > Non, car si on n'utilise que des caract�res ascii en travaillant en
> > iso-8859-15 �a passe.
>
> L'ascii est un sous ensemble (cod� sur 7 bits) de l'iso-8859-15 donc
> un logiciel qui g�re des caract�res 8 bits va "g�rer" le 8859 sans
> s'en rendre compte. En revanche, un logiciel qui g�re du 7 bits (un
> logiciel de mail mal configur� par exemple) ne g�rera pas
> correctement les textes en 8859-15.
>
> > Si on n'uytilise que des caract�res iso-8859-15 en UTF-8 �a foire...
>
> Ca c'est bizarre. L'UTF-8 est calqu� quasiment identiquement sur
> l'iso-8859-15 pour les 8 premiers bits. (cf
> http://orwell.ru/test/ISO/_?15 )
UCS, pas UTF-8 qui va prendre 2 octets pour coder le caract�re 0xE9 ('�')
> Je penche plut�t pour une locale mal r�gl�e dans ce cas.
>
> > > La faiblesse est plut�t du c�t� des logiciels qui ne g�rent pas
> > > correctement l'unicode, en effet, si on utilise la libc GNU
> > > standard et qu'on utilise gettext pour la localisation, il
> > > suffit d'utiliser wprintf au lieu de printf, de ne plus utiliser
> > > les "char" (en C) mais les "wchar" et de veiller � ne pas tester
> > > les cha�nes de caract�res "en dur" mais d'utiliser
> > > syst�matiquement des cha�nes localis�es.
> >
> > arrfff... il "suffit"...
>
> Ce n'est pas l'utilisation d'un "il suffit" qui permet de dire que
> c'est irr�aliste, c'est l'ampleur de la t�che que �a repr�sente.
>
> Faire un chercher/remplacer char/wchar_t, printf/wprintf,
> strcpy/wstrcpy, etc. constitue d�j� l'essentiel du travail de
> conversion et se fait de fa�on tout � fait automatique. Ensuite, si
> le texte est d�j� localis� avec gettext (ou similaire), il n'y a
> plus rien � faire. Si il ne l'est pas, de toute mani�re ce logiciel
> est inutilisable dans toute autre langue que l'anglais et il est
> probablement d�j� obsol�te ou de diffusion locale uniquement et n'a
> pas besoin d'�tre converti si l'utilisateur ne manipule que de
> l'ascii ou de l'iso8859-15 puisque ils sont quasiment identiques bit
> � bit avec les caract�res utf-8 cod�s sur un octet.
Sauf que char en C sers � bien d'autre choses que repr�senter des
caract�res, ton remplacement syst�matique va juste foutre en l'air
le soft...
> C'est r�ellement quelque chose de simple � mener. Cf
> ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO-6.html#ss6.1
>
> > EN attendant zsh ne supporte pas et debbaibn a bidouill� un slnag
> > suppl�mentaire en utf-8...
>
> Ca signifie avant tout que personne ne l'a fait, pas que c'est
> difficile ;)
C'etspas ce que disentles d�veloppeurs de zsh...
> Vu la faible conscience de l'int�r�t de l'unicode, il est normal que
> tous les auteurs de logiciels libres n'aient pas encore franchi le
> pas. Je ne leur jette pas la pierre : si l'info ne leur est pas
> parvenue, ils ne vont pas le deviner tous seuls tant qu'ils n'ont
> pas besoin de manipuler d'autres langues.
�a implique parfois de revoir compl�tement certaines parties
du logiciels, qui par exemple font l'hypoth�se que les caract�res sont
de taille fixe...
--
Erwan
