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é
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Xavier Roche
Le #23429141
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.
Yannick Duchêne (Hibou57)
Le #23430461
Bonjour,

Le Mon, 06 Jun 2011 18:04:38 +0200, Herve Autret écrit:
Avant de me pencher sur le code de la libiconv, pour voir si l'ajout d e
l'option "verbatim" est réalisable sans y passer trop de temps,
j'aimerais savoir si quelqu'un connaît une solution pratique au p roblème
du mélange d'encodages ?


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]
Yannick Duchêne (Hibou57)
Le #23430451
Bonjour,

Le Mon, 06 Jun 2011 18:04:38 +0200, Herve Autret écrit:
Avant de me pencher sur le code de la libiconv, pour voir si l'ajout d e
l'option "verbatim" est réalisable sans y passer trop de temps,
j'aimerais savoir si quelqu'un connaît une solution pratique au p roblème
du mélange d'encodages ?


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]
Herve Autret
Le #23431511
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é
Herve Autret
Le #23431501
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é
Yannick Duchêne (Hibou57)
Le #23431591
Le Tue, 07 Jun 2011 11:19:16 +0200, Herve Autret écrit:

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éde nt 0xxxxxxx



Non, ça c'est justement un ASCII ;-).



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]
Yannick Duchêne (Hibou57)
Le #23431721
Le Mon, 06 Jun 2011 20:05:45 +0200, Xavier Roche
Expérimentalement, je n'ai jamais rencontré de cas où e xisterait une
ambigüité (càd. plusieurs caractères Latin-1 qui s erait pris pour un
caractère UTF-8) ; le standard UTF-8 est là encore remarquab lement bien
foutu.


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]
Yannick Duchêne (Hibou57)
Le #23431711
Le Tue, 07 Jun 2011 11:58:39 +0200, Yannick Duchêne (Hibou57)

Le Mon, 06 Jun 2011 20:05:45 +0200, Xavier Roche
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 remarqua blement bien
foutu.


Seulement à la lecture aux yeux d’un être humain, pa rce qu’à part ça,
l’ambiguïté est totale aux yeux d’un program me 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 recomma ndée.



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]
Herve Autret
Le #23432091
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 :

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.

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é
Yannick Duchêne (Hibou57)
Le #23445641
Le Mon, 06 Jun 2011 20:05:45 +0200, Xavier Roche
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 s ur
le Web, mais ce n'est peut être pas utile dans votre cas)



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]
Publicité
Poster une réponse
Anonyme