je développe un petit script qui doit récupérer le nom de l'expéditeur
d'un mail (du champ From:).
Mon gros souci vient des lignes du genre :
From: ?=ISO8859-1?Q?Fran=E7ois=?
Avec une expression régulière, je récupère correctement l'encodage en
$1, le mode utilisé (base64 B ou quoted printable Q) en $2 et le texte
lui-même en $3.
En gros, il faut transformer la chaîne $3 en caractères (split //, $3),
puis parcourir le tableau à la recherche d'un =, si on en trouve un,
agglomérer les deux caractères suivants et regarder si =~
/[0-9A-Fa-f][0-9A-Fa-f]?/ et le cas échéant faire un oct pour récupérer
le caractère sous forme d'un octet.
Maintenant, mon problème est le suivant : comment faire pour réinjecter
cet octet dans le tableau de caractères de sortie (en gros, je veux
rentrer dans ce tableau de chaînes de caractère une chaîne d'une lettre,
cette lettre étant représentée par l'octet trucmuche) ?
push @sortie, chr oct (truc); ne fonctionne pas car je suis en encodage
utf8. push @sortie, Encode::decode ($1, chr oct (truc)) ne fonctionne
évidemment pas plus puisque chr ne retourne rien de valable.
Ben si, ça me sert d'exercice pour me perfectionner, précisément !
Il semble que ta capacité à tirer partie du CPAN nécessite d'être perfectionée ;-)
Certainement. D'autant que, utilisant NetBSD, je suis obligé de passer par le système pkgsrc ce qui complique un peu plus les choses.
V.
Vincent
je ne vois pas pourquoi NetBSD interdirait l'utilisation de la commande 'cpan' et de tout ce qui va bien...
On peut l'utiliser, mais c'est mieux de faire avec pkgsrc, parce que les dépendances installées sont globales. Je m'explique : si je charge le module MIME avec cpan, et qu'ensuite j'installe un utilitaire à partir de pkgsrc qui utilise aussi MIME, ce dernier va être une nouvelle fois recompilé, parce que la base de données qui gère pkgsrc n'est pas la même que celle qui gère CPAN, et que l'un ne connaît pas les paquets installés par l'autre, et lycée de Versailles.
V.
PS : Il doit quand même être possible d'ajouter un octet précis à une chaîne de caractère autrement que par
$ligne .= chr $truc;
non ?
V.
je ne vois pas pourquoi NetBSD interdirait l'utilisation de la
commande 'cpan' et de tout ce qui va bien...
On peut l'utiliser, mais c'est mieux de faire avec pkgsrc, parce que les
dépendances installées sont globales. Je m'explique : si je charge le
module MIME avec cpan, et qu'ensuite j'installe un utilitaire à partir
de pkgsrc qui utilise aussi MIME, ce dernier va être une nouvelle fois
recompilé, parce que la base de données qui gère pkgsrc n'est pas la
même que celle qui gère CPAN, et que l'un ne connaît pas les paquets
installés par l'autre, et lycée de Versailles.
V.
PS : Il doit quand même être possible d'ajouter un octet précis à une
chaîne de caractère autrement que par
je ne vois pas pourquoi NetBSD interdirait l'utilisation de la commande 'cpan' et de tout ce qui va bien...
On peut l'utiliser, mais c'est mieux de faire avec pkgsrc, parce que les dépendances installées sont globales. Je m'explique : si je charge le module MIME avec cpan, et qu'ensuite j'installe un utilitaire à partir de pkgsrc qui utilise aussi MIME, ce dernier va être une nouvelle fois recompilé, parce que la base de données qui gère pkgsrc n'est pas la même que celle qui gère CPAN, et que l'un ne connaît pas les paquets installés par l'autre, et lycée de Versailles.
V.
PS : Il doit quand même être possible d'ajouter un octet précis à une chaîne de caractère autrement que par
$ligne .= chr $truc;
non ?
V.
Paul Gaborit
À (at) Wed, 28 May 2008 16:37:38 +0200, Vincent écrivait (wrote):
PS : Il doit quand même être possible d'ajouter un octet précis à une chaîne de caractère autrement que par
$ligne .= chr $truc;
non ?
Il faut lire :
perldoc -f pack perldoc -f chr (en particulier pour les valeurs entre 128 et 255) perldoc Encode (en particulier la différence entre 'from_to' et 'decode')
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 28 May 2008 16:37:38 +0200,
Vincent <10.50@free.fr> écrivait (wrote):
PS : Il doit quand même être possible d'ajouter un octet précis à une
chaîne de caractère autrement que par
$ligne .= chr $truc;
non ?
Il faut lire :
perldoc -f pack
perldoc -f chr
(en particulier pour les valeurs entre 128 et 255)
perldoc Encode
(en particulier la différence entre 'from_to' et 'decode')
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Wed, 28 May 2008 16:37:38 +0200, Vincent écrivait (wrote):
PS : Il doit quand même être possible d'ajouter un octet précis à une chaîne de caractère autrement que par
$ligne .= chr $truc;
non ?
Il faut lire :
perldoc -f pack perldoc -f chr (en particulier pour les valeurs entre 128 et 255) perldoc Encode (en particulier la différence entre 'from_to' et 'decode')
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
espie
In article <483d6e32$0$26597$, Vincent wrote:
je ne vois pas pourquoi NetBSD interdirait l'utilisation de la commande 'cpan' et de tout ce qui va bien...
Ca peut etre effectivement complexe a faire coexister.
Chez les voisins (Open), j'ai dans les plans a moyen terme d'unifier un peu plus ca. Deja, on a aux 3/4 automatise la creation d'un port d'un module CPAN, et on doit avoir plus de 500 packages en rapport avec CPAN. Autant dire une enorme partie des trucs utiles.
In article <483d6e32$0$26597$426a74cc@news.free.fr>,
Vincent <10.50@free.fr> wrote:
je ne vois pas pourquoi NetBSD interdirait l'utilisation de la
commande 'cpan' et de tout ce qui va bien...
Ca peut etre effectivement complexe a faire coexister.
Chez les voisins (Open), j'ai dans les plans a moyen terme d'unifier un
peu plus ca. Deja, on a aux 3/4 automatise la creation d'un port d'un
module CPAN, et on doit avoir plus de 500 packages en rapport avec CPAN.
Autant dire une enorme partie des trucs utiles.
Ca peut etre effectivement complexe a faire coexister.
Chez les voisins (Open), j'ai dans les plans a moyen terme d'unifier un peu plus ca. Deja, on a aux 3/4 automatise la creation d'un port d'un module CPAN, et on doit avoir plus de 500 packages en rapport avec CPAN. Autant dire une enorme partie des trucs utiles.
Thierry B.
--{ Vincent a plopé ceci: }--
Il semble que ta capacité à tirer partie du CPAN nécessite d'être perfectionée ;-)
Certainement. D'autant que, utilisant NetBSD, je suis obligé de passer par le système pkgsrc ce qui complique un peu plus les choses.
Aie, pourrais-tu donner un peu plus d'explications avant que je ne pulvérise ma ss20 par l'usage abusif de cpan ? Des dépendances de l'OS incompatibles ?
-- No sig available for this very specific troll.
--{ Vincent a plopé ceci: }--
Il semble que ta capacité à tirer partie du CPAN nécessite d'être
perfectionée ;-)
Certainement. D'autant que, utilisant NetBSD, je suis obligé de passer
par le système pkgsrc ce qui complique un peu plus les choses.
Aie, pourrais-tu donner un peu plus d'explications avant que
je ne pulvérise ma ss20 par l'usage abusif de cpan ? Des
dépendances de l'OS incompatibles ?
Il semble que ta capacité à tirer partie du CPAN nécessite d'être perfectionée ;-)
Certainement. D'autant que, utilisant NetBSD, je suis obligé de passer par le système pkgsrc ce qui complique un peu plus les choses.
Aie, pourrais-tu donner un peu plus d'explications avant que je ne pulvérise ma ss20 par l'usage abusif de cpan ? Des dépendances de l'OS incompatibles ?
-- No sig available for this very specific troll.
Vincent
perldoc Encode (en particulier la différence entre 'from_to' et 'decode')
Merci ! Je n'avais pas vu la fonction 'from_to', qui est exactement ce que je désirais.
Maintenant, ça fonctionne.
Merci infiniment.
Vincent
perldoc Encode
(en particulier la différence entre 'from_to' et 'decode')
Merci ! Je n'avais pas vu la fonction 'from_to', qui est exactement ce
que je désirais.
