Discussion: envoi mails en vietnamien

Je vais essayer de mettre un peu d'ordre dans une discussion qui me parait pédaler dans le yogourt !

Tout d'abord, Unicode (contrairement à ce que son nom pourrait laisser penser) n'est pas un code. C'est la définition d'un jeu de caractères standards universel (Universal Character Set, UCS). UCS est défini par les normes ISO 10646 et 10646-2 comme étant un jeu de 2.147.483.648 caractères (il y a de quoi faire , y compris pour les langues actuelles, anciennes ou futures, alphabétiques, idéographiques ou hiéroglyphiques !).
La définition est organisée hiérarchiquement: 128 groupes composés chacun de 256 plans, eux-même composés de 256 rangées de 256 caractères chacune. Chaque caractère défini reçoit un numéro (allant de 0 à 2.147.483.647). Actuellement, tous les caractères possibles ne sont pas définis (de loin s'en faut ), seul le groupe 0 (65536 caractères possibles) contient des caractères, et encore, le groupe est plein de vide, malgré la présence des idéogrammes chinois et des hiéroglyphes égyptiens ! Ce groupe 0 est appelé BMP (Basic Multilingual Plan).
C'est ainsi que les caractères vietnamiens sont dans le BMP (groupe 0), plan 0, rangée 30, rangée dite "Latin Extended Additional" allant du caractère 7680 au caractère 7935. Plus spécifiquement, les caractères vietnamiens sont les caractères allant de 7840 à 7929.

Le fait de définir un jeu de caractères n'en fait pas pour autant quelque chose de directement utilisable sur un ordinateur. Il faut coder ce jeu de caractères.
Le code le plus simple est, sans aucun doute, d'utiliser directement le numéro associé au caractère pour le codage, c'est le codage UCS-4 sur 4 octets (32 bits*). Solution simple en théorie, mais, en pratique, à ma connaissance, il n'existe pas de périphérique d'entrée-sortie (clavier, écran, etc) acceptant des caractères de 32 bits, pas plus que de logiciels implémentant directement UCS-4 (encore que les librairies disponibles sous Linux permettent d'implémenter directement UCS-4 ).
Il existe une autre solution, ne coder que le BMP (puisque les seuls caractères définis actuellement sont dans le BMP) sur 2 octets (16 bits), c'est le codage UCS-2. De nouveau, à ma connaissance, pas de périphérique d'entrée-sortie, mais, quelques logiciels (surtout des logiciels libre ;D) supportent UCS-2.
Pour finir, il existe un système de codage d'UCS assez largement répandu: UTF-8. C'est un codage d'UCS sur un nombre variable (de 1 à 6) de caractères de 8 bits. Les 128 premiers caractères d'UCS sont totalement compatibles avec les caractères ASCII (ISO 646), UTF-8 va donc coder ces caractères sur un seul caractère et ainsi la compatibilité est totale avec des logiciels n'utilisant que le code ASCII. Pour les 128 caractères suivants, UTF-8 les code sur 2 caractères de 8 bits. Mais les choses sont un peu plus complexes. Les anciennes normes (actuelles pour certains retardés comme Microsoft), ISO 8859-x n'assurent pas une correspondance totalement univoque entre caractère et codage, tout dépend du -x utilisé (quel est le malade qui a imaginé un tel truc ). Et c'est là que réside tout le problème posé par les langues accentuées !

La conversion UCS <-> UTF8 est loin d'être triviale**.
Microsoft, qui n'a jamais été connu pour la qualité de sa programmation, a pondu sa version d'UTF-8 totalement délirante et qui, en plus, fonctionne de façon très imparfaite.
À l'opposé, les fonctions proposée par la FSF (Freee Software Foundation), utilisés par Linux implémentent de façon tout à fait correcte UTF-8 (je parle en connaissance de cause, j'ai travaillé dessus ).

Et, en plus du codage d'UCS, il faut disposer de représentations graphiques des caractères sur imprimantes et écrans, c'est ce que l'on appelle les polices de caractères. Là encore, Microsoft a des années de retard sur l'état de l'art.


CONCLUSION:
Utilisez des logiciels libres, je ne dis pas que vous n'aurez plus de problème, mais vous en aurez infiniment moins qu'avec des produits dont on ne sait pas trop comment ils sont fabriqués. Ou, plutôt, on le sait trop bien: à la va-vite, pour les sortir le plus rapidement possible (vite fait, mal fait) et pouvoir ainsi ouvrir en grand son tiroir-caisse.

Voilà, c'était la page du matin d'un prof qui reprend du poil de la bête.



* bit: chiffre binaire.

**pour les connaisseurs:
Il s'agit de modules séquentiels à mémoire, l'état de sortie dépend de la combinaison des entrées ET de l'état antérieur du module, ce qui pose des problèmes relativement délicats en cas de réentrance. Contrairement à une transcodification simple, purement combinatoire.

Envoyé par abgech

Je vais essayer de mettre un peu d'ordre dans une discussion qui me parait pédaler dans le yogourt !
...un jeu de 2.147.483.648 caractères
...CONCLUSION:
Utilisez des logiciels libres, je ne dis pas que vous n'aurez plus de problème, mais vous en aurez infiniment moins qu'avec des produits dont on ne sait pas trop comment ils sont fabriqués. Ou, plutôt, on le sait trop bien: à la va-vite, pour les sortir le plus rapidement possible (vite fait, mal fait) et pouvoir ainsi ouvrir en grand son tiroir-caisse.
...Voilà, c'était la page du matin d'un prof qui reprend du poil de la bête.

salut abgech,
2.147.483.648, c'est 2 exposant combien?
En ce qui concerne les logiciels sous Linux, j' hésite encore à me lancer.faudra-t-il que je recherche ensuite tous les logiciels de remplacement ?(photoshop, traitement de textes, tableurs, etc...)
Quand au prof qui reprend du poil de la bête, tu en prendras toujours jusqu'à ce que les neurones n'en puissent plus.C'est notre karma de prof.:bigthumbup:
Je vais tirer ton cours sur papier, et je vais essayer d'y comprendre quelque chose
Salut et bonnes fêtes à toi et aux tiens:kimouss:

Envoyé par claudio

pour ceux qui veulent en savoir plus:
http://nguyentl.free.fr/html/sujet_s...tm#ecrire_viet
tres bien fait..c'est le coup des polices que je n'avais pas capté.

cette page a presque 10 ans... et quelques confusions
- les caractères ASCII (ISO 646) c'est les 128 premiers caractères qui n'ont pas d'accents
- Il n'explique pas l'astuce permettant de faire du pseudo Unicode avec uniquement de l'ASCII (peut-être que les navigateur genre IE5 ne le supportaient pas encore a l'époque) grâce a la séquence :
et-commercial + dièse + le numéro Unicode en toute lettre + par point-virgule
- les 12 autres techniques VNI, TCVN, VPS, VISCII... pour écrire en vietnamien sont maintenant abandonees

Pour ce qui est des messageries
Notez que la nouvelle version de la messagerie yahoo.fr est une page UTF8 et si elle ne vous aimer mieux l'ancienne version, comme moi, ils vous donnes une page en Occidental (ISO 8859-1)
@NoiVongTayLon ainsi pas besoin de créer un compte dans "Yahoo Vietnam" pour résoudre ce problème

Si vous conservez votre vielle messagerie en Occidental (ISO 8859-1) vous copiez collez du vietnamien, votre ordinateur va générer un mélange de ISO 8859-1 (les accents communs au français et VN) + du faux unicode
-Votre correspondant utilise la même vieux bidule, pas de problème.
- votre corespant est en UTF8 , il ne voit tout sauf le français (e accent grave et aigu...)

Votre correspondant vietnamien vous répond avec sa messagerie UTF8 :
Dans le texte en français comme en VN, les accent sont remplaces par "rA©action" pour "réaction"
Mais vous pouvez le lire en forçant votre navigateur a utiliser l'encodage UTF8 mais les accent du cadre de la messagerie sont remplaces par des petit carres ops:

dans Internet Explorer, il faut aller dans Affichage > Codage > Unicode UTF8. Dans Firefox, il faut aller dans Affichage > Encodage des caractères > Unicode UTF8

Envoyé par thuong19

salut abgech,
2.147.483.648, c'est 2 exposant combien?

2 puissance 31. Et ta question me pose une colle ! À quoi sert le 32em bit ? J'imagine pour un contrôle de parité, mais cela n'aurait de sens que pour un codage. Sans doute pour préparer l'avenir, codage direct en UCS-4. Et je n'ai pas de doc sous la main pour confirmer mon sentiment.

Envoyé par thuong19

En ce qui concerne les logiciels sous Linux, j' hésite encore à me lancer.faudra-t-il que je recherche ensuite tous les logiciels de remplacement ?(photoshop, traitement de textes, tableurs, etc...)

Photoshop: Gimp ! (Voir http://www.gimp-fr.org/news.php )
Je l'utilise, sans être un utilisateur exigeant. Mais, d'après ce que j'en entends dire, peut remplacer photoshop sans problème.

Traitement de texte, tableurs: Openoffice ! (Voir http://fr.openoffice.org )
Remplace:
1) Microsoft word (peut lire et écrire des fichiers compatibles avec word).
2) Microsoft excel (peut lire et écrire des fichiers compatibles avec excel).
3) Microsoft Powerpoint (peut lire et écrire des fichiers compatibles avec powerpoint).
4) Contient un éditeur d'équations assez performant.
5) Contient un logiciel de dessin vectoriel.
6) Contient une base de donnée. Je ne connais pas trop ce dernier logiciel, parce qu'il existe d'autres produits libres extrêmement performants (MySQL, PostgreSQL).

Multimédia: vlc, xine, amarok, kaffeine ...
Là, c'est plutôt l'embarras du choix. Il existe une grande quantité de logiciels libres consacrés au multimédia. Personnellement, j'utilise vlc, fonctionnalités assez avancées, pas de codecs, mais un interface moins "léché" que d'autres produits.

Lecture de pdf: Acrobat (n'est pas vraiment un logiciel libre, mais gratuit).

Gestion de photos: digiKam,

Gravure de CD/DVD: K3B, plus performant que Nero.

Navigateur internet: Firefox(et bien d'autres) l'essayer, c'est l'adopter.

Gestion de courriel: Thunderbird (et bien d'autres), pas forcément le plus génial mais c'est celui que j'utilise.

Etc, etc !

On dit que le point faible de Linux, c'est les jeux. Comme je ne joue jamais (la programmation remplace absolument tout les jeux !) je ne sais pas trop. Je sais qu'il existe plusieurs centaines de jeux pour Linux, mais je ne peux rien en dire d'autre. Par contre, il me semble que les vrais amateurs de jeux préfère avoir une console que d'utiliser un ordinateur.

Tu trouves Gimp, Openoffice, vlc, acrobat, firefox, thunderbird en version Windows, ce qui te permet de faire une transition en douceur vers les logiciels libres: d'abord les applicatif et ensuite le système d'exploitation (Linux ou une des variantes de BSD).

Re: pourquoi 2^31?

Je m'y essaye.

2 puissance 31 = 2,147,483,648.

Si on codait brutalement sur 4 octets comme UTF-32 (Abgech, est-ce la même chose qu'UCS4?), on aurait les caractères de 0 à 2^32-1, soit deux fois plus. En UTF-8, on a perdu de la capacité de coder des très grands nombres. Ỏu est l'intérêt? C'est la capacité de coder simplement et légèrement les fichiers les plus courants.

Quand on code en UTF-8, on peut employer un seul octet pour les 128 premiers caractères, de 0 à 127, et le bit de poids fort de l'octet est à 0. Quand ce bit est à zéro, l'application sait dire que c'est un octet seul, et interpréter 65dec (décimal), soit 01000001bin (binaire) comme la lettre A.

Pour les caractères de numéro supérieur à 127, pour deux octets, le premier octet commence par 110, suivi de 5 bits significatifs (les bits de poids fort du numéro unicode), puis un deuxième octet qui commence par 10 suivi de 6 bits significatifs. On encore donc 2^(5+6) = 2^11 = 2048 caractères.

Pour plus de caractères, on emploie 3 octets: 1110xxxx 10yyyyyy 10zzzzzz, soit 2^16 = 65536 caractères. Juste assez pour tous les caractères existants. Sur 4 octets, on code sur 4 octets: 11110www 10xxxxxx 10yyyyyy 10zzzzzz, donc 3w, et 6 x, y et z, donc 2^21. Je n'ai jamais vu de caractère encodé sur 4 octets. Ca doit exister. UTF-8 peut encoder par définition jusqu'à 6 octets: le premier 1111110x et 5 octets de la forme 10yyyyyy, soit 2^ (6 * 5 = 30 + 1 = 31) (le dernier bit du premier octet, qui est significatif).

Bingo.

On perd donc une part importante de la capacité de coder des grands nombres. (sur 6 octets, on peut coder en brut 6^36 caractères, soit 32 fois plus.

L'intérêt de ca, à part que peu de périphériques sont en 32 bits, c'est aussi que l'immense majorité des fichiers et des données sont essentiellement de l'ASCII --même si sur Linux on peut tout-à-fait écrire un source en UTF-8 avec du viet dans le texte et ca sera compilé sans souci, le programme lui-même, par exemple, est en ASCII, donc codé sur 7 bits.

De plus, cet encodage est "auto-synchronisé", c'est-à-dire que si on capte un flux de données, on peut toujours savoir à partir de quel octet on doit décoder pour avoir un texte clair.

Si la norme ISO 10646 ne définit d'encodage que sur 6 octets et non 7 (on pourrait imaginer 11111110 et 6 fois 10xxxxxx pour encoder 2^36 caractères), ca doit être que ca permet de se synchroniser même si on capte un flux de bits sans synchro, donc même si on ne sait pas òu commencent et òu finissent les octets. La classe.

C'est beau, l'info, quand c'est bien fait.

En tout cas, UTF-8 n'est pas près de se faire supplanter par un autre encodage, c'est son immense force. (Jusqu'à ce que le Chinois ou le Bengali supplante l'anglais pour l'info!)

Il n'y a vraiment que Windows pour ne pas vouloir implémenter ca proprement: comme ils ont une grosse part de marché, ca leur permet de garder une clientèle captive. Sur le web, le standard impose de savoir au moins reconnaitre UTF-8.

Envoyé par Nem Chua

...
Si on codait brutalement sur 4 octets comme UTF-32 (Abgech, est-ce la même chose qu'UCS4?), on aurait les caractères de 0 à 2^32-1, soit deux fois plus. En UTF-8, on a perdu de la capacité de coder des très grands nombres. Ỏu est l'intérêt? C'est la capacité de coder simplement et légèrement les fichiers les plus courants.

En principe, mais en principe, UCS-8 est la même chose UTF-32. Toutefois, il peut y avoir des subtilités que je ne maitrise pas. Repris de wikipédia ( http://fr.wikipedia.org/wiki/UCS ) (excellent article au demeurant, avec des liens pertinents):

Cependant, le temps passant, la situation changea dans le standard Unicode lui-même : 65.536 caractères devinrent vite insuffisants et, depuis la version 2.0 et suivantes, le standard supporte l'encodage de 1.112.064 caractères par les mécanismes de surrogate d'UTF-16. Pour cette raison, ISO 10646 fut limité à contenir autant de caractères que pouvait en contenir l'UTF-16, c.-à-d. à peine plus d'un de million caractères au lieu de plus de 2.000 millions. Le codage UCS-4 de l'ISO 10646 a été incorporé dans le standard Unicode avec la limitation de l'UTF-16 sous le nom d'UTF-32. Comme pour UTF-1, personne ne l'utilisa, en raison de son mauvais design (aucune manière de distinguer les octets solitaires, les octets de début de séquences et les autres octets, un problème similaire à celui du codage Shift-JIS pour le japonais) et de faibles performances (beaucoup d'opérations de division). Rob Pike et Ken Thompson, les développeurs du système d'exploitation Plan 9, conçurent un nouveau, rapide et bien-fini codage de taille variable, qui finit par être appelé UTF-8.

Pour le 32em bit, je persiste à penser qu'il s'agit d'une réserve pour un bit de parité.

Envoyé par Nem Chua

Je n'ai jamais vu de caractère encodé sur 4 octets. Ca doit exister.

Oui, le tableau de codage:
Codage sur:
1 caractère: 0xxxxxxx
du caractère 0 au caractère 127. 7 bits utiles sur 8.

2 caractères: 110xxxxx 10xxxxxx
du caractère 128 au caractère 2047. 11 bits utiles sur 16.

3 caractères: 1110xxxx 10xxxxxx 10xxxxxx
du caractère 2048 au caractère 65535. 16 bits utiles sur 24.

4 caractères: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
du caractère 65536 au caractère 2097151. 21 bits utiles sur 32.

5 caractères: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
du caractère 2097152 au caractère 67108863. 26 bits utiles sur 40.

6 caractères: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
du caractère 67108864 au caractère 2147483647. 31 bits utiles sur 48.

UTF-8 permet de représenter la totalité de l'UCS (avec deux restrictions, les caractères 254 et 255, en réfléchissant sur le codage en 2 carac. tu comprendras pourquoi ), y compris les idéogrammes et les caractères non encore définis (pour autant que l'on en ait une représentation graphique, une police) mais au prix d'une approche assez compliquée de chaines de caractères en longueur variable et un peu de perte de place.
Je travaille actuellement sur un éditeur multi-langage permettant de travailler caractères européen, symboles math, arabe, chinois, etc. Les données sont mémorisée sous forme de caractères de 32 bits (type wchar_t de la librairie GNU sous Linux, UCS-4) mais les entrées-sorties se font en UTF-8.

Envoyé par Nem Chua

De plus, cet encodage est "auto-synchronisé", c'est-à-dire que si on capte un flux de données, on peut toujours savoir à partir de quel octet on doit décoder pour avoir un texte clair.

La logique de décodage est de type séquentiel à mémoire, tant que l'on reste dans le cadre d'un traitement mono-tâche sans réentrance on se ramène à un cas dégénéré de cette logique, une approche purement combinatoire ce qui ne pose aucun problème. Par contre les choses se compliquent lorsqu'on implémente la réentrance: la fonction doit contenir une pile de variables d'état pour chacun des appels concurrent. C'est ce que tu appelle la synchro, effectivement, délicat, mais intéressant, à réaliser.

Envoyé par Nem Chua

Il n'y a vraiment que Windows pour ne pas vouloir implémenter ca proprement: comme ils ont une grosse part de marché, ca leur permet de garder une clientèle captive. Sur le web, le standard impose de savoir au moins reconnaitre UTF-8.

Je ne résiste pas à la tentation de citer encore wikipédia ( http://fr.wikipedia.org/wiki/UTF-8 ) pour illustrer la façon dont Microsoft "travaille":

De par son système de codage, il est possible de représenter un point de code de différentes manières en UTF-8, ce qui peut poser un problème de sécurité : un programme mal écrit peut accepter un certain nombre de représentations UTF-8, normalement invalides selon la RFC 3629 mais pas selon la spécification originale, et les convertir comme un seul et même caractère. De fait, un logiciel détectant certaines chaînes de caractères (pour prévenir les injections SQL, par exemple) peut échouer dans sa tâche.
Prenons un exemple tiré d'un cas réel de virus attaquant des serveurs HTTP du Web en 2001 ((en)[1] [2] [3]). Une séquence à détecter pourrait être « /../ » représentée en ASCII (a fortiori en UTF-8) par les octets « 2F 2E 2E 2F » en notation hexadécimale.
Cependant, une manière malformée de coder cette chaîne en UTF-8 serait « 2F C0 AE 2E 2F », appelée aussi en anglais overlong form (forme superlongue). Si le logiciel n'est pas soigneusement écrit pour rejeter cette chaîne, en la mettant par exemple sous forme canonique, une brèche potentielle de sécurité est ouverte. Cette attaque est appelée directory traversal.

Il est vrai que le but de Microsoft n'est pas de produire de bons logiciels, mais de maximiser son profit et, cela, ils le font parfaitement.

254 et 255, je vais y penser.

les 31 bits, tu les as donnés toi-même: " 6 caractères: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
du caractère 67108864 au caractère 2147483647. 31 bits utiles sur 48."

ca colle: c'est bien 31 bits sur 6 octets. (et il n' a plus de raison de chercher 32 bits: on n'est pas sur 4 mais sur 6 octets).

Un autre exemple est "degré C" ou "degré F", sachant qu'il y a des caractères unicode pour chacun (et d'autres), mais qu'on peut aussi les écrire en combinant "degré" et C ou F.

Le problème des normes, c'est qu'il faut qu'on les suive!

254 dec: 11000011 10111110 utf-8 (bits significatifs: 00011 111110 = 254d)
255 dec: 11000011 10111111 utf-8 (bits significatifs: 00011 111111 = 255d)

Ca m'a l'air de coller, je ne vois pas le problème, Abgech? me trompé-je?

Quid réentrance?

Exposés, somme toute, hautement intéressants ! (même si je comprends pas tout...! )
Mais...merci pour...la migraine !