Forum Linux.général Conversion encodage d'un fichier

Posté par .
Tags : aucun
3
2
sept.
2012

J'ai un fichier où les accents déconnent :
« é » donne « Ã© »
« à » donne « Ã »
« ç » donne « Ã§ »
etc

Si mes souvenirs sont bons, c'est le symptôme d'un fichier en iso-8859-15 qui est affiché en utf8. Donc j'essaye « :set fileencoding=iso-8859-15 » dans vim. Ah, erreur de conversion. Zut.

Quand je suis passé en utf8, j'ai utilisé utrac pour convertir mes fichiers importants. Donc je tente
utrac -f UTF-8 -t ISO-8859-15 fichier >essai

Ça semble déjà mieux qu'avec vim :
utrac -i essai
Charset (unsure): ISO-8859-11

Si je fais « most essai » les accents sont corrects. Par contre si je l'ouvre avec vim j'ai de nouveau des accents massacrés :/

Quelqu'un aurait une solution pour convertir un fichier vers l'utf8 de manière simple et efficace ?

  • # set encoding=utf-8

    Posté par . Évalué à 4.

    je peux me tromper, mais je pense que c'est ton vim qui considère que ces fichiers ne sont pas en utf-8

    • [^] # Re: set encoding=utf-8

      Posté par . Évalué à 1.

      J'ai cette commande dans mon vimrc. Si je la retape une fois le fichier ouvert et fais :x ça ne change rien.

  • # file fichier

    Posté par (page perso) . Évalué à 5.

    Si mes souvenirs sont bons, c'est le symptôme d'un fichier en iso-8859-15 qui est affiché en utf8.

    c'est plutôt l'inverse de l'UTF-8 qui est lu comme de l'ISO-8859.

    • [^] # Re: file fichier

      Posté par (page perso) . Évalué à 3.

      Pour avoir eu le cas, ça peut-être aussi de l'<> c'est à dire de l'utf-8, vu comme de l'iso-8859 et re-enregistré sous forme UTF-8.

      Tu te retrouve avec 4 octets pour un accent, c'est "tres rigolo".

      "hexdump -C" ou le viewer hexa de midnight commander sont bien pratique pour comprendre ce genre de blague, et être certain de l'encodage d'un fichier.

      • [^] # Re: file fichier

        Posté par . Évalué à 1.

        Apparemment c'est bien de l'UTF-8 affiché comme de l'iso-latin-1 ou 15. Mais les outils sensés faire la traduction se cassent les dents dessus… (voir mon commentaire plus complet ci-dessous).

  • # recode, iconv

    Posté par (page perso) . Évalué à 5.

    recode iso8859-15..utf8 fichier
    ou
    iconv -t utf8 -f iso8859-15 fichier

    • [^] # Re: recode, iconv

      Posté par (page perso) . Évalué à 3.

      Surtout pas. C'est le contraire.

      • [^] # Résultat de mes tests

        Posté par . Évalué à 1.

        Si je lance un
        % iconv -f utf8 -t iso8859-15 fichier.sql >essai
        iconv: séquence d'échappement non permise à la position 3220

        la sortie sur terminal donne
        [le début du fichier converti avec les bons accents]
        […]si tu veux avoir la trois�iconv: séquence d'échappement non permise à la position 3220

        Si j'essaye un
        % utrac -f UTF-8 -t ISO-8859-15 fichier.sql >essai
        je n'ai pas d'erreur, mais les accents ne sont pas OK dans vim. Dans most la plupart semblent bons, sauf è et ô qui sont remplacés par « <C3>_ ». Si je l'ouvre dans kedit et que je l'enregistre, vim voit les accents correctement dans le nouveau fichier, sauf è et ô. Mais si j'essaye %s/<C3>/è/g je me retrouve avec des mots comme cèté (ô remplacé par è), puisque c'est le même caractère.

        Si j'essaye avec iconv -c j'ai le même problème : accents OK mais è et ô remplacés par « <C3> » (sans l'underscore rajouté par utrac).

        D'après le man :
        Lorsque la chaîne « //TRANSLIT » est ajoutée à --to-code, la translitération est activée. Cela signifie que lorsqu'un caractère ne peut pas être représenté dans l'encodage cible, il pourra être approximé par un caractère de forme similaire.

        La seule différence c'est un ? après <C3>.

        J'ai aussi essayé avec recode :
        % recode utf8..iso8859-15 fichier.sql recode: linux-fr.sql non-réussi: Entrée invalide dans « UTF-8..ISO-8859-15 »

        Le man de recode ne me donne pas de pistes pour approfondir. J'ai googlé l'erreur d'iconv, pas plus.

        Le fichier fait 140K, je me vois pas changer les caractères un par un. Au pire, s'il n'y a pas d'autre solution, je pourrais toujours partir de la sortie d'utrac, chercher une liste des mots contenant ô et corriger à coup de :%s/motavecè/motavecô/g. Mais bon…

        • [^] # Re: Résultat de mes tests

          Posté par . Évalué à 2.

          Le fichier est vraisemblablement corrompu, ou plusieurs fichiers avec un encoding différent ont été concaténés. Dans le premier cas, tu modifies le caractère fautif à la main avec un éditeur ascii/hex. Dans le second tu découpes le fichier avant chaque erreur et tu convertis chaque partie indépendamment.

          Tu peux uploader le fichier qq part sur le net? Ça m'intéresserait de voir quel type de problème est arrivé.

          • [^] # Re: Résultat de mes tests

            Posté par . Évalué à 1.

            C'était ça, le fichier était corrompu. Un ami m'a aidé à déterminer qu'il avait subi une double conversion latin1 -> utf8.

            J'ai donc fais iconv -c -f utf8 -t iso8859-15 dessus, puis j'ai corrigé les è/ô qui posaient problème.

            Merci de ton attention, c'est sympa :)

  • # Le contraire

    Posté par (page perso) . Évalué à 3.

    Ça, c'est un fichier codé en UTF-8 et décodé comme si c'était du latin-1 ou du latin-9. Pas l'inverse.

  • # Merci

    Posté par . Évalué à 1.

    Merci à tous pour vos réponses, j'essayerai ça demain.

    Ces histoires de convertion d'encodage, ça m'a toujours pris la tête.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.