Problèmes de conversion avec iconv

Bonjour bonsoir,

Mon problème c'est que visiblement certains logiciels considèrent que le code hexadécimal 8D fait partie du jeu de caractères Windows-1252 alors que iconv non. Donc je me retrouve par exemple avec l'impossibilité de convertir des fichiers de utf8 vers windows-1252 avec iconv à cause de caractères de contrôle comme le caractère correspondant à 8D.
Et je me dis que peut-être avec une version plus à jour de iconv je règlerais le problème ou alors en créant une table de conversion pour iconv, mais je ne sais pas trop comment faire.

Je suis sous Debian et comme je ne m'y connais pas trop en Linux je précise que je ne sais même pas si ça a un sens de vouloir ajouter une table de conversion à iconv ou de vouloir le mettre à jour.

Voilà, merci de votre aide.

Salut,

Je ne suis pas un spécialiste de l'encodage de caractères :? mais peut être pourrais-tu jeter un oeil à utrac, qui sait ?

;)

Hello,

Windows-1252 n'utilise pas le caractère 8D, donc si tu as des fichiers encodés en Windows-1252, ils ne devraient pas avoir de 8D. Si tu en as, c'est le logiciel qui créé le fichier d'origine qui est en erreur (et donc pas iconv).

Cela étant, tu peux utiliser tr pour modifier les caractères qui te posent problème avant de passer par iconv. Exemple bidon, j'ai un fichier qui contient AAADD mais je ne veux pas de D et je veux des _ à la place :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

$ cat car.txt AAADD $ od -tx1 car.txt 0000000 41 41 41 44 44 0a 0000006 $ tr '\104' '_' < car.txt > car2.txt $ cat car2.txt AAA__ $ od -tx1 car2.txt 0000000 41 41 41 5f 5f 0a 0000006

---

od -tx1 affiche un fichier en hexa : le A vaut 41 et le D 44
tr permet de transposer les occurrences des D (hex 44 = oct 104) en _

Donc si tu fais un

Code:

---

tr '\215' '_' <ton_fichier>

---

, tu vas virer les caractères qui te gênent...

Citation:

---

Envoyé par zipe31

Salut,
Je ne suis pas un spécialiste de l'encodage de caractères :? mais peut être pourrais-tu jeter un oeil à utrac, qui sait ?
;)

---

Tiens oui c'est pas mal, j'ai facilement accès à la table de conversion avec utrac.
Mais si quelqu'un trouve celle d'iconv je suis toujours preneur. :)

Alek-C, le problème n'est pas de savoir qui a raison mais c'est de savoir si les versions récentes d'iconv résolvent mon problème.
Et la solution de remplacer les caractères ça fonctionne mais c'est juste pas pratique du tout, j'espère une solution qui ne rajoute pas d'opérations.... parce que je suis en droit de l'espérer dans le cas présent. :)

Ben non, ça ne résoudra rien car je doute qu'iconv, même dans une autre version ne respecte pas un encodage aussi basique que Windows-1252...

Le but de mon post n'est pas de dire qui a raison, mais juste de démontrer que ça ne sert à rien de chercher si en entrée tu as un fichier mal encodé :aie:

Bref, si tu ne cherches pas à corriger, tu peux simplement ignorer les caractères qui posent problème avec l'option -c...

Mais ça ne démontre rien non plus et puisque d'autres logiciels gèrent les choses différemment il est tout à fait possible qu'iconv un jour le fasse aussi. La question n'est pas non plus de savoir qui respecte l'encodage ou qui ne le respecte pas.

Et je ne peux pas ignorer les caractères dans mon cas de figure car je perdrais alors de l'information.

Bon, tu poses une question, on te répond, mais si la réponse ne te convient pas, je ne vois pas ce que tu veux de plus ;)

Si je demande à un traducteur anglais/français de traduire ceci : "da haben wir den salat", il ne va pas y arriver car ce n'est pas de l'anglais... ton fichier, c'est pareil : iconv ne convertit pas et ne convertira jamais un fichier encodé en Windows-1252 comportant des caractères 8D car ce caractère n'existe pas dans l'encodage Windows-1252, et donc le fichier ne peut pas être encodé en Windows-1252 :roll:

A partir de ce moment là, soit tu fais avec, soit tu cherches à trouver d'où vient le problème puisque toi, tu es persuadé que cela devrait être du Windows-1252 : peut-être que le programme produisant le fichier est erroné, peut-être que le problème vient du cycle de vie de ton fichier (transfert ftp en ascii plutôt qu'en binaire, utilisation d'un système de compression qui va provoquer ce genre de problème d'encodage à la décompression, etc.)...

Selon que tu trouves ou non l'origine du problème, tu peux tenter de le corriger pour obtenir un fichier correctement encodé.

Si tu ne trouves pas l'origine du problème ou s'il n'est pas possible de le corriger (dans le cas où c'est la source le problème par exemple), il ne te reste plus qu'à faire avec.

Et pour ça, tu peux éventuellement aller chercher les sources de iconv (glibc) et modifier l'encodage cp1252 (je le déconseille) ou créer un nouveau type d'encodage (bon courage) pour gérer ton cas particulier.
Ou tu peux utiliser une des solutions proposées : convertir les caractères par tr ou tu les ignorer par -c (ou utiliser autre chose que iconv).

Citation:

---

iconv ne convertit pas et ne convertira jamais un fichier encodé en Windows-1252 comportant des caractères 8D car ce caractère n'existe pas dans l'encodage Windows-1252, et donc le fichier ne peut pas être encodé en Windows-1252

