[Laurent Giroud] > Ca c'est bizarre. > L'UTF-8 est calqu� quasiment identiquement sur > l'iso-8859-15 pour les 8 premiers bits.
Tu confonds la table des caract�res et le codage utilis�. > > > 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. C'est bien beau de se documenter, encore faut-il passer � la pratique ;) Si tout ce qui t'int�resse 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�nes, recherche d'expressions, etc. C'est ce que fait la majorit� des programmeurs, avec �ventuellement conversion du codage si l'utilisateur n'est pas en UTF-8. Ce que tu d�cris avec wchar est autre chose, mais les ayatollahs de l'UTF-8 sont contre car �a permet aux codages existants (8-bit ou multibyte) de continuer � �tre support�s, alors qu'il faudrait les �radiquer. Les 2 approches requi�rent beaucoup plus de travail que tu ne sembles l'imaginer. -- Denis Acc�dez au courrier �lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34�/mn) ; t�l : 08 92 68 13 50 (0,34�/mn)
