Champ Subject avec accents dans un lien mailto.
Olivier Miakinen
Bonjour,
Dans fciwa et fciwn, Thomas de Contes demandait comment préremplir le
sujet d'un courriel au moyen d'un lien mailto, et plus particulièrement
comment mettre autre chose que de l'ASCII 7 bits dans ce champ.
Ayant parcouru le RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt>, il me
semble qu'il suffit d'encoder la valeur au format MIME, soit en QP soit
en Base64, par exemple comme ceci : <http://www.miakinen.net/tmp/mailto>.
J'ai testé avec Mozilla comme navigateur et courrielleur, et aussi avec
Internet Explorer comme navigateur et Thunderbird comme courrielleur :
tous deux fonctionnent (sur Windows 2000 ou XP, je ne sais plus). Mais
je voudrais savoir si cela fonctionne aussi avec d'autres couples
(navigateur + courrielleur). Si jamais vous connaissez déjà une doc
listant les différentes configurations supportées, cela m'intéresse.
Et si ce n'était pas le cas, j'aimerais bien que ceux qui le veulent se
livrent au petit test de <http://www.miakinen.net/tmp/mailto>.
Vous pouvez soit m'envoyer le message ouvert dans votre courrielleur,
soit annuler l'envoi et venir décrire ici le résultat. Dans un cas
comme dans l'autre, n'oubliez pas de préciser votre environnement
(OS + navigateur web + courrielleur) !
Par exemple : Windows 2000 + Internet Explorer 6 + Mozilla 1.7.12.
Ou bien : MacOS 9 + Netscape 4 + Netscape 4.
Etc.
D'avance, merci. Je viendrai bien sûr donner le résultat dans les trois
groupes, avec suivi sur un seul.
--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)
rm
> [ publication croisée dans trois groupes, suivi vers fr.comp.mail ]
>
> Bonjour,
Salut,
> Dans fciwa et fciwn, Thomas de Contes demandait comment préremplir le
> sujet d'un courriel au moyen d'un lien mailto, et plus particulièrement
> comment mettre autre chose que de l'ASCII 7 bits dans ce champ.
>
> Ayant parcouru le RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt>, il me
> semble qu'il suffit d'encoder la valeur au format MIME, soit en QP soit
> en Base64, par exemple comme ceci : <http://www.miakinen.net/tmp/mailto>.
>
> J'ai testé avec Mozilla comme navigateur et courrielleur, et aussi avec
> Internet Explorer comme navigateur et Thunderbird comme courrielleur :
> tous deux fonctionnent (sur Windows 2000 ou XP, je ne sais plus). Mais
> je voudrais savoir si cela fonctionne aussi avec d'autres couples
> (navigateur + courrielleur). Si jamais vous connaissez déjà une doc
> listant les différentes configurations supportées, cela m'intéresse.
> Et si ce n'était pas le cas, j'aimerais bien que ceux qui le veulent se
> livrent au petit test de <http://www.miakinen.net/tmp/mailto>.
>
> Vous pouvez soit m'envoyer le message ouvert dans votre courrielleur,
> soit annuler l'envoi et venir décrire ici le résultat. Dans un cas
> comme dans l'autre, n'oubliez pas de préciser votre environnement
> (OS + navigateur web + courrielleur) !
>
> Par exemple : Windows 2000 + Internet Explorer 6 + Mozilla 1.7.12.
> Ou bien : MacOS 9 + Netscape 4 + Netscape 4.
> Etc.
_Ne fonctionne pas avec les trio suivants_ :
WinXPSP1 + Opera 8.53 + Opera 8.53
WinXPSP1 + Opera 9 (8265) + Opera 9 (8265)
WinXPSP1 + Opera 8.53 + Foxmail 5.0.800.0
WinXPSP1 + Opera 8.53 + Dreammail 4.0.4.1
WinXPSP1 + Opera 8.53 + Outlook Express 6 SP1
WinXPSP1 + Opera 8.53 + Outlook2002
WinXPSP1 + Orca Browser 1.0 RC3 + Foxmail 5.0.800.0
WinXPSP1 + Orca Browser 1.0 RC3 + Dreammail 4.0.4.1
WinXPSP1 + Orca Browser 1.0 RC3 + Outlook Express 6 SP1
WinXPSP1 + Orca Browser 1.0 RC3 + Outlook2002
WinXPSP1 + Offbyone 3.5a + Foxmail 5.0.800.0
WinXPSP1 + Offbyone 3.5a + DreamMail 4.0.4.1
WinXPSP1 + Offbyone 3.5a + Outlook Express 6 SP1
WinXPSP1 + Offbyone 3.5a + Outlook2002
WinXPSP1 + Offbyone 3.5a + Thunderbird 1.5
sujet obtenu en général égal à
"=?ISO-8859-1?Q?Gr=E2ce_=E0_QP?="
sauf avec DreamMail avec lequel on obtient
"%3D%3FISO-8859-1%3FQ%3FGr%3DE2ce_%3DE0_QP%3F%3D"
quand ça vient d'Orca :)
_Fonctionne avec les trio suivant_ :
WinXPSP1 + Opera 8.53 + Thunderbird 1.5
WinXPSP1 + Opera 9 b8265 + Thunderbird 1.5
WinXPSP1 + Orca Browser 1.0 RC3 + Thunderbird 1.5
@+
--
rm
Bobe
>
> Ayant parcouru le RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt>, il me
> semble qu'il suffit d'encoder la valeur au format MIME, soit en QP soit
> en Base64, par exemple comme ceci : <http://www.miakinen.net/tmp/mailto>.
>
Il me semble que c'est là le rôle du MUA, non des auteurs de pages web.
--
Aurélien Maille
Olivier Miakinen
>>
>> <http://www.miakinen.net/tmp/mailto>.
>
> _Ne fonctionne pas avec les trios suivants_ :
> WinXPSP1 + Opera 8.53 + Opera 8.53
> WinXPSP1 + Opera 9 (8265) + Opera 9 (8265)
> WinXPSP1 + Opera 8.53 + Foxmail 5.0.800.0
> WinXPSP1 + Opera 8.53 + Dreammail 4.0.4.1
> WinXPSP1 + Opera 8.53 + Outlook Express 6 SP1
> WinXPSP1 + Opera 8.53 + Outlook2002
> WinXPSP1 + Orca Browser 1.0 RC3 + Foxmail 5.0.800.0
> WinXPSP1 + Orca Browser 1.0 RC3 + Dreammail 4.0.4.1
> WinXPSP1 + Orca Browser 1.0 RC3 + Outlook Express 6 SP1
> WinXPSP1 + Orca Browser 1.0 RC3 + Outlook2002
> WinXPSP1 + Offbyone 3.5a + Foxmail 5.0.800.0
> WinXPSP1 + Offbyone 3.5a + DreamMail 4.0.4.1
> WinXPSP1 + Offbyone 3.5a + Outlook Express 6 SP1
> WinXPSP1 + Offbyone 3.5a + Outlook2002
> WinXPSP1 + Offbyone 3.5a + Thunderbird 1.5
Ben ça c'est du test ! Un grand merci à toi.
> sujet obtenu en général égal à
> "=?ISO-8859-1?Q?Gr=E2ce_=E0_QP?="
Il serait intéressant que tu cliques sur « Envoyer » dans ces cas-là,
quitte à cacher ton adresse si tu ne veux pas que je la récupère, car
j'ai eu ce comportement dans l'éditeur de Netscape 4.79 sur AIX 4.3.3
mais au final le sujet s'est correctement affiché une fois arrivé.
En fait, je me demande si la plupart de ceux qui m'ont déjà répondu par
courriel (et où j'ai constaté que c'était correct à l'arrivée) n'ont pas
eu le même problème que toi, sans forcément le voir.
> sauf avec DreamMail avec lequel on obtient
> "%3D%3FISO-8859-1%3FQ%3FGr%3DE2ce_%3DE0_QP%3F%3D"
> quand ça vient d'Orca :)
Là en effet il n'y a aucune chance que cela fonctionne.
> _Fonctionne avec les trios suivants_ :
>
> WinXPSP1 + Opera 8.53 + Thunderbird 1.5
> WinXPSP1 + Opera 9 b8265 + Thunderbird 1.5
> WinXPSP1 + Orca Browser 1.0 RC3 + Thunderbird 1.5
Brave Thunderbird... mais bon, à lui tout seul il ne compense pas le
fait que ça ne marche pas dans tous les autres cas que tu signalais.
Thomas
<4415eddb$0$19690$8fcf...@news.wanadoo.fr>,
Bobe <bo...@antispam.invalid> wrote (écrivait) :
j'espere que t'as raison, c'est un rien compliqué à encoder :-)
en fait si j'ai bien compris,
le pb c'est que la norme ne dit pas grand chose sur la communication
client web / client email,
donc c'est pas facile de determiner ce qu'on doit ecrire dans une url
mailto: pour avoir un resultat precis dans le message lui meme ?
mais, si il y a certaines normes à respecter pour envoyer un sujet avec
un accent, il y a de toutes facon pas trop de danger que le client email
envoie un sujet non conforme,
le seul danger c'est qu'il n'envoie pas "le bon accent" ?
--
http://tDeContes.hd.free.fr/
http://palestine-hn.org/
http://www.aapel.org/bdp/BLpas_concerne.html
"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"
Olivier Miakinen
>>
>> Ayant parcouru le RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt>, il me
>> semble qu'il suffit d'encoder la valeur au format MIME, soit en QP soit
>> en Base64, par exemple comme ceci : <http://www.miakinen.net/tmp/mailto>.
>
> Il me semble que c'est là le rôle du MUA, non des auteurs de pages web.
Tu parles du fait de pré-remplir le champ Subject [cas 1], ou du fait de
l'encoder comme il faut [cas 2] ?
Si c'est le cas 1, bien évidemment le MUA propose à l'utilisateur de
remplir ou de modifier le champ Subject. Mais il y a des tas de
situations dans lesquelles un auteur de page web pourrait vouloir
proposer une valeur par défaut pour le sujet, différente d'une page
à l'autre. L'exemple le plus simple, c'est un site avec des milliers
de pages et un lien mailto sur chaque page permettant de réagir à son
contenu. Le fait de positionner le sujet facilite l'identification de
la page où était le visiteur quand il a cliqué.
Maintenant, si c'est le cas 2, vu qu'il n'y a aucun paramètre dans l'URL
de type mailto pour donner le charset et le transfer-encoding, le MUA
n'a aucun moyen pour deviner ce qu'il doit faire d'une chaîne d'octets.
Comme en outre les caractères 8 bits y sont interdits, le MUA ne doit
pas avoir beaucoup d'états d'âme pour transmettre la chaîne telle
quelle. Enfin, je rappelle (ce que j'avais fait dans fciwa seul) que
les entêtes MIME d'un courriel, remplis par le MUA en fonction du corps
du message, n'ont *aucune* influence sur les autres entêtes, Subject
compris.
Donc non, ça ne peut pas être le rôle du MUA d'encoder un champ Subject
pré-rempli.
Thomas
rm <ra...@tffp.invalid> wrote (écrivait) :
> Le 13/03/2006 18:54:32, Olivier Miakinen a écrit :
>
> > Dans fciwa et fciwn, Thomas de Contes demandait comment préremplir le
> > sujet d'un courriel au moyen d'un lien mailto, et plus particulièrement
> > comment mettre autre chose que de l'ASCII 7 bits dans ce champ.
merci de faire tout ca pour moi :-)
> > Ayant parcouru le RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt>, il me
> > semble qu'il suffit d'encoder la valeur au format MIME, soit en QP soit
> > en Base64, par exemple comme ceci : <http://www.miakinen.net/tmp/mailto>.
> >
> > je voudrais savoir si cela fonctionne aussi avec d'autres couples
> > (navigateur + courrielleur).
> > j'aimerais bien que ceux qui le veulent se
> > livrent au petit test de <http://www.miakinen.net/tmp/mailto>.
mac os x 10.2.8 + (icab | firefox) + apple mail :
fonctionne : tout est affiché correctement, je ne vois pas comment ca
pourrais ne pas etre envoyé corectement
est ce que tu pourrais tester tout ca avec
<fantome.forums.tDeConte...@nnrp1-2.proxad.net>
stp ? :-)
http://palestine-hn.org/dossiers/basem/
(tout en bas, "Vous pouvez nous contacter par eMail" juste en dessous de
la derniere photo (les 2 liens sont codés pareil))
(ou peut etre pas tout, peut etre que qqes combinaisons qui representent
tous les logiciels peuvent suffire :-) )
Bobe
> Le 13/03/2006 23:11, Bobe a écrit :
>>> Ayant parcouru le RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt>, il me
>>> semble qu'il suffit d'encoder la valeur au format MIME, soit en QP soit
>>> en Base64, par exemple comme ceci : <http://www.miakinen.net/tmp/mailto>.
>> Il me semble que c'est là le rôle du MUA, non des auteurs de pages web.
>
> Tu parles du fait de pré-remplir le champ Subject [cas 1], ou du fait de
> l'encoder comme il faut [cas 2] ?
>
Du fait de l'encoder.
> Maintenant, si c'est le cas 2, vu qu'il n'y a aucun paramètre dans l'URL
> de type mailto pour donner le charset et le transfer-encoding,
Que veux-tu dire par "transfer-encoding" ?
> le MUA n'a aucun moyen pour deviner ce qu'il doit faire d'une chaîne d'octets.
> Comme en outre les caractères 8 bits y sont interdits, le MUA ne doit
> pas avoir beaucoup d'états d'âme pour transmettre la chaîne telle
> quelle.
Je pense, mais je ne suis pas expert, que l'application appelant le MUA
doit lui transmettre le champ subject pré-rempli dans le jeu de
caractères du système. Quant aux caractères non-ascii, il devrait
simplement être codé dans la forme %XX dans l'url.
>
> Donc non, ça ne peut pas être le rôle du MUA d'encoder un champ Subject
> pré-rempli.
Qui d'autre sinon ??
Le mécanisme du mailto: repose sur le principe des URIs, pourquoi
l'encodage des différentes parties le composant ferait-il exception ?
--
Aurélien Maille
Olivier Miakinen
> [plein de choses auxquelles je répondrai plus tard]
Puis :
>
> [...] Quant aux caractères non-ascii, il devrait
> simplement être codé dans la forme %XX dans l'url.
Mais bon sang, tu as raison bien sûr ! Je viens de rajouter cet autre
test à la page <http://www.miakinen.net/tmp/mailto>, mais il est évident
que c'est le bonne manière de procéder. Curieusement, avec Mozilla, le
caractère + n'est pas équivalent à %20 (pour coder l'espace).
Si vous avez le courage de refaire des tests, j'en serai ravi. Bien
entendu, même si l'idée du QP n'était pas la bonne, je publierai quand
même les résultats avec les deux méthodes.
Pierre Goiffon
> j'aimerais bien que ceux qui le veulent se
> livrent au petit test de <http://www.miakinen.net/tmp/mailto>.
Avec :
Windows 2000 SP4 + Firefox 1.5.0.1 + Lotus Notes 6.5.4
On obtient :
A: test+...@miakinen.net
Objet: =?ISO-8859-1?Q?Gr=E2ce_=E0_QP?=
Corps : uniquement la signature configurée par défaut
Pierre Goiffon
Et le 2eme test toujours avec la même configuration donne dans l'objet
des caractères étranges venus d'ailleurs qui ne passeraient qu'en UTF-8,
ce que le serveur de Free rejette (?!!????)
Bref une copie d'écran ici :
http://pgoiffon.free.fr/_temp/20060314_test_mailto_%25.gif
Olivier Miakinen
>
>> de type mailto pour donner le charset et le transfer-encoding,
>
> Que veux-tu dire par "transfer-encoding" ?
Je voulais dire ça (exemple dans les entêtes de ton article) :
----------
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
----------
(d'autres possibilités sont : 7bit, quoted-printable et base64).
Mais j'étais parti du principe que l'on ne peut transmettre que des
caractères 7 bits, sans penser à l'histoire des %nn%pp%qq où nn, pp
et qq correspondent à l'encodage UTF-8.
>> le MUA n'a aucun moyen pour deviner ce qu'il doit faire d'une chaîne d'octets.
>> Comme en outre les caractères 8 bits y sont interdits, le MUA ne doit
>> pas avoir beaucoup d'états d'âme pour transmettre la chaîne telle
>> quelle.
>
> Je pense, mais je ne suis pas expert, que l'application appelant le MUA
> doit lui transmettre le champ subject pré-rempli dans le jeu de
> caractères du système.
Je croyais ne pas être d'accord avec ton « dans le jeu de caractères
du système » parce que j'ai d'abord imaginé que tu parlais des « â »,
« à », « € », etc. Mais en fait tu as certainement raison, maintenant
que j'ai compris que cela s'applique aux caractères ASCII, à transcoder
si le système fonctionne en EBCDIC.
> Quant aux caractères non-ascii, il devrait
> simplement être codé dans la forme %XX dans l'url.
Donc j'ai rajouté cette méthode dans ma page de tests. Pas de problème
avec Mozilla et Thunderbird, mais d'autres courrielleurs semblent avoir
du mal à s'en sortir : voir par exemple l'article de Pierre Goiffon, et
je constate des choses similaires avec Netscape 4.
Jacques Belin
Le lundi 13 mars 2006 18:54:32,
Olivier Miakinen <om+...@miakinen.net> a écrit:
> Ayant parcouru le RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt>, il me
> semble qu'il suffit d'encoder la valeur au format MIME, soit en QP soit
> en Base64, par exemple comme ceci : <http://www.miakinen.net/tmp/mailto>.
Win95 + Mozilla 1.0 + Becky! 2.24.02 :
Premier test :
La chaîne apparait en format QP, mais une fois le message stocké, le
texte apparaît en clair.
Deuxième test :
Le texte apparait en clair tout de suite.
A+ Jacques.
--
Le dernier Homme connecté sur le Net regardait d'anciens sites Webs.
"Vous avez du courrier" apparut sur l'écran...
--------------------------- adapté d'une courte histoire de Fredric Brown
Bobe
>
> Mais bon sang, tu as raison bien sûr ! Je viens de rajouter cet autre
> test à la page <http://www.miakinen.net/tmp/mailto>, mais il est évident
> que c'est le bonne manière de procéder. Curieusement, avec Mozilla, le
> caractère + n'est pas équivalent à %20 (pour coder l'espace).
>
Attention, je pense que mélanger les deux encodages (espace sous forme
de ù20 ou sous forme de +) ne doit pas être correct, ou du moins que
cela risque d'induire en erreur le navigateur.
Tu devrais plutôt décomposer en deux tests, un avec les espaces sous
forme de %20, et l'autre avec les espaces sous forme de +.
--
Aurélien Maille
Olivier Miakinen
>
> Attention, je pense que mélanger les deux encodages (espace sous forme
Il n'y a aucune raison que ce soit le cas. De même que tu peux mélanger
des « e » et des « %65 » dans la même URL sans que le navigateur ne
perde les pédales (ou alors c'est qu'il est bizarrement codé).
> Tu devrais plutôt décomposer en deux tests, un avec les espaces sous
> forme de %20, et l'autre avec les espaces sous forme de +.
Initialement je n'avais que des + et aucun %20, et j'ai rencontré
le problème avec Mozilla. Le mélange des deux me permet de tester
facilement ces deux cas, sans abuser encore de la patience des
testeurs qui sont déjà bien sympas.
Eric Demeester
ecrivait (wrote) :
Bonjour,
J'ai rapidement parcouru la discussion et il me semble (je peux me
tromper) que :
> Dans fciwa et fciwn, Thomas de Contes demandait comment préremplir le
> sujet d'un courriel au moyen d'un lien mailto, et plus particulièrement
> comment mettre autre chose que de l'ASCII 7 bits dans ce champ.
Au delà du conseil avisé d'Aurélien (alias Bobe) d'encoder la chose sous
forme d'URL (remplacer les caractères non ASCII par des %xx), je crains
que résoudre ce problème ne s'apparente à la quadrature du cercle.
> Ayant parcouru le RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt>, il me
> semble qu'il suffit d'encoder la valeur au format MIME, soit en QP soit
> en Base64, par exemple comme ceci : <http://www.miakinen.net/tmp/mailto>.
Oui mais non, car comme dit dans un autre message, la définition d'un
jeu de caractères et d'un type MIME dans les en-têtes est supposée ne
concerner que le corps du mail, pas les en-têtes, et ce d'autant plus
que l'ordre de description des champs d'en-têtes n'est pas prédéfini,
tandis que sa lecture par le logiciel client recevant le mail est
séquentiel.
Ainsi, si le champ « Subject: » précède les champs :
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Il y a de grandes chances, sauf si l'encodage du sujet correspond aux
paramétrages par défaut du logiciel client, que ces éléments ne soient
pas pris en compte et que le champ « Subject: » ne soit pas correctement
affiché.
S'il appartient au logiciel d'envoi (ici un script PHP si j'ai bien
suivi) d'indiquer des champs d'en-têtes corrects, la restitution
correcte des en-têtes en question (champ « Subject: » compris) dépendra
uniquement du client de courrier et de son paramétrage par défaut.
> Et si ce n'était pas le cas, j'aimerais bien que ceux qui le veulent se
> livrent au petit test de <http://www.miakinen.net/tmp/mailto>.
Je viens d'essayer depuis FireFox avec Pegasus Mail, chargé d'envoyer
tous mes courriers.
Avec ton premier lien j'obtiens :
To: test%2Bmailto%40miakinen.net
Subject: =?ISO-8859-1?Q?Gr=E2ce_=E0_QP?=
(Pegasus présume d'un encodage en QP et affichera probablement
correctement le sujet en réception)
Avec le second j'ai :
To: test%2Bmailto%40miakinen.net
Subject: Grâce à % avec+ou+sans++
> (OS + navigateur web + courrielleur) !
WinXP pro sp2 + FireFox 1.0.4 + Pegasus 4.31.
PS: Veux-tu que je t'expédies de vrais courriers ou la vue des en-têtes
générées te suffit-elle ?
--
Eric
rm
> est ce que tu pourrais tester tout ca avec
> <fantome.forums.tDeConte...@nnrp1-2.proxad.net>
> stp ? :-)
>
> http://palestine-hn.org/dossiers/basem/
> (tout en bas, "Vous pouvez nous contacter par eMail" juste en dessous de
> la derniere photo (les 2 liens sont codés pareil))
>
> (ou peut etre pas tout, peut etre que qqes combinaisons qui representent
> tous les logiciels peuvent suffire :-) )
bon alors, Sous Win2000 ce coup ci:
- depuis Opera 9 build 8225:
destinataire et sujet correctement renseignés dans Outlook-Express 6 et
Foxmail 5.0.600.0
rien du tout par contre dans DreamMail 4.1.0.5 (destinataire et sujet
complètement vides!)
-depuis OrcaBrowser 1.0.RC3 (idem Firefox 1.5) et Deepnet Explorer 1.5
bêta2 (surcouche IE6):
destinataire OK, mais sujet altéré (le "à" remplacé par un A-tilde ou juste
un accent circonflexe...) dans Foxmail 5 et OE6
"Coordinateur des Missions Civiles en Haute Normandie
%3ccoordina%74eur%40admin.palestine-hn.org%3e" et "%5Bc%70hn%5D Soutien
%C3%A0 Basem" dans DreamMail
bon courage !
PS: sur ce site annoncant encoding="macintosh", toujours certains accents
qui passent mal dans Opera...
@+
--
rm
Pierre Goiffon
>> Ayant parcouru le RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt>, il me
>> semble qu'il suffit d'encoder la valeur au format MIME, soit en QP soit
>> en Base64, par exemple comme ceci : <http://www.miakinen.net/tmp/mailto>.
>
> Oui mais non, car comme dit dans un autre message, la définition d'un
> jeu de caractères et d'un type MIME dans les en-têtes est supposée ne
> concerner que le corps du mail, pas les en-têtes, et ce d'autant plus
> que l'ordre de description des champs d'en-têtes n'est pas prédéfini,
> tandis que sa lecture par le logiciel client recevant le mail est
> séquentiel.
On en parlait dans la discussion initiale (message de départ :
<fantome.forums.tDeConte...@nnrp1-2.proxad.net>), la
RFC 2047 définit un moyen d'utiliser des caractères or us-ascii dans les
entètes, sans utiliser les content-type et autres entètes associés qui
eux, ne concernent bien que le contenu.
En utilisant le codage définit par la RFC, l'entête contient le contenu
et tout ce qu'il faut pour permettre de lire correctement ce qu'il
contient. Voir les exemples au chapitre 8, en particulier le 1er, très
clair :
http://www.ietf.org/rfc/rfc2047.txt
Olivier Miakinen
>
> Au delà du conseil avisé d'Aurélien (alias Bobe) d'encoder la chose sous
> forme d'URL (remplacer les caractères non ASCII par des %xx), je crains
> que résoudre ce problème ne s'apparente à la quadrature du cercle.
Après les premiers tests, *puis* la lecture des RFC (je sais, j'aurais
dû faire l'inverse, mais je suis feignant), il s'avère que le conseil
d'Aurélien ne résoud rien, car la table utilisée pour les caractères %xx
n'est normalisée *que* pour us-ascii. Selon le courrielleur utilisé, les
octets peuvent être interprétés comme de l'UTF-8, ou de l'ISO-8850-1, ou
n'importe quoi d'autre ! La norme pour HTML 4.01 recommande que ce soit
de l'UTF-8, mais sans rien imposer... et cela d'autant moins quand il
s'agit d'un lien mailto !
http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.1
http://www.la-grange.net/w3c/html4.01/appendix/notes.html#h-B.2.1
>> Ayant parcouru le RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt>, il me
>> semble qu'il suffit d'encoder la valeur au format MIME, soit en QP soit
>> en Base64, par exemple comme ceci : <http://www.miakinen.net/tmp/mailto>.
>
> Oui mais non, car comme dit dans un autre message, la définition d'un
> jeu de caractères et d'un type MIME dans les en-têtes est supposée ne
> concerner que le corps du mail, pas les en-têtes, et ce d'autant plus
> que l'ordre de description des champs d'en-têtes n'est pas prédéfini,
> tandis que sa lecture par le logiciel client recevant le mail est
> séquentiel.
Nous sommes d'accord, et justement c'est ce que je disais et ce dont
j'ai tenu compte sur la page en question.
> Ainsi, si le champ « Subject: » précède les champs :
>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 8bit
>
> Il y a de grandes chances, sauf si l'encodage du sujet correspond aux
> paramétrages par défaut du logiciel client, que ces éléments ne soient
> pas pris en compte et que le champ « Subject: » ne soit pas correctement
> affiché.
En l'occurrence, je précisais *dans* le champ Subject l'encodage utilisé
*pour* le champ Subject, encodage qui peut parfaitement n'avoir rien à
voir avec celui spécifié dans Content-Type et Content-Transfer-Encoding.
> S'il appartient au logiciel d'envoi (ici un script PHP si j'ai bien
> suivi) d'indiquer des champs d'en-têtes corrects, la restitution
> correcte des en-têtes en question (champ « Subject: » compris) dépendra
> uniquement du client de courrier et de son paramétrage par défaut.
Tout d'abord ce n'est pas un script PHP mais juste un lien <a href...>
dans une page HTML statique, et on ne demande rien au client de courrier
sinon de transmettre tels quels les octets spécifiés. En fait, on lui
demande un peu plus si c'était possible, et c'est de décoder le champ
Subject pour l'afficher de façon plus lisible dans la fenêtre d'édition.
>> Et si ce n'était pas le cas, j'aimerais bien que ceux qui le veulent se
>> livrent au petit test de <http://www.miakinen.net/tmp/mailto>.
>
> Je viens d'essayer depuis FireFox avec Pegasus Mail, chargé d'envoyer
> tous mes courriers.
>
> Avec ton premier lien j'obtiens :
>
> To: test%2Bmailto%40miakinen.net
Ça c'est dommage car spécifié dans les RFC.
> Subject: =?ISO-8859-1?Q?Gr=E2ce_=E0_QP?=
Là il se contente d'afficher ce qu'on lui a transmis, sans interpréter
le QP (alors qu'il l'affiche probablement comme il faut en réception).
> (Pegasus présume d'un encodage en QP et affichera probablement
> correctement le sujet en réception)
Oui pour la fin de ta phrase, non pour le début : il ne présume rien,
justement, sinon que c'est de l'ASCII.
> Avec le second j'ai :
>
> To: test%2Bmailto%40miakinen.net
> Subject: Grâce à % avec+ou+sans++
Cf. Le début du présent article : ton courrielleur a interprété les
%NN comme si c'était du Latin1 et pas de l'UTF-8.
D'autre part il est étonnant que Pegasus comprenne les %NN dans le champ
Subject et pas dans l'adresse du destinataire. Cela fonctionnerait sans
doute mieux si j'avais utilisé la syntaxe "?to=...&subject=..." au lieu
de "...?subject=...".
> PS: Veux-tu que je t'expédies de vrais courriers ou la vue des en-têtes
> générées te suffit-elle ?
Je veux bien les vrais courriers, car j'ai eu parfois des surprises (par
exemple, dans Netscape 4, un « Grâce à » qui se transformait comme par
magie en « Grâce à » alors qu'il était transmis en QP Latin1).
moi
Le contenu du champ objet à la réception (à l'émission voir ce que dit
ED plus haut) est correct: Grâce à QP
L'affichage des en-têtes donne pour le champ objet :
Subject: =?ISO-8859-1?Q?Gr=E2ce_=E0_QP?=
Voilà voilà
A+
Bobe
>
> Je voulais dire ça (exemple dans les entêtes de ton article) :
> ----------
> MIME-Version: 1.0
> Content-Type: text/plain; charset=ISO-8859-15; format=flowed
> Content-Transfer-Encoding: 8bit
> ----------
> (d'autres possibilités sont : 7bit, quoted-printable et base64).
>
Ah, mais là, c'est autre chose, ça concerne l'encodage de transfert du
corps de l'email, non des en-têtes. Et cet encodage là est choisi au
niveau du client mail.
>
> Je croyais ne pas être d'accord avec ton « dans le jeu de caractères
> du système » parce que j'ai d'abord imaginé que tu parlais des « â »,
> « à », « € », etc. Mais en fait tu as certainement raison, maintenant
> que j'ai compris que cela s'applique aux caractères ASCII, à transcoder
> si le système fonctionne en EBCDIC.
>
C'est pourtant bien ce que j'entendais par là. Que le navigateur en
l'occurrence, décode les %XX, convertisse la chaîne dans l'encodage
local et passe le tout au client mail invoqué.
Mais ça ne doit pas être aussi simple (malheureusement), car je crois
que l'encodage local sur Windows est Windows-1252, alors que sur mon
système (Ubuntu), c'est utf-8. On oublie vite ces problématiques
d'encodage quand on est soi-même sur un système basé sur l'utf-8 :)
Bref, un sujet comportant par exemple des caractères grecs ne pourrait
en aucun cas être passé correctement au client mail dans mon hypothèse
:/. Donc en fait, j'ignore comment, et ça m'intrigue, font les couples
navigateur + client mail ayant passé avec succés ton test malgré que le
système soit Windows (dans le cas de rm par exemple, voir dans les
messages précédents).
--
Aurélien Maille
Bobe
>
> Donc en fait, j'ignore comment, et ça m'intrigue, font les couples
> navigateur + client mail ayant passé avec succés ton test malgré que le
> système soit Windows (dans le cas de rm par exemple, voir dans les
> messages précédents).
>
Pas les résultats donnés par rm, suis-je bête, ils concernent le premier
lien uniquement.
--
Aurélien Maille
Nicolas Krebs
news:dv4bk1$22s2$1...@cabale.usenet-fr.net
> Dans fciwa et fciwn, Thomas de Contes demandait comment préremplir le
> sujet d'un courriel au moyen d'un lien mailto, et plus particuličrement
> comment mettre autre chose que de l'ASCII 7 bits dans ce champ.
>
> Ayant parcouru le RFC 2368 <http://www.ietf.org/rfc/rfc2368.txt>, il me
> semble qu'il suffit d'encoder la valeur au format MIME, soit en QP soit
> en Base64, par exemple comme ceci : <http://www.miakinen.net/tmp/mailto>.
Voir l'article de Daniel Glazman, « Ad???????? », Glazblog, 2006-03-17,
http://www.glazman.org/weblog/dotclear/?2006/03/17/1634 (y compris l'image
illustrative http://www.glazman.org/weblog/dotclear/images/TC/adherezPS.gif ).