HS -utf 8

[Xavier Roche]

Oulah, là on est vraiment HS sur frc..

L'UTF-8 est semble-t-il une norme.

Une norme pour représenter ("encoder") des caractères Unicode. Unicode
étant "le" système attibuant un numéro unique aux caractères (latin,
arabe, chinois, etc.)

Hop, petit topo:
<http://www.unicode.org/standard/translations/french.html>

L'ISO 8859-1 ou -14 (Euro) est une norme.

Qui deviennent de plus en plus obsolète.

L'UTF-8 couvre plus de caractères que l'ISO 8859-1 (langues
orientales...) mais est moins bien reconnu selon les machines et/ou les
systèmes d'exploitation.

Bof. Aujourd'hui il a tendance a être mieux reconnu que certains ISO peu
usités. Quel système d'exploitation ne reconnait pas Unicode, à l'heure
actuelle ? Même en retournant dix ans en arrière, je ne vois pas..

De l'UTF-8 envoyé par un PC sous windows et lu sur un Mac, ça donne du
vénusien septentrional très peu lisible.

Non non, impossible. La représentation UTF-8 est unique, quelque soit le
système. C'est une suite d'octets 8 bit parfaitement normalisée, non
redondante, non changeante, et compatible avec l'ASCII.

Il se *peut* que certains logiciels aient du mal avec la représentation
en UCS-2 sur deux octets (variantes "petit boutien" et "grand boutien")
si cette dernière n'est pas préfixée par un marqueur de début (0xfeff),
mais il est rare de voir de l'UCS2 circuler (on préfère l'UTF-8, qui a
l'avantage d'être naturellement compatible avec l'ascii)

L'ISO 8859-1 et dérivés permet de s'affranchir de toutes ces conversions

Non. Les "encodages" historiques représentent aujourd'hui un maelström
infernal qui suppose d'avoir autant de systèmes d'encodage que de types
de caractères, avec des cas extrèmes (le Chinois/Japonais/Coréen qui
utilisent des caractères communs, mais qui se trouvaient encodés de
manière totalement différente selon les cas: BIG5, Shift-Jis, les
infâmes ISO-2022-* (beurk) etc.)

Unicode (et UTF-8, son encodage "naturel" pour du réseau et du stockage)
est le seul système à pouvoir (enfin) s'affranchir une bonne fois pour
toutes des problèmes de caractères.

(FU2 fr.comp.normes.unicode parce que c'est _vraimet_ HS ici)

[xcomm]

Post by Xavier Roche
Il se *peut* que certains logiciels aient du mal avec la représentation
en UCS-2 sur deux octets (variantes "petit boutien" et "grand boutien")
si cette dernière n'est pas préfixée par un marqueur de début (0xfeff),
mais il est rare de voir de l'UCS2 circuler (on préfère l'UTF-8, qui a
l'avantage d'être naturellement compatible avec l'ascii)

L'ISO 8859-1 et dérivés permet de s'affranchir de toutes ces conversions

Bonsoir,

Hélas, chez moi, l'UTF-8 ne passe pas de manière automatique, malgré le
réglage de détection de l'encodage de manière automatique "type
universel". C'est le SEUL qui me pose des problème. J'ai fait des tests
en arabe, en japonais, en chinois, et en russe, et mon système
fonctionne correctement avec ces différents types d'encodage. Et
pourtant, je n'utilise pas un lecteur propriétaire, mais un produit
"open source" de la maison Mozilla.org...

Si quelqu'un a une solution pour me permettre de pouvoir lire
correctement et automatiquement l'UTF-8 sous SeaMonkey sans avoir à le
spécifier manuellement pour chaque message, je suis preneur.

Mais comme ton message est codé en ISO-8859-15, je n'ai pas de problème
pour le lire. Merci pour avoir fait l'effort de rendre ton message
lisible par le plus grand monde :-)

Bonne soirée.
A+, Xavier

[Xavier Roche]

Post by xcomm
Si quelqu'un a une solution pour me permettre de pouvoir lire
correctement et automatiquement l'UTF-8 sous SeaMonkey sans avoir à le
spécifier manuellement pour chaque message, je suis preneur.

Euh, j'utilise également seamonkey (1.1.x), et je n'ai jamais eu de
problèmes avec l'UTF-8.

La détection automatique en UTF-8 est triviale, au passage: en première
approximation, si aucune erreur de décodage n'est survenue, c'est de
l'UTF-8.

(Tiens, hop, je passe en UTF-8 pour tester sous seamonkey.)

[Antoine Leca]

Post by Xavier Roche

L'ISO 8859-1 ou -14 (Euro) est une norme.

Le monsieur doit probablement faire allusion à -15.

Post by Xavier Roche
Qui deviennent de plus en plus obsolète.

