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.
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.
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.
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>.
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>.
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>.
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).
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).
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 +.
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 +.
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 +.
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>.
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>.
(OS + navigateur web + courrielleur) !
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>.
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>.
(OS + navigateur web + courrielleur) !
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>.
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>.
(OS + navigateur web + courrielleur) !
est ce que tu pourrais tester tout ca avec
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 :-) )
est ce que tu pourrais tester tout ca avec
<fantome.forums.tDeContes-70618A.10280413032006@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 :-) )
est ce que tu pourrais tester tout ca avec
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 :-) )
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.
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.
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.
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âce_à_QP?
Là il se contente d'afficher ce qu'on lui a transmis, sans interpréter
(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++
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 ?
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âce_à_QP?
Là il se contente d'afficher ce qu'on lui a transmis, sans interpréter
(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++
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 ?
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âce_à_QP?
Là il se contente d'afficher ce qu'on lui a transmis, sans interpréter
(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++
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 ?
dans (in) fr.comp.mail, Olivier Miakinen <om+
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âce_à_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 ?
Test avec FF1.5 et Pegasus Mail 4.31:
dans (in) fr.comp.mail, Olivier Miakinen <om+news@miakinen.net>
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âce_à_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 ?
Test avec FF1.5 et Pegasus Mail 4.31:
dans (in) fr.comp.mail, Olivier Miakinen <om+
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âce_à_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 ?
Test avec FF1.5 et Pegasus Mail 4.31:
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).
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.
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).
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.
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).
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.