Re: bash et UTF-8
> > > 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 ('é')
Exact, j'ai vérifié là http://www.wordiq.com/definition/UTF-8 et j'ai bien dit une connerie.
l'ASCII est un sous ensemble de l'UTF-8, mais ce n'est pas le cas de l'ISO-8859-15.
On a donc une situation similaire à celle qui existait lors du passage de l'ascii 7 bits à l'iso 8 bits.
Les logiciels qui limitent la taille d'un caractère à ce qu'ils en connaissent lors de leur conception sont restreints à un encodage donné.
Ca reste bien leur faute, pas celle de l'unicode, on n'allait pas rester en 8.3 sous prétexte que les logiciels DOS ne gèraient que ça :)
> 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...
Pour certains logiciels oui. Pour beaucoup d'autres qui utilisent un type du style u8 ou byte, ça ne posera pas de problème.
Mais c'est effectivement clairement quelque chose à ne pas oublier.
> > 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...
Tout à fait, comme ça impliquait de revoir les parties qui supposaient que les caractères étaient nécessairement sur 7 bits et servaient du 8ème bit pour rajouter des données lors du passage ASCII -> encodages ISO.
Idem pour les logiciels qui supposaient qu'un nom de fichier était nécessairement sur 8+3 octets, que l'année d'une date était nécessairement codée de 0 à 99, etc.
Tous les logiciels qui se brident lors de la conception à un format de donnée figé sont nécessairement à corriger ensuite.
Néanmoins, si ils sont bien conçus, ils ont veillé à gérer les char "caractères" et les char "octets" de façon différente. Quand je veux manipuler des octets non signés, je crée un type u8. Quand je veux juste "un entier signé" j'utilise "int" sans me poser de questions, etc.
Si ils ne l'ont pas fait, ma foi, certes ça sera plus compliqué, mais après tout, c'est un problème de conception, tant pis pour eux.
Ils passeront moins vite à l'unicode et seront donc plus susceptibles d'être abandonnés au profit de logiciels mieux conçus dont la conversion aura été plus simple.
Le darwinisme agit aussi à l'échelle des logiciels ;)
Laurent
PS: un avantage de l'utilisation des w_char est que lorsque l'unicode sera rendu obsolète par le contact avec des extra-terrestres avec des alphabets de plusieurs milliards de signes, il suffira d'étendre le type w_char pour gérer un nombre plus grand de symboles que l'unicode, d'adapter la libc et gettext, puis de recompiler sans avoir à toucher au code des logiciels ;)
Reply to: