panachage d'unicode et iso
Le
Herve Autret
Bonjour,
Je rencontre un problème en utilisant Doxygen. Les commentaires des
fichiers sources comportent des codes iso et de l'unicode car il ont été
écrits à différentes époques (et sur différentes machines par différentes
personnes). J'ai moi-meme déjà obtenu de genre de situation en changeant
de version de Linux au cours d'un travail
Dans ces conditions, Latex ne peut pas traiter le code produit par
Doxygen et les pages html comportent des caratères inaffichables.
J'ai essayé de convertir ces fichiers avec iconv, dans les 2 sens :
- ISO vers UTF : les caratères utf prennent un octet de plus et ne sont
pas plus affichables qu'avant.
- UTF ves ISO : sans l'option -c, le traitement s'arrête au premier
caractère ISO (non UTF). Avec cette option, les caractères ISO sont
éliminés de la sortie. Je peux tout reprendre à la main à ce stade, notez.
Mais je me dis qu'avec une option -V[erbatim] pour laisser passer les
caractères non reconnus sans les modifier, je pourrais espérer m'en tirer.
Pour peu que le non-UTF ne soit pas trop hétérogène (un mélange de
caractères MAC, windows et autres, par exemple), oeuf corse.
En passant, j'ai essayé uconv (http://site.icu-project.org/ : c'est de
l'opensource, ok). Bien que ce programme semble avoir plus de
possibilités, je n'en ai rien obtenu de plus.
Avant de me pencher sur le code de la libiconv, pour voir si l'ajout de
l'option "verbatim" est réalisable sans y passer trop de temps,
j'aimerais savoir si quelqu'un connaît une solution pratique au problème
du mélange d'encodages ?
Cordialement,
[Xpost f.c.divers, f.c.application.libre, f.c.normes.unicode,
Suivi proposé sur sur f.c.divers]
--
Hervé
Je rencontre un problème en utilisant Doxygen. Les commentaires des
fichiers sources comportent des codes iso et de l'unicode car il ont été
écrits à différentes époques (et sur différentes machines par différentes
personnes). J'ai moi-meme déjà obtenu de genre de situation en changeant
de version de Linux au cours d'un travail
Dans ces conditions, Latex ne peut pas traiter le code produit par
Doxygen et les pages html comportent des caratères inaffichables.
J'ai essayé de convertir ces fichiers avec iconv, dans les 2 sens :
- ISO vers UTF : les caratères utf prennent un octet de plus et ne sont
pas plus affichables qu'avant.
- UTF ves ISO : sans l'option -c, le traitement s'arrête au premier
caractère ISO (non UTF). Avec cette option, les caractères ISO sont
éliminés de la sortie. Je peux tout reprendre à la main à ce stade, notez.
Mais je me dis qu'avec une option -V[erbatim] pour laisser passer les
caractères non reconnus sans les modifier, je pourrais espérer m'en tirer.
Pour peu que le non-UTF ne soit pas trop hétérogène (un mélange de
caractères MAC, windows et autres, par exemple), oeuf corse.
En passant, j'ai essayé uconv (http://site.icu-project.org/ : c'est de
l'opensource, ok). Bien que ce programme semble avoir plus de
possibilités, je n'en ai rien obtenu de plus.
Avant de me pencher sur le code de la libiconv, pour voir si l'ajout de
l'option "verbatim" est réalisable sans y passer trop de temps,
j'aimerais savoir si quelqu'un connaît une solution pratique au problème
du mélange d'encodages ?
Cordialement,
[Xpost f.c.divers, f.c.application.libre, f.c.normes.unicode,
Suivi proposé sur sur f.c.divers]
--
Hervé
Ce problème se résout assez bien en décodant le fichier en UTF-8, et, en
cas d'erreur de décodage, en crachant les caractères en erreur en
effectuant une conversion ISO-8859-1 vers UTF-8 (en fait je dirais même
plus: du "dérivé" WINDOWS-1252 vers UTF-8; car on rencontre pas mal de
cochonneries venant de texte produit par Word et ses amis, notamment sur
le Web, mais ce n'est peut être pas utile dans votre cas)
Expérimentalement, je n'ai jamais rencontré de cas où existerait une
ambigüité (càd. plusieurs caractères Latin-1 qui serait pris pour un
caractère UTF-8) ; le standard UTF-8 est là encore remarquablement bien
foutu.
Après, je pense que cette fonction n'est en effet pas disponible en
standard dans icon et ses amis.. cela vaut presque le coup de réécrire
50 lignes de C pour ça, plutôt que d'essayer de patcher une
fonctionnalité exotique amha.
Le Mon, 06 Jun 2011 18:04:38 +0200, Herve Autret écrit:
La solution que jâimaginerais, serait de traiter le flux à la recherche
dâoctets de la forme 10xxxxxx, et ainsi de détecter les car actères encodés
en UTF-8 (le début du caractère se trouve alors au précà ©dent 0xxxxxxx ou
110xxxxx ou 1110xxxx ou 11110xxx); les autres seraient soit en ASCII 7
bits (qui de toute manière ne peut pas être distinguer de lâ UTF-8 ni de
lâISO 8859-1), et les autres encore enfin â ni ASCII ni UTF-8, seraient
des caractères ISO 8859-1 (ou supposé lâêtreâ ¦ une petite heuristique basé
sur les pages de code probables pourrait être utile dans le pire de s cas).
Sinon à part ça, je ne connais pas les sources de âlib iconvâ, je ne peux
donc pas me prononcer à ce sujet.
Bonne journée
-- Yannick Duchêne
--
âSyntactic sugar causes cancer of the semi-colons.â [Ep igrams on
Programming â Alan J. â P. Yale University]
âStructured Programming supports the law of the excluded muddle. â [Idem]
âc++; /* this makes c bigger but returns the old value */â [Anonymous]
Le Mon, 06 Jun 2011 18:04:38 +0200, Herve Autret écrit:
La solution que jâimaginerais, serait de traiter le flux à la recherche
dâoctets de la forme 10xxxxxx, et ainsi de détecter les car actères encodés
en UTF-8 (le début du caractère se trouve alors au précà ©dent 0xxxxxxx ou
110xxxxx ou 1110xxxx ou 11110xxx); les autres seraient soit en ASCII 7
bits (qui de toute manière ne peut pas être distinguer de lâ UTF-8 ni de
lâISO 8859-1), et les autres encore enfin â ni ASCII ni UTF-8, seraient
des caractères ISO 8859-1 (ou supposé lâêtreâ ¦ une petite heuristique basé
sur les pages de code probables pourrait être utile dans le pire de s cas).
Sinon à part ça, je ne connais pas les sources de âlib iconvâ, je ne peux
donc pas me prononcer à ce sujet.
Bonne journée
-- Yannick Duchêne
--
âSyntactic sugar causes cancer of the semi-colons.â [Ep igrams on
Programming â Alan J. â P. Yale University]
âStructured Programming supports the law of the excluded muddle. â [Idem]
âc++; /* this makes c bigger but returns the old value */â [Anonymous]
Le Mon, 06 Jun 2011 20:05:45 +0200, Xavier Roche a écrit:
Merci pour les réponses, je crois que je vais finalement me laiser tenter
par ce côté-là. 50 lignes, je ne sais pas : j'ai dessiné un automate à 6
états et 12 transisions (11 si on considère qu'une conversion forcée du
non-utf vers l'utf est réussie par nature ;-).
Mais de cette manière je vois où je vais.
De plus, la pérennité du truc n'est pas garantie de cette manière...
--
Hervé
Le Tue, 07 Jun 2011 06:41:09 +0200, Yannick Duchêne (Hibou57) a écrit:
Non, ça c'est justement un ASCII ;-). Mais le principe me plaît, comme je
disais à Xavier : je vais faire un truc comme ça.
à +
--
Hervé
Sauf sâil est suivi dâun 10xxxxxx : je parlais bien de r etrouver un
0xxxxxxx en remontant en arrière après avoir rencontré un 10xxxxxx⦠la
nuance est importante.
P.S. Je ne sais pas comme ça a été redirigé, mais jâ ai à lâorigine reçu ce
sujet sur âfr.comp.norme.unicodeâ auquel je suis abonnà ©, et quand jâai
voulu y répondre, ça a automatiquement sur âfr.comp.di versâ auquel je
nâétais pas abonné (mâenfin, pas grave, mainte nant je mây suis abonné)
--
âSyntactic sugar causes cancer of the semi-colons.â [Ep igrams on
Programming â Alan J. â P. Yale University]
âStructured Programming supports the law of the excluded muddle. â [Idem]
âc++; /* this makes c bigger but returns the old value */â [Anonymous]
Seulement à la lecture aux yeux dâun être humain, parc e quâà part ça,
lâambiguïté est totale aux yeux dâun programme informatique. Ce qui
indique dâailleurs quâune petite relecture, même en diagonale, des
fichiers traités par des yeux humains, sera sûrement recommand ée.
--
âSyntactic sugar causes cancer of the semi-colons.â [Ep igrams on
Programming â Alan J. â P. Yale University]
âStructured Programming supports the law of the excluded muddle. â [Idem]
âc++; /* this makes c bigger but returns the old value */â [Anonymous]
Oops, pardon, je mâaperçois que jâai compris le sen s à lâenvers
(tant-pis). Dans lâautre sens, oui, vrai que cette ambiguït é là est rare,
mais ce nâest pas à mettre au compte de la conception dâ UTF-8, mais plutôt
au compte des statistiques.
--
âSyntactic sugar causes cancer of the semi-colons.â [Ep igrams on
Programming â Alan J. â P. Yale University]
âStructured Programming supports the law of the excluded muddle. â [Idem]
âc++; /* this makes c bigger but returns the old value */â [Anonymous]
Le Tue, 07 Jun 2011 11:52:17 +0200, Yannick Duchêne (Hibou57) a écrit:
Au cas où la RFC suivante serait d'actualité :
http://www.rfc-editor.org/rfc/rfc3629.txt
On y lit, ligne 200 et avoisinantes, les 4 cas possibles de caractères
UTF-8 :
Char. number range | UTF-8 octet sequence
(hexadecimal) | (binary)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
Les caractères 0000 0000-0000 007F, c'est aussi de 0 à 127 : c'est
l'ascii standard sur 7 bits. Le caractère "en soi" qu'il n'y a pas
besoin d'interpréter en fonction des précédents ni des suivants.
D'ailleurs, vous l'aurez remarqué les premiers bits d'un caractère UTF
servent à compter le nombre d'octets de ce caractère, sauf s'il s'agit
d'un caractère ascii, auquel cas ce premier bit est zéro.
Voilà pour ce que je comprends, et je commencerai en fonction de ce que
j'ai compris. En fait, je vais m'occuper d'abord de projets plus
pressants, de celui-ci ensuite.
C'était annoncé en effet à la fin de mon premier message :
Un petit coup d'oeil ici ?
http://www.usenet-fr.net/fr.usenet.reponses/minis-faqs/crosspost.html
Cordialement,
--
Hervé
Pour la différence entre la page de code Windows-1252 et ISO 8859-1 (sous
ensemble dâUnicode), du détail ici :
http://fr.wikipedia.org/wiki/Windows-1252#Support_en_HTML
La différence nâest pas catastrophique, elle ne concerne qu e des
caractères peut courants. Et de plus, dâaprès les expl ications données sur
la page, il devrait être facile discerner 1252 et 8859-1, par le fa it que
1252 défini les codes 128 à 159 comme représentant des ca ractères, alors
que Unicode défini cet intervalle comme représentant les code de contrôle
C1 (ce sont des codes de contrôle sâajoutant à ceux pl us classique de 0 Ã
31), et que ces codes de contrôle C1 ne devraient normalement pas
apparaitre dans du texte humainement lisible.
Pour savoir ce que sont ces codes de contrôle, voir ici :
http://en.wikipedia.org/wiki/C0_and_C1_control_codes#C1_.28ISO_8859_and_ Unicode.29
⦠quand on voit le genre des codes, sûr que sâils a pparaissent quelque
part, on peut être certain(e) de ne pas avoir à faire à d e lâISO 8859-1.
--
âSyntactic sugar causes cancer of the semi-colons.â [Ep igrams on
Programming â Alan J. â P. Yale University]
âStructured Programming supports the law of the excluded muddle. â [Idem]
âc++; /* this makes c bigger but returns the old value */â [Anonymous]