fr.comp.normes.unicode
[Top] [All Lists]

Re: HS -utf 8

Subject: Re: HS -utf 8
From: "Antoine Leca"
Date: Thu, 21 Feb 2008 12:24:39 +0100
Newsgroups: fr.comp.normes.unicode
En news:[email protected], Xavier Roche va escriure:
> Antoine Leca a Ãcrit :
>> DÃbut 1998 ? Vous voulez rire, n'est-ce pas ? Ã l'Ãpoque, la
>> question, c'Ãtait combien de systÃmes d'exploitation reconnaissait
>> UTF-8 en dehors des applications spÃcialement faites pour cela.
>
> Windows le faisait (MBCS et l'API "wide", Ãa date de cette Ãpoque),

Windows NT4 maniait trÃs mal UTF-8 en tant que MultiByte charset... il a
fallu attendre NT5, mais cela date de 1999 !

Quant à Windows NT et Unicode, cela date de 1992, mais c'est diffÃrent de ce
dont on parle ici : l'idÃe Ãtait alors de n'utiliser qu'une seule forme
(celle que l'on appelle aujourd'hui UCS-2) et de ne plus avoir *aucun* souci
; mais cela ne marche pas dans la pratique : certains idÃogrammes chinois
n'ont pas la mÃme forme que leur Ãquivalent japonais, il faut environ 18
bits pour un encodage rÃellement universel donc avec 16 bits cela n'est pas
suffisant, on devient sensible à l'ordre des octets dans un mot machine, les
octets à zÃro sont impossible à gÃrer par les outils classiques en langage C
ce qui rend la solution Unicode originale impossible à appliquer aux
systÃmes genre Posix qui existaient et oblige à redÃvelopper un systÃme
complÃtement (NT a mis 8 ans pour s'imposer, alors que Windows n'en avait
mis que 5), etc.


> et Linux aussi (bon, d'accord, personne ne rÃglait alors la locale
> sur UTF-8 :p)

Et mieux valait ne pas le faire. Par exemple, j'ai souvenir de discussions
plusieurs annÃes aprÃs, quand RedHat et consorts ont changà la locale par
dÃfaut pour une locale .utf8, et que cela a cassà tout plein de scripts,
entre autres parce que l'ordre des fichiers est devenu insensible à la
casse...


> AprÃs, les applications avaient parfois un peu plus de mal à Ãtre
> aussi compatibles, mais bon.. on va dire cinq ans :p

Cinq ans d'accord. D'ailleurs, il est dÃjà remarquable d'avoir une
acceptation aussi importante au bout de seulement une dizaine d'annÃes
(Unicode est sortie en 1990, et a Ãtà stabilisÃe au moment de la fusion avec
ISO10646 en 1991).


>> Non. Les encodages historiques sont des compromis
>
> Oui, c'est pour Ãa que je prÃcise "aujourd'hui". Mais c'est un
> hÃritage qui devient de plus en plus encombrant.

C'est de plus en plus encombrant depuis... les annÃes 1970 !
Dans ce domaine des codifications, l'ASCII et l'unification des
architectures sur la base des octets ont Ãtà une rÃvolution, sur la base des
quelles beaucoup de gens ont construit depuis... et les consÃquences n'ont
pas cessà d'Ãtre de plus en plus gÃnantes en bout de chaÃne.
Mais bon, tout est relatif, on fait avec, de toutes faÃons les machines sont
de plus en plus puissantes, les tuyaux de plus en plus larges, ...


>>> [Unicode (et UTF-8, son encodage "naturel" pour ] du stockage)
>> non, sauf si vous avez un penchant pro-europÃen (comme par exemple
>> celui
>
> Euh, pourquoi pas pour du stockage ?

Ce n'est pas l'encodage naturel (ou pas toujours). Suivant les applications,
on pourra utiliser un encodage à base ASCII (par exemple, pour du courrier
Ãlectronique en 2007), ou un jeu de caractÃre dÃpendant du systÃme (s'il
l'on cause avec un autre systÃme qui ne bavarde _que_ dans ce jeu), ou
UTF-16 (si l'on manipule des donnÃes du monde global et que l'on souhaite
utiliser au maximum la propriÃtà de taille fixe, quitte à faire des
exceptions pour les caractÃres hors BMP). UTF-8 est adaptà à certains cas de
stockage, par exemple si l'on veut pouvoir modifier les donnÃes facilement
avec des outils externes (chose difficile à faire avec du UTF-16) ; et pas
du tout à d'autres, par exemple si tu veux stocker des donnÃes de taille
dÃfinie dans un fichier à accÃs alÃatoire (enfin, on peut le faire, mais
c'est du gÃchis d'espace ; il vaut mieux repenser l'application, taille
variable avec accÃs indirect aux donnÃes).

> J'ai idÃe que une fois compressÃ,
> la diffÃrence avec du ISO ne se voit pas vraiment (on compresse de
> toute maniÃre le chunk au dessus en gÃnÃral, qui ne fait que changer
> de forme).

Pour les idÃogrames, utf8 reprÃsente +50%. Pour l'arabe, le cyrillique ou le
grec, plus de +85%. Pour les langues indiennes (y compris le thaÃ), +200%.

Si on comprime les donnÃes stockÃes, Ãvidemment les diffÃrences vont Ãtres
plus faibles, puisque l'information initiale est toujours la mÃme, donc les
diffÃrences ci-dessus sont redondantes. Mais dans tous les cas, il faut
stocker quelque part les mÃtadonnÃes de cette redondance.


>> la difficultà d'avoir des fontes et
>
> Ca a toujours Ãtà vrai. Ca l'est moins, dans la mesure oà des fontes
> sont dÃsormais disponibles de maniÃre raisonnable un peu partout (y
> compris Linux) ; ce qui n'Ãtait pas gagnà vu les problÃmes ancestraux
> de licence liÃs aux polices de caractÃre..

Avec un encodage genre iso-8859-x, il suffit de quelques heures à n'importe
quel pÃkin avec les bons outils pour dessiner une police de caractÃre
complÃte. Rien de tel avec Unicode, oà il est en fait impossible d'avoir une
couverture de 100%, mais de plus il est largement plus compliquà de faire
une police adaptÃe  seulement  au franÃais ; sans compter qu'on va
forcÃment tomber sur un mauvais coucheur qui va se plaindre que tel ou tel
caractÃre prÃsent dans Unicode n'est pas prÃsent dans la police (mon dernier
exemple en date : j'ai manipulà des Ãcarts-type, donc j'ai eu besoin du
Ï...)

Quels sont les problÃmes de licence liÃs à Unicode auxquels tu fais allusion
? De tout temps il y a eu des problÃmes, liÃs entre autres au fait que les
AmÃricains ont dÃcidà que les polices ne sont pas protÃgÃes par le Copyright
(et il y a bien sÃr un rapport avec le fait que la typographie est nÃe et a
grandi en Europe).
Le vrai problÃme n'a rien à voir avec les licences, il est que le travail de
celui qui dessine des caractÃres n'est pas rÃtribuà ; et Unicode demande la
crÃation de nombreux caractÃres...
C'est en fait le mÃme problÃme de fond que celui de l'industrie du disque ou
du cinÃma en ce moment : les consomateurs, quand ils sont trÃs nombreux,
estiment qu'ils n'ont pas à rÃnumÃrer les crÃateurs s'ils n'ont pas
d'exclusivitÃ. Et le modÃle de rÃnumÃration utilisà prÃcÃdement (celui des
typographes au plomb ou celui des disques en plastique) qui Ãtait de lier la
rÃnumÃration du crÃateur à un support obligatoire, a sombrà avec les
technologies digitales.

En fait, depuis de nombreuses annÃes on peut faire tourner sur Linux un X11
avec des polices tramÃes encodÃes Unicode (plutÃt que JIS ou Big5) ; mais le
rÃsultat Ãtait pitoyable à cause de la taille des structures par rapport Ã
la mÃmoire disponible. C'est lià au fait que l'architecture de X11 est
pensÃe pour des jeux de caractÃres de quelques centaines de caractÃres ; et
on revient au propos du dÃbut, Unicode oblige à casser tout (chose que le
projet Linux n'a pas fait dans le domaine de l'interface graphique).
Un autre problÃme Ãtait (est toujours en fait) dà au fait que la technologie
des polices bouge vers les polices vectorielles et TrueType en particulier
(Type1 est restreint à 8 bits dans la pratique), et là le problÃme, ce sont
les brevets detenus par Apple qui coincent. Mais tout cela n'a rien à voir
avec les problÃmes de licence de polices.


Antoine


<Prev in Thread] Current Thread [Next in Thread>