Re: bash et UTF-8
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
Reply to: