Kaixo! On Tue, Aug 03, 2004 at 08:00:07PM +0200, Jean-Francois Straeten wrote:
>> Unicode sera à terme le seul encodage utilisÃ; il est donc normal >> qu'il y aie convergence vers son adoption. > > Je suppose que le "à terme", c'est Ãa qui explique qu'il y ait > "plusieurs" utf-8 ? non, il n'y a qu'un et un seul utf-8; c'est justemment là sa beautà (contrairement à utf-16 qui lui existe en plusieures versions suivant que le systÃme est grand boutien ou petit boutien) > pas bien, si utf-8 est un codage unique, c'est qu'il y en ait malgrà > tout... plusieurs ? UTF-8 est unique. Ceci dit, UTF-8 n'est pas le seul encodage possible d'unicode, c'est vrai (Windows utilise UTF-16 par exemple). Mais dans le contexte des systÃme GNU/Linux c'est UTF-8; ainsi que pour ce qui est du partage de documents textuels qui utilisent des protocoles travaillant avec des octets. (HTML, email, news, etc) Note que je dis que à terme *unicode* sera le seul utilisÃ, non pas "UTF-8". Mais une fois que unicode sera la norme, les differeces entre UTF-8, UTF-16, UTF-32 etc seront transparentes pour l'utilisateur, et dependentes soit du systÃme (codage interne aux programmes) soit dependent de la definition du document (xml, html, le courrier ÃlÃctronique, les news, etc. tous prevoient d'indiquer l'encodage utilisÃ; des formats de fichiers comme ceux des traitements de texte ont aussi un encodagà bien connu qui est utilisÃ; donc il n'y a pas de problÃme). Les differences entre UTF-8, UTF-16, etc. c'est la maniÃre de *representer* un mÃme nombre (le code unicode d'un caractÃre) en une suite de bits; mais le code du caractÃre, lui, reste toujours le mÃme. Avec les anciens encodages, il y a aussi le mÃme problÃme de representation en suite de bits (surtour visible dans le courrier/news avec le quoted-printable et base64; mais, *en plus* un code comme 0xb9 par exemple on ne peut pas l'interpreter sans savoir le jeu de caractÃres utilisÃ, car dans iso-8859-9 ou tis-620 Ãa represente des choses totalement differentes. >> SuSE a semble-t-il choisi la premiÃre. > > En fait, elle laisse le choix : il y a toujours moyen d'avoir > l'iso8895-1 en choisissant la locale adÃquate. C'est juste de l'utf-8 > par dÃfaut. Ah, je ne savais pas qu'ils proposaient le choix de l'encodage, c'est nouveau alors, avant ils ne le fesaient pas (il y a dà avoir des rouspetances sans doute). note: la possibiltie de modifier à la main les variables LC_* ce n'est pas "laisser le choix" (Ãa toutes les distributions le permettent), je parle bien de la possibilità de le configurer via les outils de configuration standard de la distrib (yast donc pour SuSE) Pour info, personellement, ce qui me reste encore en iso-8859-1 chez moi, ce sont des fichiers LaTeX (c'est possible depuis peu d'utiliser directemment utf-8 dans le source; mais je n'ai pas encore essayÃ); mon Ãditeur (vim :) ) fait la conversion à la volÃe; donc c'est transparent, mais si je mets un caractÃre absent de iso-8859-1 (Å, â par exemple, ou des caractÃres de l'alphabet phonetique, etc) alors lors de la savegarde Ãa ne marche pas car la conversion est impossible. Sans doute qu'un jour je deciderait de tout convertir en utf-8. >> Dans le temps on faisait des bidouilles immondes pour faire semblant, >> avec un encodag ecyrillique par exemple, que c'Ãtait une suite de >> caractÃres iso-8859-1; Ãa marchait plus ou moins; mais pas en utf-8 >> (car utf-8 est multi-octets). > > Si je comprends bien, l'utf-8, et les autres encodages, Ãa conditionne > la maniÃre de stocker (et relire) du texte sur disque, c'est Ãa ? Oui. Donc un programme pour qu'il soit capable de travailler avec du texte dans n'importe quelle langue, il doit: - soit n'utiliser que unicode en interne et rien d'autre - soit avoir un moyen de luis specifier l'encodage des donnÃes, pour qu'il puisse le cas Ãcheant les recoder selon ce qui est demandà à l'affichage. Dans le cas de groff, il ne reconnaÃt *que* iso-8859-1 (c'est codà en dur); si le source est en iso-8859-1 et la sortie (le terminal) aussi, Ãa va; si le source est en iso-8859-1 et la sortie est en utf-8, grande nouveautà depuis peu, Ãa va aussi. par contre si le source est autre chose que iso-8859-1.... groff interpretera Ãa comme un suite de caractÃres iso-8859-1, genre "ÃÃÃÃÂÃÃÃÃ" à la place d'un mot en cyrillique. > Et aussi, comme il est multi-octets (par caractÃre je suppose ?), oui, un caractÃre peut faire de 1 à (4?, 6? me souviens plus) octets. l'avantage c'est qu'il n'y a jamais de sequences d'octets nuls (0x00), ce qui fait qu'un flux utf-8 passe sans problÃme à travers tout programme qui supportait du texte 8bits (pas besoin de modifier les serveurs http, les serveurs mail, etc. *gros* avantage). UTF-16 (qui a tous les desavantages de UTF-8 (UTF-16 est multi-saizet), aucun de ses avantages, et des desavantages supplementaires) par contre peut avoir des suites de bits 00000000, ce qui est considerà comme le caractÃre nul en C, et donc les textes pourraient Ãtre tronquÃs; hors tous les caractÃres ascii sont dans le cas; un email en UTF-16 passant sur un serveur de mail non prÃvu pour travailler en UTF-16 tronquerait donc le fichier dÃs le premier caractÃre; il n'aurait mÃme pas la premiÃre en-tÃte! (alors que le mÃme mail en UTF-8 passera sans problÃme sur tout serveur smtp de moins de 15 ans) > est-ce que cela revient à dire que les fichiers texte pourraient > prendre plus de place, ou bien c'est une Ãnerie ? plus de place qu'en iso-8859-1? oui. maintenant, il faut voir qu'en iso-8859-1 tu ne peux mÃme pas Ãcrire du franÃais correct (pas de Å) ni parler d'euros; et je ne parle mÃme pas d'inserer des mots en grec, russe, ou polonais... Et puis, l'augmentation de taille (de 0% pour de l'ascii, à 50%-60% dans les pires cas) est assez nÃgligeable quand on voit la taille moyenne des disques durs et la proportion du texte par rapport à d'autres donnÃes (programmes, images, films, son,...) dans leur remplissage. >> Il faut utiliser sous Windows des Ãditeurs de texte decents, capables > > La moins mauvaise des applis Windows, le Notepad :-) > > En tout cas, il m'a ouvert comme il faut sous w2k Pro un fichier en > utf-8 crÃà avec Emacs (aprÃs un unix2dos naturellement). Il faut voir si unix2dos n'ajoute pas le BOM justemment... essaye de crÃer un fichier utf-8 d'une seule ligne, avec quelques caractÃres; et de l'ouvrir avec notepad sans passer par unix2dos, pour voir. -- Ki Ãa vos vÃye bÃn, Pablo Saratxaga http://chanae.walon.org/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Catalan or Esperanto] [min povas skribi en valona, esperanta, angla aux latinidaj lingvoj]
pgpbbdwwk2sfY.pgp
Description: PGP signature
_______________________________________________________ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: chat.unixtech.be:6667 - #unixtech
