Forum Programmation.shell conversion d'un charset à l'autre

Posté par (page perso) .
Tags : aucun
1
29
sept.
2010
Bonjour les gens,

Je viens juste de terminer une installation d'un serveur LDAP sur mon serveur pour me faire un carnet d'adresses personnel centralisé.
Thunderbird ne gérant pas de façon native l'écriture dans un LDAP, j'ai pallié ce manque par un petit script qui va scruter les mails au format Maildir, extrait la ligne "^From: " du fichier, découpe tout ca et le balance à manger à ldapadd au format ldif. Jusqu'ici tout va bien. Le seul problème c'est les expéditeurs dont le nom est codé avec un charset spécifié et que le pauvre grep ne le voit pas comme ca lui.

Les lignes incriminées sont de la forme

From: =?iso-8859-1?B?sldfjeofjd9786hjèJKBHjkgfkIU=?= <moi@plop.plop>

ou encore

From: =?utf-8?B?sldfjeofjd9786hjèJKBHjkgfkIU=?= <moi@plop.plop>


et grep me le renvoie tel quel, donc je me retrouve avec des entrées dans mon annuaire qui ressemblent à rien.

Je voudrais savoir s'il y a moyen de convertir ca en mots "lisibles" par un cerveau non utf-8 compliant ?

J'ai regardé du coté de iconv sans succès... Quelqu'un a-t-il une solution ?
  • # RFC2047

    Posté par . Évalué à 5.

    Je viens de voir que c'est l'encodage normalisé par la RFC 2047. Je m'étais toujours dit que ce genre de truc devait venir de quelque part, et tu m'as fait chercher…
    En passant, un petit post intéressant dessus (avec code python idoine) : http://www.bortzmeyer.org/2047.html
    • [^] # Re: RFC2047

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

      OK, très bien tu m'a mis sur la bonne voie !

      J'ai trouvé mon bonheur à cette adresse là: http://www.linuxquestions.org/questions/linux-software-2/con(...) et j'ai juste rajouté le script filter.pl de la fin qui a résolu comme un charme mon souci, maintenant je fais le grep comme ca :

      FROM=`grep ^From: $1| ./filter.pl | iconv -f ISO-8859-1 -t UTF-8`

      et ca me renvoie la bonne chaine, fini les entrées toutes moches, à moi un annuaire LDAP propre !

      Merci pour ton aide
      • [^] # Re: RFC2047

        Posté par . Évalué à 3.

        De rien.

        Si tu veux utiliser une lib toute prête plutôt que de réinventer la roue, en Perl, j'ai vu ça sur le CPAN : http://search.cpan.org/~markov/Mail-Box-2.095/lib/Mail/Messa(...)
        (je ne sais pas comment l'utiliser, je ne fais pas de perl, mais ça a l'air de supporter la RFC dont on parle)
        • [^] # Re: RFC2047

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

          Ben j'ai préféré faire un truc rapide dans un environnement que je connais plutôt que me plonger dans un langage inconnu (je ne connais ni perl ni python encore). Donc je me suis fait une solution maison avec un petit programme en C qui parse et découpe proprement la ligne "From: " du mail et renvoie une entrée ldif prévue pour mon annuaire, ce programme est appelé par un script shell qui prend un nom de fichier en argument, il récupère à coup de grep la ligne From:, la convertit en utf-8 au besoin (cf mon problème), puis la passe au programme C, je renvoie la sortie du programme C dans ldapadd et puis voilà, j'ai plus qu'à mettre ca dans un cron pour lancer ce script régulièrement avec les nouveaux mails reçus.

          C'est pas très propre mais ca marche, je l'optimiserai lorsque j'aurai 5 minutes
          • [^] # Re: RFC2047

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

            "C'est pas très propre mais ca marche, je l'optimiserai lorsque j'aurai 5 minutes "

            c'est à dire... jamais ou quand il y aura un bug ! :o)

            Fuse : j'en Use et Abuse !

  • # Thunderbird Write LDAP

    Posté par . Évalué à 3.

    Thunderbird ne gérant pas de façon native l'écriture dans un LDAP

    Si si. Un très léger patch de 2 lignes et ça marche, plus qu'à recompiler. Thunderbird peut écrire dans un annuaire LDAP mais c'a n'est pas activé par défaut car soit disant pas stable.. Pourtant je l'utilise depuis un moment (seule la photo n'est pas prise en charge).

Suivre le flux des commentaires

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