---

Ca ça n'a juste rien à voir avec le discussion et ça fait juste la 15ème fois que je le dis.
Beyond Compare, Mysql, Notepad++, PHP (avec la fonction mb_convert_encoding() ) et sans doute d'autres gèrent le Windows-1252 et sans doute toutes les extensions de l'ASCII comme des extensions non-ISO de l'ASCII en complétant les "cases" vides avec les caractères de contrôle car ça permet de convertir plus facilement entre elles les extensions de l'ASCII. En gros pour schématiser tout le monde le fait sauf iconv.

Je rajoute aussi que je n'ai jamais dit que 8D appartenait à l'encodage Windows-1252, mais tu as quand même réussi à mettre dans ton message que j'étais persuadé de cela ce qui est assez balèze.

Créer un nouveau type d'encodage ne serait pas plus complexe que de modifier l'encodage cp1252. Si on a accès aux tables de conversion il suffit de faire un copier/coller de cp1252 et de compléter avec les 3-4 caractères de contrôle qui manquent.
Ou voir si une nouvelle version d'iconv l'a déja fait, soit au niveau de cp1252 soit à partir d'un nouvel encodage qui aurait pour but de rendre iconv plus compatible avec les autres logiciels qui existent.
Et si personne ne peut m'informer à ce niveau là alors effectivement une solution rapide est de chercher à utiliser autre chose qu'iconv.
Ce qui nous ramène au 2ème message de ce topic.

les solutions UTRAC et TR qui t'ont été proposées ont-elles permis de résoudre le problème, au lieu de se chambrer dans la joie :D ? :mouarf: :mouarf:

Parce que bon j'ai l'impression que les autres ont compris que tu confondais vouloir une solution, et vouloir la solution avec iconv absolument et rien d'autre... et du coup la discussion devient stérile.

de plus comme chacun sait si il n'y a pas de solutions c'est qu'il n'y a pas de problèmes.

:mouarf:

Pas la peine de t'énerver : j'essaye juste d'aider, et si ça fait 15 fois selon toi que tu répètes la même chose et que personne ne répond, c'est peut être aussi que ça n'est pas très clair comme problème !

Ceci étant, en recoupant ton premier message avec le dernier, je pense que je saisis mieux le problème. Tu dis "certains logiciels considèrent que le code hexadécimal 8D fait partie du jeu de caractères Windows-1252 alors que iconv non". Ce que tu veux dire je suppose, c'est que certains logiciels affichent un symbole à la place d'un caractère qui n'existe pas dans un encodage particulier, un peu comme Word peut afficher les fins de lignes, les espaces, les tabulations, etc.

Le problème selon moi, c'est que tu parles dans ton dernier message de logiciels qui font de l'affichage : iconv fait de la conversion. Les logiciels dont tu parles peuvent remplacer certains caractères inexistants ou de contrôles par un symbole correspondant, mais iconv ne le peut pas pour la simple et bonne raison qu'il n'existe pas de tel caractère dans l'encodage cible.

Je reprends ton exemple (si je l'ai bien compris cette fois-ci) : tu as un fichier encodé en UTF8 et tu souhaites le convertir en Windows-1252, mais ce fichier comporte un caractère 8D ? Alors déjà, ne le prend pas mal, mais je ne crois pas que "8D" soit un caractère valide en UTF8 ;)

Si j'ai un fichier qui comporte ceci :

Code:

---

1 2	Offset 00 01 02 000000 8D A1 A1

---

Ca ne correspond à rien en UTF8, et Notepad++ affichera un truc du genre [x8D]AA alors que Word affiche : AA

Mais si j'ai ceci :

Code:

---

1 2	Offset 00 01 02 03 04 000000 EF A4 8D A1 A1

---

Alors ça correspond à ce texte dans Word : 懶AA
Mais le premier symbole est encodé avec le groupe EF A4 8D, pas uniquement 8D

Bref, ça c'est le premier point, mais même en partant du principe que ton fichier est correctement encodé, ma question est "que voudrais-tu que iconv te retourne si tu lui passes un fichier encodé en UTF8 dont le contenu en hexa donne : EFA48DA1A1 ?" ?

Car quoi que tu en penses, on en revient toujours au même point : que tu partes du Windows-1252 vers l'UTF8 ou l'inverse, si à un moment, un caractère donné n'existe pas dans un encodage, ça va poser problème...

Certes, certains logiciels vont t'afficher quelque chose, mais ça ne sera pas un caractère de ton jeu d'encodage, donc une conversion complète est impossible.

Donc ce que je te propose, c'est de donner un exemple concret de ce que tu veux obtenir et à partir de quoi tu veux l'obtenir (en utilisant od -tx1 par exemple sur ton fichier d'entrée)...

Soit dit en passant, je ne sais pas si tu as regardé les sources des table d'encodage de iconv, mais ça n'est pas ultra basique contrairement à ce que tu sembles penser (j'ai regardé, preuve que je m'intéresse à ton problème et que je ne suis pas là par plaisir...).

Pour finir, le mot persuadé de mon post n'était pas à prendre négativement : comme je partais du principe que tu avais un fichier encodé en Windows-1252 en entrée, je partais également du principe que ce fichier était fourni par un logiciel qui indiquait explicitement que c'était l'encodage utilisé pour le fichier... d'où le fait que tu en sois persuadé même si le logiciel se gourre... mais passons sur ce point hors sujet : encore une fois, je suis là pour essayer d'aider, pas pour me faire taper dessus parce que j'ai mal compris un problème ou que ma réponse ne plait pas...