Je cherche une moyen simple pour encoder des mails en autre chose que du
7 bits, avec surtout le sujet encodé également. MIME::Lite ne semble
malheureusement ne pas vouloir le faire.
J'aimerai un module pure perl ou une méthode plus "à la main", je n'ai
pas la possibilté d'installer les modules que je souhaite.
Je cherche une moyen simple pour encoder des mails en autre chose que du 7 bits, avec surtout le sujet encodé également. MIME::Lite ne semble malheureusement ne pas vouloir le faire.
J'aimerai un module pure perl ou une méthode plus "à la main", je n'ai pas la possibilté d'installer les modules que je souhaite.
MIME::Base64 te permet d'encoder en ... base64 . MIME::Tools qui te permet "tout".
tu as un article fait par les mongueurs de perl, dans un linux mag recent, si je ne m'abuse ...
Merci d'avance
Padkoa,
.s'nuoM
Bonjour,
Bonjour
Je cherche une moyen simple pour encoder des mails en autre chose que du
7 bits, avec surtout le sujet encodé également. MIME::Lite ne semble
malheureusement ne pas vouloir le faire.
J'aimerai un module pure perl ou une méthode plus "à la main", je n'ai
pas la possibilté d'installer les modules que je souhaite.
MIME::Base64 te permet d'encoder en ... base64 .
MIME::Tools qui te permet "tout".
tu as un article fait par les mongueurs de perl, dans un linux mag
recent, si je ne m'abuse ...
Je cherche une moyen simple pour encoder des mails en autre chose que du 7 bits, avec surtout le sujet encodé également. MIME::Lite ne semble malheureusement ne pas vouloir le faire.
J'aimerai un module pure perl ou une méthode plus "à la main", je n'ai pas la possibilté d'installer les modules que je souhaite.
MIME::Base64 te permet d'encoder en ... base64 . MIME::Tools qui te permet "tout".
tu as un article fait par les mongueurs de perl, dans un linux mag recent, si je ne m'abuse ...
Merci d'avance
Padkoa,
.s'nuoM
Aurelien
Bonjour
J'ai fait pas mal de recherche du côté de l'article des Mongueurs mais surtout sur le module MIME::Tools. Il a l'air assez complet, mais après tests, il semble qu'il ne veut pas encoder le header Subject. La RFC ne semble pas en parler, mais pourtant certains MUA le font (enfin, ceux que j'ai testé), et j'ai déjà vu des filtres anti-spam et cie se plaindre si ce n'est pas fait....
Vous me conseillez de faire la conversion du sujet, avant, à la main ?
Aurélien
Bonjour,
Bonjour
Je cherche une moyen simple pour encoder des mails en autre chose que du 7 bits, avec surtout le sujet encodé également. MIME::Lite ne semble malheureusement ne pas vouloir le faire.
J'aimerai un module pure perl ou une méthode plus "à la main", je n'ai pas la possibilté d'installer les modules que je souhaite.
MIME::Base64 te permet d'encoder en ... base64 . MIME::Tools qui te permet "tout".
tu as un article fait par les mongueurs de perl, dans un linux mag recent, si je ne m'abuse ...
Merci d'avance
Padkoa,
.s'nuoM
Bonjour
J'ai fait pas mal de recherche du côté de l'article des Mongueurs mais
surtout sur le module MIME::Tools.
Il a l'air assez complet, mais après tests, il semble qu'il ne veut pas
encoder le header Subject. La RFC ne semble pas en parler, mais pourtant
certains MUA le font (enfin, ceux que j'ai testé), et j'ai déjà vu des
filtres anti-spam et cie se plaindre si ce n'est pas fait....
Vous me conseillez de faire la conversion du sujet, avant, à la main ?
Aurélien
Bonjour,
Bonjour
Je cherche une moyen simple pour encoder des mails en autre chose que
du 7 bits, avec surtout le sujet encodé également. MIME::Lite ne
semble malheureusement ne pas vouloir le faire.
J'aimerai un module pure perl ou une méthode plus "à la main", je n'ai
pas la possibilté d'installer les modules que je souhaite.
MIME::Base64 te permet d'encoder en ... base64 .
MIME::Tools qui te permet "tout".
tu as un article fait par les mongueurs de perl, dans un linux mag
recent, si je ne m'abuse ...
J'ai fait pas mal de recherche du côté de l'article des Mongueurs mais surtout sur le module MIME::Tools. Il a l'air assez complet, mais après tests, il semble qu'il ne veut pas encoder le header Subject. La RFC ne semble pas en parler, mais pourtant certains MUA le font (enfin, ceux que j'ai testé), et j'ai déjà vu des filtres anti-spam et cie se plaindre si ce n'est pas fait....
Vous me conseillez de faire la conversion du sujet, avant, à la main ?
Aurélien
Bonjour,
Bonjour
Je cherche une moyen simple pour encoder des mails en autre chose que du 7 bits, avec surtout le sujet encodé également. MIME::Lite ne semble malheureusement ne pas vouloir le faire.
J'aimerai un module pure perl ou une méthode plus "à la main", je n'ai pas la possibilté d'installer les modules que je souhaite.
MIME::Base64 te permet d'encoder en ... base64 . MIME::Tools qui te permet "tout".
tu as un article fait par les mongueurs de perl, dans un linux mag recent, si je ne m'abuse ...
Merci d'avance
Padkoa,
.s'nuoM
Denis Joiret
Bonjour,
Il est toujours possible d'installer les modules ailleurs que dans l'endroit standard. Il suffit de mettre quelques option sur la ligne "perl Makefile.PL". Exemple : perl Makefile.PL INSTALLDIRS=perl PREFIX=$HOME cela installe le module dans $HOME/lib/perl5/... Il suffit ensuite de positionner la variable d'environnement PERL5LIB en ajoutant le chemin $HOME/LIB/perl5 pour qu'on puisse accéder sans problème au module depuis n'importe quel script. On peut aussi mettre une ligne use lib "$ENV{HOME}/lib/perl5" dans les scripts appelant les modules privés.
Denis
"Aurelien" a écrit dans le message de news:409bfc91$0$8635$
Bonjour
Je cherche une moyen simple pour encoder des mails en autre chose que du 7 bits, avec surtout le sujet encodé également. MIME::Lite ne semble malheureusement ne pas vouloir le faire.
J'aimerai un module pure perl ou une méthode plus "à la main", je n'ai pas la possibilté d'installer les modules que je souhaite.
Merci d'avance
Aurélien
Bonjour,
Il est toujours possible d'installer les modules ailleurs que dans l'endroit
standard. Il suffit de mettre quelques option sur la ligne "perl
Makefile.PL". Exemple :
perl Makefile.PL INSTALLDIRS=perl PREFIX=$HOME
cela installe le module dans $HOME/lib/perl5/...
Il suffit ensuite de positionner la variable d'environnement PERL5LIB en
ajoutant le chemin $HOME/LIB/perl5 pour qu'on puisse accéder sans problème
au module depuis n'importe quel script. On peut aussi mettre une ligne
use lib "$ENV{HOME}/lib/perl5"
dans les scripts appelant les modules privés.
Denis
"Aurelien" <spam@lelfe.net> a écrit dans le message de
news:409bfc91$0$8635$626a14ce@news.free.fr...
Bonjour
Je cherche une moyen simple pour encoder des mails en autre chose que du
7 bits, avec surtout le sujet encodé également. MIME::Lite ne semble
malheureusement ne pas vouloir le faire.
J'aimerai un module pure perl ou une méthode plus "à la main", je n'ai
pas la possibilté d'installer les modules que je souhaite.
Il est toujours possible d'installer les modules ailleurs que dans l'endroit standard. Il suffit de mettre quelques option sur la ligne "perl Makefile.PL". Exemple : perl Makefile.PL INSTALLDIRS=perl PREFIX=$HOME cela installe le module dans $HOME/lib/perl5/... Il suffit ensuite de positionner la variable d'environnement PERL5LIB en ajoutant le chemin $HOME/LIB/perl5 pour qu'on puisse accéder sans problème au module depuis n'importe quel script. On peut aussi mettre une ligne use lib "$ENV{HOME}/lib/perl5" dans les scripts appelant les modules privés.
Denis
"Aurelien" a écrit dans le message de news:409bfc91$0$8635$
Bonjour
Je cherche une moyen simple pour encoder des mails en autre chose que du 7 bits, avec surtout le sujet encodé également. MIME::Lite ne semble malheureusement ne pas vouloir le faire.
J'aimerai un module pure perl ou une méthode plus "à la main", je n'ai pas la possibilté d'installer les modules que je souhaite.
Merci d'avance
Aurélien
Paul GABORIT
À (at) Fri, 07 May 2004 23:10:28 +0200, Aurelien écrivait (wrote):
Je cherche une moyen simple pour encoder des mails en autre chose que du 7 bits, avec surtout le sujet encodé également. MIME::Lite ne semble malheureusement ne pas vouloir le faire.
MIME::Lite permet pourtant de la faire (au moins pour le corps). Un extrait du début de la doc de MIME::Lite :
Create a single-part message:
### Create a new single-part message, to send a GIF file: $msg = MIME::Lite->new( From =>'', To =>'', Cc =>', ', Subject =>'Helloooooo, nurse!', Type =>'image/gif', Encoding =>'base64', Path =>'hellonurse.gif' );
'Encoding' me semble assez clair. Puis plus loin :
You don't need to worry about encoding your message data: this module will do that for you. It handles the 5 standard MIME encodings.
Le 5 types gérés sont '7bit', '8bit', 'binary', 'base64' et 'quoted-printable'.
Reste le problème du sujet lui-même (sachant que quelle que soit la méthode choisie, il reste encore beaucoup de lecteurs de mail qui ne savent pas décoder les en-têtes). Je n'ai pas testé MIME::Lite pour savoir comment il traite les en-têtes non 7bit.
If you need more sophisticated behavior, please get the MIME-tools package instead. I will be more likely to add stuff to that toolkit over this one.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Fri, 07 May 2004 23:10:28 +0200,
Aurelien <spam@lelfe.net> écrivait (wrote):
Je cherche une moyen simple pour encoder des mails en autre chose que du 7
bits, avec surtout le sujet encodé également. MIME::Lite ne semble
malheureusement ne pas vouloir le faire.
MIME::Lite permet pourtant de la faire (au moins pour le corps). Un extrait du
début de la doc de MIME::Lite :
Create a single-part message:
### Create a new single-part message, to send a GIF file:
$msg = MIME::Lite->new(
From =>'me@myhost.com',
To =>'you@yourhost.com',
Cc =>'some@other.com, some@more.com',
Subject =>'Helloooooo, nurse!',
Type =>'image/gif',
Encoding =>'base64',
Path =>'hellonurse.gif'
);
'Encoding' me semble assez clair. Puis plus loin :
You don't need to worry about encoding your message data:
this module will do that for you. It handles the 5 standard
MIME encodings.
Le 5 types gérés sont '7bit', '8bit', 'binary', 'base64' et
'quoted-printable'.
Reste le problème du sujet lui-même (sachant que quelle que soit la méthode
choisie, il reste encore beaucoup de lecteurs de mail qui ne savent pas
décoder les en-têtes). Je n'ai pas testé MIME::Lite pour savoir comment il
traite les en-têtes non 7bit.
If you need more sophisticated behavior, please get the
MIME-tools package instead. I will be more likely to add
stuff to that toolkit over this one.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Fri, 07 May 2004 23:10:28 +0200, Aurelien écrivait (wrote):
Je cherche une moyen simple pour encoder des mails en autre chose que du 7 bits, avec surtout le sujet encodé également. MIME::Lite ne semble malheureusement ne pas vouloir le faire.
MIME::Lite permet pourtant de la faire (au moins pour le corps). Un extrait du début de la doc de MIME::Lite :
Create a single-part message:
### Create a new single-part message, to send a GIF file: $msg = MIME::Lite->new( From =>'', To =>'', Cc =>', ', Subject =>'Helloooooo, nurse!', Type =>'image/gif', Encoding =>'base64', Path =>'hellonurse.gif' );
'Encoding' me semble assez clair. Puis plus loin :
You don't need to worry about encoding your message data: this module will do that for you. It handles the 5 standard MIME encodings.
Le 5 types gérés sont '7bit', '8bit', 'binary', 'base64' et 'quoted-printable'.
Reste le problème du sujet lui-même (sachant que quelle que soit la méthode choisie, il reste encore beaucoup de lecteurs de mail qui ne savent pas décoder les en-têtes). Je n'ai pas testé MIME::Lite pour savoir comment il traite les en-têtes non 7bit.
If you need more sophisticated behavior, please get the MIME-tools package instead. I will be more likely to add stuff to that toolkit over this one.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
Aurelien
MIME::Lite permet pourtant de la faire (au moins pour le corps). Un extrait du début de la doc de MIME::Lite :
Comme vous le dites, "au moins pour le corps", il est parfaitement exact que MIME::Lite encode correctement le corps, mais pas sur sujet.
Reste le problème du sujet lui-même (sachant que quelle que soit la méthode choisie, il reste encore beaucoup de lecteurs de mail qui ne savent pas décoder les en-têtes). Je n'ai pas testé MIME::Lite pour savoir comment il traite les en-têtes non 7bit.
J'essaye de générer des mails les plus syntaxiquement corrects, respectueux des standards. Le sujet reste un problème.
If you need more sophisticated behavior, please get the MIME-tools package instead. I will be more likely to add stuff to that toolkit over this one.
Je me suis donc tourné vers MIME::Tools qui a, pour ce problème, exactement le même comportement, il n'encode pas le header Subject. MIME::Tools utilise son module MIME::Words pour gérer l'encodage des champs, la seule solution que j'ai trouvée est la suivante :
my $msg = MIME::Lite->new( From =>'', To =>'', Subject => MIME::Words::encoding_qp('Hello!'), Type =>'text/plain', Encoding =>'quoted-printable', );
Mais je n'aime pas trop cette approche qui consiste à passer un champ déjà encodé à une fonction qui n'est pas censée, sémantiquement, prendre de tels paramètres, surtout si les prochaines version de MIME::Lite se mettent à réellement encoder ce champ....
Aurélien
MIME::Lite permet pourtant de la faire (au moins pour le corps). Un extrait du
début de la doc de MIME::Lite :
Comme vous le dites, "au moins pour le corps", il est parfaitement exact
que MIME::Lite encode correctement le corps, mais pas sur sujet.
Reste le problème du sujet lui-même (sachant que quelle que soit la méthode
choisie, il reste encore beaucoup de lecteurs de mail qui ne savent pas
décoder les en-têtes). Je n'ai pas testé MIME::Lite pour savoir comment il
traite les en-têtes non 7bit.
J'essaye de générer des mails les plus syntaxiquement corrects,
respectueux des standards. Le sujet reste un problème.
If you need more sophisticated behavior, please get the
MIME-tools package instead. I will be more likely to add
stuff to that toolkit over this one.
Je me suis donc tourné vers MIME::Tools qui a, pour ce problème,
exactement le même comportement, il n'encode pas le header Subject.
MIME::Tools utilise son module MIME::Words pour gérer l'encodage des
champs, la seule solution que j'ai trouvée est la suivante :
my $msg = MIME::Lite->new(
From =>'me@myhost.com',
To =>'you@yourhost.com',
Subject => MIME::Words::encoding_qp('Hello!'),
Type =>'text/plain',
Encoding =>'quoted-printable',
);
Mais je n'aime pas trop cette approche qui consiste à passer un champ
déjà encodé à une fonction qui n'est pas censée, sémantiquement, prendre
de tels paramètres, surtout si les prochaines version de MIME::Lite se
mettent à réellement encoder ce champ....
MIME::Lite permet pourtant de la faire (au moins pour le corps). Un extrait du début de la doc de MIME::Lite :
Comme vous le dites, "au moins pour le corps", il est parfaitement exact que MIME::Lite encode correctement le corps, mais pas sur sujet.
Reste le problème du sujet lui-même (sachant que quelle que soit la méthode choisie, il reste encore beaucoup de lecteurs de mail qui ne savent pas décoder les en-têtes). Je n'ai pas testé MIME::Lite pour savoir comment il traite les en-têtes non 7bit.
J'essaye de générer des mails les plus syntaxiquement corrects, respectueux des standards. Le sujet reste un problème.
If you need more sophisticated behavior, please get the MIME-tools package instead. I will be more likely to add stuff to that toolkit over this one.
Je me suis donc tourné vers MIME::Tools qui a, pour ce problème, exactement le même comportement, il n'encode pas le header Subject. MIME::Tools utilise son module MIME::Words pour gérer l'encodage des champs, la seule solution que j'ai trouvée est la suivante :
my $msg = MIME::Lite->new( From =>'', To =>'', Subject => MIME::Words::encoding_qp('Hello!'), Type =>'text/plain', Encoding =>'quoted-printable', );
Mais je n'aime pas trop cette approche qui consiste à passer un champ déjà encodé à une fonction qui n'est pas censée, sémantiquement, prendre de tels paramètres, surtout si les prochaines version de MIME::Lite se mettent à réellement encoder ce champ....
Aurélien
Aurelien
En fait, je travaille dans un environnement restreint ou j'ai très peu de marge de manoeuvre, et surtout...pas de shell. (Web only). Pour compiler les modules Perl qui contiennent une partie binaire, il faut que la machine possède les headers nécessaires... Bref, bcp de contraintes et de 'si'. Mais, il est vrai qu'avec un peu de chance et en bidouillant un peu, il est possible de contourner le problème...
Aurélien
Bonjour,
Il est toujours possible d'installer les modules ailleurs que dans l'endroit standard. Il suffit de mettre quelques option sur la ligne "perl Makefile.PL". Exemple : perl Makefile.PL INSTALLDIRS=perl PREFIX=$HOME cela installe le module dans $HOME/lib/perl5/... Il suffit ensuite de positionner la variable d'environnement PERL5LIB en ajoutant le chemin $HOME/LIB/perl5 pour qu'on puisse accéder sans problème au module depuis n'importe quel script. On peut aussi mettre une ligne use lib "$ENV{HOME}/lib/perl5" dans les scripts appelant les modules privés.
Denis
En fait, je travaille dans un environnement restreint ou j'ai très peu
de marge de manoeuvre, et surtout...pas de shell. (Web only).
Pour compiler les modules Perl qui contiennent une partie binaire, il
faut que la machine possède les headers nécessaires...
Bref, bcp de contraintes et de 'si'.
Mais, il est vrai qu'avec un peu de chance et en bidouillant un peu, il
est possible de contourner le problème...
Aurélien
Bonjour,
Il est toujours possible d'installer les modules ailleurs que dans l'endroit
standard. Il suffit de mettre quelques option sur la ligne "perl
Makefile.PL". Exemple :
perl Makefile.PL INSTALLDIRS=perl PREFIX=$HOME
cela installe le module dans $HOME/lib/perl5/...
Il suffit ensuite de positionner la variable d'environnement PERL5LIB en
ajoutant le chemin $HOME/LIB/perl5 pour qu'on puisse accéder sans problème
au module depuis n'importe quel script. On peut aussi mettre une ligne
use lib "$ENV{HOME}/lib/perl5"
dans les scripts appelant les modules privés.
En fait, je travaille dans un environnement restreint ou j'ai très peu de marge de manoeuvre, et surtout...pas de shell. (Web only). Pour compiler les modules Perl qui contiennent une partie binaire, il faut que la machine possède les headers nécessaires... Bref, bcp de contraintes et de 'si'. Mais, il est vrai qu'avec un peu de chance et en bidouillant un peu, il est possible de contourner le problème...
Aurélien
Bonjour,
Il est toujours possible d'installer les modules ailleurs que dans l'endroit standard. Il suffit de mettre quelques option sur la ligne "perl Makefile.PL". Exemple : perl Makefile.PL INSTALLDIRS=perl PREFIX=$HOME cela installe le module dans $HOME/lib/perl5/... Il suffit ensuite de positionner la variable d'environnement PERL5LIB en ajoutant le chemin $HOME/LIB/perl5 pour qu'on puisse accéder sans problème au module depuis n'importe quel script. On peut aussi mettre une ligne use lib "$ENV{HOME}/lib/perl5" dans les scripts appelant les modules privés.
Denis
Paul GABORIT
À (at) Mon, 10 May 2004 13:39:22 +0200, Aurelien écrivait (wrote): [...]
Comme vous le dites, "au moins pour le corps", il est parfaitement exact que MIME::Lite encode correctement le corps, mais pas sur sujet. [...]
Je me suis donc tourné vers MIME::Tools qui a, pour ce problème, exactement le même comportement, il n'encode pas le header Subject.
En fait, la bonne question est « existe-t-il une RFC qui définit le codage des caractères autres qu'ANSI dans un en-tête de mail ? ». Une fois la réponse trouvée, il suffit de coder la bonne solution.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Mon, 10 May 2004 13:39:22 +0200,
Aurelien <spam@lelfe.net> écrivait (wrote):
[...]
Comme vous le dites, "au moins pour le corps", il est parfaitement exact que
MIME::Lite encode correctement le corps, mais pas sur sujet.
[...]
Je me suis donc tourné vers MIME::Tools qui a, pour ce problème, exactement
le même comportement, il n'encode pas le header Subject.
En fait, la bonne question est « existe-t-il une RFC qui définit le codage des
caractères autres qu'ANSI dans un en-tête de mail ? ». Une fois la réponse
trouvée, il suffit de coder la bonne solution.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Mon, 10 May 2004 13:39:22 +0200, Aurelien écrivait (wrote): [...]
Comme vous le dites, "au moins pour le corps", il est parfaitement exact que MIME::Lite encode correctement le corps, mais pas sur sujet. [...]
Je me suis donc tourné vers MIME::Tools qui a, pour ce problème, exactement le même comportement, il n'encode pas le header Subject.
En fait, la bonne question est « existe-t-il une RFC qui définit le codage des caractères autres qu'ANSI dans un en-tête de mail ? ». Une fois la réponse trouvée, il suffit de coder la bonne solution.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
Paul GABORIT
À (at) Mon, 10 May 2004 14:06:27 +0200, Paul GABORIT écrivait (wrote):
En fait, la bonne question est « existe-t-il une RFC qui définit le codage des caractères autres qu'ANSI dans un en-tête de mail ? ». Une fois la réponse trouvée, il suffit de coder la bonne solution.
Je voulais dire :
...autres qu'ASCII dans un en-tête... ~~~~~~
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Mon, 10 May 2004 14:06:27 +0200,
Paul GABORIT <Paul.Gaborit@invalid.invalid> écrivait (wrote):
En fait, la bonne question est « existe-t-il une RFC qui définit le codage
des caractères autres qu'ANSI dans un en-tête de mail ? ». Une fois la
réponse trouvée, il suffit de coder la bonne solution.
Je voulais dire :
...autres qu'ASCII dans un en-tête...
~~~~~~
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Mon, 10 May 2004 14:06:27 +0200, Paul GABORIT écrivait (wrote):
En fait, la bonne question est « existe-t-il une RFC qui définit le codage des caractères autres qu'ANSI dans un en-tête de mail ? ». Une fois la réponse trouvée, il suffit de coder la bonne solution.
Je voulais dire :
...autres qu'ASCII dans un en-tête... ~~~~~~
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
Aurelien
À (at) Mon, 10 May 2004 14:06:27 +0200, Paul GABORIT écrivait (wrote):
En fait, la bonne question est « existe-t-il une RFC qui définit le codage des caractères autres qu'ANSI dans un en-tête de mail ? ». Une fois la réponse trouvée, il suffit de coder la bonne solution.
Il est vrai, les quelques RFC que j'ai lu à ce sujet n'en parlent pas. Mais pourtant, un certains nombres de logiciels, dont certains que je considère comme assez respectueux des standards comme Mozilla, le font. De plus certains logiciels de filtrage se plaignent si le sujet n'est pas encodé (ce qui peut sembler normal, car les problèmes qui peuvent survenir à cause du non-encodage du corps du mail, peuvent survenir également concernant le sujet). Tous ces programmes auraient pris l'initiative de gérer cet encodage, sans accord avec les RFC ? Le manque dans les RFCs à ce sujet expliqueraient pourquoi les modules Perl MIME:: n'encode pas ?
Aurélien
À (at) Mon, 10 May 2004 14:06:27 +0200,
Paul GABORIT <Paul.Gaborit@invalid.invalid> écrivait (wrote):
En fait, la bonne question est « existe-t-il une RFC qui définit le codage
des caractères autres qu'ANSI dans un en-tête de mail ? ». Une fois la
réponse trouvée, il suffit de coder la bonne solution.
Il est vrai, les quelques RFC que j'ai lu à ce sujet n'en parlent pas.
Mais pourtant, un certains nombres de logiciels, dont certains que je
considère comme assez respectueux des standards comme Mozilla, le font.
De plus certains logiciels de filtrage se plaignent si le sujet n'est
pas encodé (ce qui peut sembler normal, car les problèmes qui peuvent
survenir à cause du non-encodage du corps du mail, peuvent survenir
également concernant le sujet).
Tous ces programmes auraient pris l'initiative de gérer cet encodage,
sans accord avec les RFC ?
Le manque dans les RFCs à ce sujet expliqueraient pourquoi les modules
Perl MIME:: n'encode pas ?
À (at) Mon, 10 May 2004 14:06:27 +0200, Paul GABORIT écrivait (wrote):
En fait, la bonne question est « existe-t-il une RFC qui définit le codage des caractères autres qu'ANSI dans un en-tête de mail ? ». Une fois la réponse trouvée, il suffit de coder la bonne solution.
Il est vrai, les quelques RFC que j'ai lu à ce sujet n'en parlent pas. Mais pourtant, un certains nombres de logiciels, dont certains que je considère comme assez respectueux des standards comme Mozilla, le font. De plus certains logiciels de filtrage se plaignent si le sujet n'est pas encodé (ce qui peut sembler normal, car les problèmes qui peuvent survenir à cause du non-encodage du corps du mail, peuvent survenir également concernant le sujet). Tous ces programmes auraient pris l'initiative de gérer cet encodage, sans accord avec les RFC ? Le manque dans les RFCs à ce sujet expliqueraient pourquoi les modules Perl MIME:: n'encode pas ?
Aurélien
Paul GABORIT
À (at) Mon, 10 May 2004 20:51:31 +0200, Aurelien écrivait (wrote):
Il est vrai, les quelques RFC que j'ai lu à ce sujet n'en parlent pas.
La RFC concernée est la 2047.
Mais pourtant, un certains nombres de logiciels, dont certains que je considère comme assez respectueux des standards comme Mozilla, le font.
Certains ne font rien d'autres que d'accepter les en-têtes tels quels. D'autres le font (ou le faisaient) à leur manière. Les plus récents respectent (ou tentent de respecter) la RFC 2047 (qui date pourtant de 1996;-).
De plus certains logiciels de filtrage se plaignent si le sujet n'est pas encodé (ce qui peut sembler normal, car les problèmes qui peuvent survenir à cause du non-encodage du corps du mail, peuvent survenir également concernant le sujet).
Les logiciels de filtrage crient non pas parce que le sujet n'est pas encodé mais parce qu'il contient des caractères non ASCII.
Tous ces programmes auraient pris l'initiative de gérer cet encodage, sans accord avec les RFC ?
On peut le dire comme ça... au départ en tous cas.
Le manque dans les RFCs à ce sujet expliqueraient pourquoi les modules Perl MIME:: n'encode pas ?
En fait, le module Perl pour cela existe : Encode::MIME::Header. Je ne l'ai encore jamais utilisé. Il est limité à l'encodage UTF-8 (ce qui dans l'absolu n'est pas une limite mais peut en être une si les agents recevant le mail ne gèrent pas cet encodage).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Mon, 10 May 2004 20:51:31 +0200,
Aurelien <spam@lelfe.net> écrivait (wrote):
Il est vrai, les quelques RFC que j'ai lu à ce sujet n'en parlent pas.
La RFC concernée est la 2047.
Mais pourtant, un certains nombres de logiciels, dont certains que je
considère comme assez respectueux des standards comme Mozilla, le font.
Certains ne font rien d'autres que d'accepter les en-têtes tels
quels. D'autres le font (ou le faisaient) à leur manière. Les plus récents
respectent (ou tentent de respecter) la RFC 2047 (qui date pourtant de
1996;-).
De plus certains logiciels de filtrage se plaignent si le sujet n'est pas
encodé (ce qui peut sembler normal, car les problèmes qui peuvent survenir à
cause du non-encodage du corps du mail, peuvent survenir également
concernant le sujet).
Les logiciels de filtrage crient non pas parce que le sujet n'est pas encodé
mais parce qu'il contient des caractères non ASCII.
Tous ces programmes auraient pris l'initiative de gérer cet encodage, sans
accord avec les RFC ?
On peut le dire comme ça... au départ en tous cas.
Le manque dans les RFCs à ce sujet expliqueraient pourquoi les modules Perl
MIME:: n'encode pas ?
En fait, le module Perl pour cela existe : Encode::MIME::Header. Je ne l'ai
encore jamais utilisé. Il est limité à l'encodage UTF-8 (ce qui dans l'absolu
n'est pas une limite mais peut en être une si les agents recevant le mail ne
gèrent pas cet encodage).
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>
À (at) Mon, 10 May 2004 20:51:31 +0200, Aurelien écrivait (wrote):
Il est vrai, les quelques RFC que j'ai lu à ce sujet n'en parlent pas.
La RFC concernée est la 2047.
Mais pourtant, un certains nombres de logiciels, dont certains que je considère comme assez respectueux des standards comme Mozilla, le font.
Certains ne font rien d'autres que d'accepter les en-têtes tels quels. D'autres le font (ou le faisaient) à leur manière. Les plus récents respectent (ou tentent de respecter) la RFC 2047 (qui date pourtant de 1996;-).
De plus certains logiciels de filtrage se plaignent si le sujet n'est pas encodé (ce qui peut sembler normal, car les problèmes qui peuvent survenir à cause du non-encodage du corps du mail, peuvent survenir également concernant le sujet).
Les logiciels de filtrage crient non pas parce que le sujet n'est pas encodé mais parce qu'il contient des caractères non ASCII.
Tous ces programmes auraient pris l'initiative de gérer cet encodage, sans accord avec les RFC ?
On peut le dire comme ça... au départ en tous cas.
Le manque dans les RFCs à ce sujet expliqueraient pourquoi les modules Perl MIME:: n'encode pas ?
En fait, le module Perl pour cela existe : Encode::MIME::Header. Je ne l'ai encore jamais utilisé. Il est limité à l'encodage UTF-8 (ce qui dans l'absolu n'est pas une limite mais peut en être une si les agents recevant le mail ne gèrent pas cet encodage).
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Perl en français - <http://www.enstimac.fr/Perl/>
