Accéder au contenu.
Menu Sympa

technique - Re: [TECH] Pb de codage de caractères

Objet : Liste pour les discussions techniques (liste à inscription publique)

Archives de la liste

Re: [TECH] Pb de codage de caractères


Chronologique Discussions 
  • From: Patrice Pillot <patrice.pillot AT asm.map.archi.fr>
  • To: technique AT april.org
  • Cc: colin AT geekounet.org, patrice.pillot AT teletopie.net, Patrice Pillot <patrice.pillot AT asm.map.archi.fr>
  • Subject: Re: [TECH] Pb de codage de caractères
  • Date: Tue, 27 Jun 2006 12:57:15 +0200

Bonjour,

Colin Leroy wrote:
On 23 June 2006 at 00h06, Ludovic Pénet wrote:
Pas mal de mes correspondants me signalent un pb de codage des
caractères de mes mails.

Ce mail est correctement codé en tout cas. Si tes correspondants
utilisent Thunderbird comme Patrice Pillot, dans le mail duquel le
sujet est broyé (par Thunderbird), c'est peut-être plutôt lui le
coupable.

Colin a tout à fait raison d'invoquer la responsabilité des MUA des correspondants, mais celà l'amène à des conclusions un peu hardies ;-)

Le sujet de ma réponse (telle que je l'ai reçu, je ne sais si c'est le cas de tous, cf. infra) était en effet encodé de manière calamiteuse puisque le "è" (en UTF8 encodé en quoted-printable) était "escapé" par un trompeur 8859-1 :
Subject: Re: [TECH] Pb de codage de =?ISO-8859-1?Q?caract=C3=A8res?=

Fort marri de cette découverte j'ai un peu investigué la question et il appert que ThunderBird n'est pas à blamer dans l'affaire. Voici comment TBird réagit par défaut dans ma configuration (qui, au jeu de caractères près, est tout à fait standard) :

Mon jeu de caractères par défaut est l'UTF-8. À réception d'un message dans un autre jeu de caractères, ma réponse utilise néanmoins, par défaut, celui du message original. Le message est ensuite émis avec les headers suivants :
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

ou ISO-8859-1, etc... plutôt que UTF-8, etc.

Dans ma réponse à Ludovic, j'ai néanmoins forcé le jeu de caractère à UTF-8 (car je sais très bien que c'est le genre de truc qui pose encore régulièrement problème, malheureusement).
Et les headers de ma boîte d'envoi donnent bien :

Subject: Re: [TECH] Pb de codage de =?UTF-8?B?Y2FyYWN0w6hyZXM=?=
References: <1151017050.5077.70.camel@catherine>
In-Reply-To: <1151017050.5077.70.camel@catherine>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Tous les autres caractères accentués étant bien encodés en UTF-8.

J'ai donc bien au départ un message conforme à 2822 et 2045 et 2047, cohérent qui plus est.

Alors comment expliquer qu'il soit arrivé dans les boîtes des lecteurs (ou de certains d'entre-eux) avec ce header :
Subject: Re: [TECH] Pb de codage de =?ISO-8859-1?Q?caract=C3=A8res?=

et le reste encapsulé dans un "multi-part message" ? TBird aurait-il un comportement non déterministe ?

Non, il y a seulement qu'entre nous les messages transitent par le robot de la liste (qui réalise apparement l'encapsulation MIME, au moins) et certains serveurs qui font... ce qu'on leur a dit de faire. Dans mon cas (et je ne suis sans doute pas le seul), le courrier entrant est au moins, malheureusement, malaxé par mon serveur smtp qui passe une moulinette quoted-printable là où il le souhaite, ce qui est montré par le header suivant :
X-MIME-Autoconverted: from 8bit to quoted-printable by smtp2.cict.fr id k5NAbELm005669
(Le pire c'est que c'est ESMTP qui tourne et qu'il sait gérer la rfc2047...)

Alors à quel moment est-ce que le message a-t-il été mal mouliné ? smtp sortant, robot, smtp d'april, mta local ? Difficile à dire. En tous cas tous les tests (avec alternativement mon smtp du boulot -ESMTP- et celui de mon FAI -exim4) que j'ai pu faire jusqu'à présent sans passer par le robot de la liste, m'ont laissé les messages (et donc les headers) tels qu'émis par TBird

Pour en savoir plus, à tout hasard, je force à nouveau le jeu de caractères de cette réponse à UTF-8 mais je me mets ainsi que Colin (s'il accepte de se prêter au jeu) en copie histoire de pouvoir comparer les headers.

Tout ceci montre bien en tous les cas que les renseignments fournis par Ludovic sont un peu insuffisants pour l'aider à résoudre son problème ;-) .

Cordialement,

Patrice








Archives gérées par MHonArc 2.6.16.

Haut de le page