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é
Poser une question
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é