J'envoie des mails en utf-8, qui sont visibles comme il faut sous
thunderbird.
Par contre, Outlook (j'ai testé sur le 2003) me mets des points
d'interrogations à la place de mes caractères en utf8.
Je mets dans le header :
"Content-Type: text/plain; charset=utf-8\n";
"Content-Transfer-Encoding: 8bit\n\n";
Est-ce un problème typique Microsoft ou est-ce mon entête qui n'est pas
complète ?
Si ça vient de MS, suis-je obligé de passer par de l'html pour obtenir
de l'utf8 sur le client ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
yamo'
Salut, Olivier Masson a tapoté, le 28.01.2009 12:43:
Est-ce un problème typique Microsoft ou est-ce mon entête qui n'est pas complète ?
Ça doit provenir d'autre chose, avec outlook 2003 je peux lire de l'utf-8 mais en quoted-printable (je ne sais pas comment éviter ce quoted-printable certainement mis par un serveur).
Stéphane -- <http://pasdenom.info>
Salut,
Olivier Masson a tapoté, le 28.01.2009 12:43:
Est-ce un problème typique Microsoft ou est-ce mon entête qui n'est pas
complète ?
Ça doit provenir d'autre chose, avec outlook 2003 je peux lire de
l'utf-8 mais en quoted-printable (je ne sais pas comment éviter ce
quoted-printable certainement mis par un serveur).
Salut, Olivier Masson a tapoté, le 28.01.2009 12:43:
Est-ce un problème typique Microsoft ou est-ce mon entête qui n'est pas complète ?
Ça doit provenir d'autre chose, avec outlook 2003 je peux lire de l'utf-8 mais en quoted-printable (je ne sais pas comment éviter ce quoted-printable certainement mis par un serveur).
Stéphane -- <http://pasdenom.info>
Olivier Masson
yamo' a écrit :
Ça doit provenir d'autre chose, avec outlook 2003 je peux lire de l'utf-8 mais en quoted-printable (je ne sais pas comment éviter ce quoted-printable certainement mis par un serveur).
Stéphane
En fait il s'agit d'une erreur dans mon protocole de test : j'étais en imap sous Outlook. Donc ce qui pose problème, c'est l'utf-8 en imap sur cette bouse. Et ça, je m'en fous (faut pas pousser) :)
yamo' a écrit :
Ça doit provenir d'autre chose, avec outlook 2003 je peux lire de
l'utf-8 mais en quoted-printable (je ne sais pas comment éviter ce
quoted-printable certainement mis par un serveur).
Stéphane
En fait il s'agit d'une erreur dans mon protocole de test : j'étais en
imap sous Outlook.
Donc ce qui pose problème, c'est l'utf-8 en imap sur cette bouse. Et ça,
je m'en fous (faut pas pousser) :)
Ça doit provenir d'autre chose, avec outlook 2003 je peux lire de l'utf-8 mais en quoted-printable (je ne sais pas comment éviter ce quoted-printable certainement mis par un serveur).
Stéphane
En fait il s'agit d'une erreur dans mon protocole de test : j'étais en imap sous Outlook. Donc ce qui pose problème, c'est l'utf-8 en imap sur cette bouse. Et ça, je m'en fous (faut pas pousser) :)
Olivier Miakinen
Le 28/01/2009 12:43, Olivier Masson a écrit :
Je mets dans le header : "Content-Type: text/plain; charset=utf-8n"; "Content-Transfer-Encoding: 8bitnn";
Pour mémoire, n'oublie pas : "MIME-Version: 1.0n"
Le 28/01/2009 12:43, Olivier Masson a écrit :
Je mets dans le header :
"Content-Type: text/plain; charset=utf-8n";
"Content-Transfer-Encoding: 8bitnn";
D'après la norme, c'est indispensable. Je ne sais pas quel est le comportement réel de la plupart des courrielleurs à ce propos, mais en principe un message qui ne contient pas de MIME-Version n'est pas censé contenir de Content-Type ou de Content-Transfer-Encoding, et donc il est censé être en ASCII 7 bits.
Le 29/01/2009 11:07, Olivier Masson a écrit :
Pour mémoire, n'oublie pas :
"MIME-Version: 1.0n"
Ah, c'est important ?
D'après la norme, c'est indispensable. Je ne sais pas quel est le
comportement réel de la plupart des courrielleurs à ce propos, mais en
principe un message qui ne contient pas de MIME-Version n'est pas censé
contenir de Content-Type ou de Content-Transfer-Encoding, et donc il est
censé être en ASCII 7 bits.
D'après la norme, c'est indispensable. Je ne sais pas quel est le comportement réel de la plupart des courrielleurs à ce propos, mais en principe un message qui ne contient pas de MIME-Version n'est pas censé contenir de Content-Type ou de Content-Transfer-Encoding, et donc il est censé être en ASCII 7 bits.
Olivier Miakinen
Le 29/01/2009 11:56, je répondais à Olivier Masson :
Pour mémoire, n'oublie pas : "MIME-Version: 1.0n"
Ah, c'est important ?
D'après la norme, c'est indispensable.
Je viens de relire ce qui concerne l'entête MIME-Version dans le chapitre 4 de <http://www.ietf.org/rfc/rfc2045.txt>, et je confirme qu'il est indispensable :
<cit.> In the absence of a MIME-Version field, a receiving mail user agent (whether conforming to MIME requirements or not) may optionally choose to interpret the body of the message according to local conventions. Many such conventions are currently in use and it should be noted that in practice non-MIME messages can contain just about anything. </cit.>
[...] en principe un message qui ne contient pas de MIME-Version n'est pas censé contenir de Content-Type ou de Content-Transfer-Encoding, et donc il est censé être en ASCII 7 bits.
En revanche, ceci contredit le fait que ça doive être obligatoirement de l'ASCII 7 bits :
<cit.> It is impossible to be certain that a non-MIME mail message is actually plain text in the US-ASCII character set since it might well be a message that, using some set of nonstandard local conventions that predate MIME, includes text in another character set or non- textual data presented in a manner that cannot be automatically recognized (e.g., a uuencoded compressed UNIX tar file). </cit.>
Quoi qu'il en soit, il faut absolument mettre cet entête.
Le 29/01/2009 11:56, je répondais à Olivier Masson :
Pour mémoire, n'oublie pas :
"MIME-Version: 1.0n"
Ah, c'est important ?
D'après la norme, c'est indispensable.
Je viens de relire ce qui concerne l'entête MIME-Version dans le
chapitre 4 de <http://www.ietf.org/rfc/rfc2045.txt>, et je confirme
qu'il est indispensable :
<cit.>
In the absence of a MIME-Version field, a receiving mail user agent
(whether conforming to MIME requirements or not) may optionally
choose to interpret the body of the message according to local
conventions. Many such conventions are currently in use and it
should be noted that in practice non-MIME messages can contain just
about anything.
</cit.>
[...]
en principe un message qui ne contient pas de MIME-Version n'est pas censé
contenir de Content-Type ou de Content-Transfer-Encoding, et donc il est
censé être en ASCII 7 bits.
En revanche, ceci contredit le fait que ça doive être obligatoirement de
l'ASCII 7 bits :
<cit.>
It is impossible to be certain that a non-MIME mail message is
actually plain text in the US-ASCII character set since it might well
be a message that, using some set of nonstandard local conventions
that predate MIME, includes text in another character set or non-
textual data presented in a manner that cannot be automatically
recognized (e.g., a uuencoded compressed UNIX tar file).
</cit.>
Quoi qu'il en soit, il faut absolument mettre cet entête.
Le 29/01/2009 11:56, je répondais à Olivier Masson :
Pour mémoire, n'oublie pas : "MIME-Version: 1.0n"
Ah, c'est important ?
D'après la norme, c'est indispensable.
Je viens de relire ce qui concerne l'entête MIME-Version dans le chapitre 4 de <http://www.ietf.org/rfc/rfc2045.txt>, et je confirme qu'il est indispensable :
<cit.> In the absence of a MIME-Version field, a receiving mail user agent (whether conforming to MIME requirements or not) may optionally choose to interpret the body of the message according to local conventions. Many such conventions are currently in use and it should be noted that in practice non-MIME messages can contain just about anything. </cit.>
[...] en principe un message qui ne contient pas de MIME-Version n'est pas censé contenir de Content-Type ou de Content-Transfer-Encoding, et donc il est censé être en ASCII 7 bits.
En revanche, ceci contredit le fait que ça doive être obligatoirement de l'ASCII 7 bits :
<cit.> It is impossible to be certain that a non-MIME mail message is actually plain text in the US-ASCII character set since it might well be a message that, using some set of nonstandard local conventions that predate MIME, includes text in another character set or non- textual data presented in a manner that cannot be automatically recognized (e.g., a uuencoded compressed UNIX tar file). </cit.>
Quoi qu'il en soit, il faut absolument mettre cet entête.
Olivier Masson
Olivier Miakinen a écrit :
Quoi qu'il en soit, il faut absolument mettre cet entête.
Merci de me le dire, car je ne le spécifiais jamais. Et après je râle de recevoir un paquet de malformed header et autres dans amavis...
Olivier Miakinen a écrit :
Quoi qu'il en soit, il faut absolument mettre cet entête.
Merci de me le dire, car je ne le spécifiais jamais.
Et après je râle de recevoir un paquet de malformed header et autres
dans amavis...
