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

Re: bash et UTF-8



> > 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 )

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.

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 ;)

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.

> Si c'était si simple tu crois pas que pluytôt qu'avoir 2 slang dans
> debian il y en aurait un seul qui fait tout ?

Bonne remarque.
Le fait que ce soit simple au niveau d'un programme ne signifie pas que ça le soit au niveau d'une distribution.

On ne peut pas forcer l'usage d'unicode quand des programmes répandus (window managers, terminaux x, shells) ne le gèrent pas encore. Donc on doit donc avoir des versions distinctes dans la distribution pour :
- ceux qui ont besoin de passer en unicode parce qu'ils communiquent en plusieurs langages et qui sont prèts à se passer de ses logiciels pour d'autres moins connus ou réputés mais qui gèrent l'unicode
et pour
- ceux qui n'ont pas un besoin impératif de l'unicode et sont attachés à leurs logiciels "classiques".

En attendant que les logiciels les plus répandus fonctionnent parfaitement en unicode, on doit effectivement avoir deux systèmes en parallèle.

Laurent



Reply to: