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é
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Xavier Roche
Le 06/06/2011 18:04, Herve Autret a écrit :
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 ?
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 06/06/2011 18:04, Herve Autret a écrit :
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 ?
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.
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 ?
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.
-- â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]
--
â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]
-- â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]
-- â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]
--
â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]
-- â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]
Herve Autret
Bonjour
Le Mon, 06 Jun 2011 20:05:45 +0200, Xavier Roche a écrit:
cela vaut presque le coup de réécrire 50 lignes de C pour ça,
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.
plutôt que d'essayer de patcher une fonctionnalité exotique amha.
De plus, la pérennité du truc n'est pas garantie de cette manière... -- Hervé
Bonjour
Le Mon, 06 Jun 2011 20:05:45 +0200, Xavier Roche a écrit:
cela vaut presque le coup de réécrire 50 lignes de C pour ça,
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.
plutôt que d'essayer de patcher une fonctionnalité exotique amha.
De plus, la pérennité du truc n'est pas garantie de cette manière...
--
Hervé
Le Mon, 06 Jun 2011 20:05:45 +0200, Xavier Roche a écrit:
cela vaut presque le coup de réécrire 50 lignes de C pour ça,
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.
plutôt que d'essayer de patcher une fonctionnalité exotique amha.
De plus, la pérennité du truc n'est pas garantie de cette manière... -- Hervé
Herve Autret
Bonjour,
Le Tue, 07 Jun 2011 06:41:09 +0200, Yannick Duchêne (Hibou57) a écrit:
(le début du caractère se trouve alors au précédent 0xxxxxxx
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é
Bonjour,
Le Tue, 07 Jun 2011 06:41:09 +0200, Yannick Duchêne (Hibou57) a écrit:
(le début du caractère se trouve alors au précédent 0xxxxxxx
Non, ça c'est justement un ASCII ;-). Mais le principe me plaît, comme je
disais à Xavier : je vais faire un truc comme ça.
-- â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]
--
â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]
-- â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]
-- â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]
--
â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]
-- â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]
-- â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]
--
â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]
-- â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]
Herve Autret
Bonjour
Le Tue, 07 Jun 2011 11:52:17 +0200, Yannick Duchêne (Hibou57) a écrit:
(le début du caractère se trouve alors au précédent 0xxxxxxx
Non, ça c'est justement un ASCII ;-).
Sauf s’il est suivi d’un 10xxxxxx : je parlais bien de retrouver un 0xxxxxxx en remontant en arrière après avoir rencontré un 10xxxxxx… la nuance est importante.
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 :
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.
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.divers” auquel je n’étais pas abonné (m’enfin, pas grave, maintenant je m’y suis abonné)
C'était annoncé en effet à la fin de mon premier message :
[Xpost f.c.divers, f.c.application.libre, f.c.normes.unicode, Suivi proposé sur sur f.c.divers]
Un petit coup d'oeil ici ? http://www.usenet-fr.net/fr.usenet.reponses/minis-faqs/crosspost.html
Cordialement, -- Hervé
Bonjour
Le Tue, 07 Jun 2011 11:52:17 +0200, Yannick Duchêne (Hibou57) a écrit:
(le début du caractère se trouve alors au précédent 0xxxxxxx
Non, ça c'est justement un ASCII ;-).
Sauf s’il est suivi d’un 10xxxxxx : je parlais bien de retrouver un
0xxxxxxx en remontant en arrière après avoir rencontré un 10xxxxxx…
la nuance est importante.
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 :
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.
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.divers”
auquel je n’étais pas abonné (m’enfin, pas grave, maintenant je m’y
suis abonné)
C'était annoncé en effet à la fin de mon premier message :
[Xpost f.c.divers, f.c.application.libre, f.c.normes.unicode,
Suivi proposé sur sur f.c.divers]
Un petit coup d'oeil ici ?
http://www.usenet-fr.net/fr.usenet.reponses/minis-faqs/crosspost.html
Le Tue, 07 Jun 2011 11:52:17 +0200, Yannick Duchêne (Hibou57) a écrit:
(le début du caractère se trouve alors au précédent 0xxxxxxx
Non, ça c'est justement un ASCII ;-).
Sauf s’il est suivi d’un 10xxxxxx : je parlais bien de retrouver un 0xxxxxxx en remontant en arrière après avoir rencontré un 10xxxxxx… la nuance est importante.
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 :
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.
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.divers” auquel je n’étais pas abonné (m’enfin, pas grave, maintenant je m’y suis abonné)
C'était annoncé en effet à la fin de mon premier message :
[Xpost f.c.divers, f.c.application.libre, f.c.normes.unicode, Suivi proposé sur sur f.c.divers]
Un petit coup d'oeil ici ? http://www.usenet-fr.net/fr.usenet.reponses/minis-faqs/crosspost.html
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]
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]
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]