Obsolète : « Qui est tombé en désuétude, sorti de l'usage. » in
/Dictionnaire de l'Académie, neuvième édition/.

Donc non, pas d'accord. D'ailleurs, je réponds à un votre message acommodée
à cette façon (histoire de faire obsolète.)

Post by Xavier Roche

L'UTF-8 couvre plus de caractères que l'ISO 8859-1 (langues
orientales...) mais est moins bien reconnu selon les machines et/ou
les systèmes d'exploitation.

Bof. Aujourd'hui il a tendance a être mieux reconnu que certains ISO
peu usités.

Le monsieur doit probablement faire allusion à ISO/CÉI 8859.

Post by Xavier Roche
Quel système d'exploitation ne reconnait pas Unicode, à
l'heure actuelle ?
Même en retournant dix ans en arrière, je ne vois pas..

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. Et il y avait largement
suffisament avec une seule main !
RFC 2044 est bien datée octobre 1996, mais c'était très expérimental à
l'époque ; le vrai mouvement a _commencé_ avec la RFC 2277... en 1998.

Post by Xavier Roche

De l'UTF-8 envoyé par un PC sous windows et lu sur un Mac, ça donne
du vénusien septentrional très peu lisible.

Balivernes.

Post by Xavier Roche

L'ISO 8859-1 et dérivés permet de s'affranchir de toutes ces conversions

Non. Les "encodages" historiques représentent aujourd'hui un maelström
infernal qui suppose d'avoir autant de systèmes d'encodage que de
types de caractères, avec des cas extrèmes (le
Chinois/Japonais/Coréen qui utilisent des caractères communs, mais
qui se trouvaient encodés de manière totalement différente selon les
cas: BIG5, Shift-Jis, les infâmes ISO-2022-* (beurk) etc.)

Non. Les encodages historiques sont des compromis, adaptés aux nécessités
qu'ils servaient au moment où ils ont été conçu.
Cela ne veut pas dire qu'ils sont encore justifié aujourd'hui, loin de là,
mais la présentation qui en faite ci-dessus est aussi injustifiée que celle
qui dirait que Unicode ne sert à rien.

Post by Xavier Roche
Unicode (et UTF-8, son encodage "naturel" pour du réseau

oui

Post by Xavier Roche
et du stockage)

non, sauf si vous avez un penchant pro-européen (comme par exemple celui
qu'ont les langages à balises, sachant bien sûr que les balises doivent
forcément être encodées avec les caractères du jeu ASCII.

Post by Xavier Roche
est le seul système à pouvoir (enfin) s'affranchir une
bonne fois pour toutes des problèmes de caractères.

Et non, il ne s'affranchit pas de *tous*. Il en résout certains, mais en
créé d'autres. Par exemple, avec les jeux ISO/CÉI 8859 (sauf le -11, et
encore), la logique de représentation des textes était simple ; avec les
jeux d'Extrême-Orient, guère plus compliquée dans le principe, seule
l'application était gênée par le nombre des idéogrammes.

Avec Unicode, on a les délices des caractères combinants et autres
canonisations, les versions de la norme, la difficulté d'avoir des fontes et
j'en passe des plus drôles [dans un sens obsolète] comme le virus CodeRed.


Antoine

[Xavier Roche]

Post by Antoine Leca
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), et
Linux aussi (bon, d'accord, personne ne réglait alors la locale sur
UTF-8 :p)

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

Post by Antoine Leca
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.

Post by Antoine Leca

Post by Xavier Roche
et du stockage)

non, sauf si vous avez un penchant pro-européen (comme par exemple celui

Euh, pourquoi pas pour du stockage ? 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).

Post by Antoine Leca
Et non, il ne s'affranchit pas de *tous*. Il en résout certains, mais en
créé d'autres.
Avec Unicode, on a les délices des caractères combinants

Oui, ça c'est clair. On peut également citer la
normalisation/désaccentuation/etc. qui ont 36 variantes toutes aussi
tordues, les problèmes de caractères "qui peuvent être confondus"
(confusable characters) et qui font la joie des pêcheurs à la ligne
électronique, etc.

Post by Antoine Leca
canonisations, les versions de la norme, 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..

[Antoine Leca]

Post by Xavier Roche

Post by Antoine Leca
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.

Post by Xavier Roche
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...

Post by Xavier Roche
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).

Post by Xavier Roche

Post by Antoine Leca
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, ...

Post by Xavier Roche

Post by Antoine Leca

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

Post by Xavier Roche
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.

Post by Xavier Roche

Post by Antoine Leca
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

[Méta-MCI (MVP)]

Bonsoir !


Juste un détail...

les balises doivent forcément être encodées avec les caractères du jeu
ASCII.

Avec XML 1.0, oui ; mais ce n'est plus forcé avec XML 1.1


@-salutations