Re: bash et UTF-8

[Laurent Giroud]
> Ca c'est bizarre.
> L'UTF-8 est calqu=E9 quasiment identiquement sur
> l'iso-8859-15 pour les 8 premiers bits.

Tu confonds la table des caract=E8res et le codage utilis=E9.

> > > La faiblesse est plut=F4t du c=F4t=E9 des logiciels qui
> > > ne g=E8rent 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 =E0 ne
> > > pas tester les cha=EEnes de caract=E8res "en dur" mais
> > > d'utiliser syst=E9matiquement des cha=EEnes localis=E9es.
> >
> > arrfff... il "suffit"...
>
> Ce n'est pas l'utilisation d'un "il suffit" qui permet
> de dire que c'est irr=E9aliste, c'est l'ampleur de la
> t=E2che que =E7a repr=E9sente.

C'est bien beau de se documenter, encore faut-il passer =E0
la pratique ;)

Si tout ce qui t'int=E9resse est de fournir un bon support
pour l'UTF-8, la solution la plus simple est de conserver
des char et de changer les routines de calcul de
longueur de cha=EEnes, recherche d'expressions, etc. C'est
ce que fait la majorit=E9 des programmeurs, avec
=E9ventuellement conversion du codage si l'utilisateur
n'est pas en UTF-8.

Ce que tu d=E9cris avec wchar est autre chose, mais les
ayatollahs de l'UTF-8 sont contre car =E7a permet aux
codages existants (8-bit ou multibyte) de continuer =E0
=EAtre support=E9s, alors qu'il faudrait les =E9radiquer.

Les 2 approches requi=E8rent beaucoup plus de travail que
tu ne sembles l'imaginer.

--
Denis=0A=0AAcc=E9dez au courrier =E9lectronique de La Poste : www.laposte=
.net ; =0A3615 LAPOSTENET (0,34=80/mn) ; t=E9l : 08 92 68 13 50 (0,34=80/=
mn)=0A=0A