"Olivier" == Olivier Ciret olivier.ciret@alcatel.fr writes:
Olivier> Voici l'exemple de mail que je recois en lecture avec Olivier> Netscape messenger qui reste assez dur a lire.
Olivier> Xavier Venient wrote: >> Olivier Ciret a tapot=E9 : > Serait-il possible de ne pas >> utiliser les accents sur la liste (comme > sur toutes les >> listes de diffusion). J'ai un peu de mal a dechiffrer. >> >> Sur une liste de diffusion francophone, qui se veut en plus une >> liste de traduction, h=E9 bien nous pouvons montrer le bon >> exemple en =E9crivant fran=E7ais. Av=E9 les accents, donc. >> Le problème c'est que le mail est sensé être en iso-8859-1 (comme spécifié dans l'en-tête de mail (Content-Type: text/plain; charset=iso-8859-1), mais que les caractères spéciaux sont codés comme en mime i.e : =E9 pour é etc.
Je ne sais pas d'où ça peut venir.
A+
Olivier.
Afficher les réponses par date
On Fri, May 11, 2001 at 11:10:04AM +0200, Olivier wrote:
"Olivier" == Olivier Ciret olivier.ciret@alcatel.fr writes:
Olivier> Voici l'exemple de mail que je recois en lecture avec Olivier> Netscape messenger qui reste assez dur a lire. Olivier> Xavier Venient wrote: >> Olivier Ciret a tapot=E9 : > Serait-il possible de ne pas >> utiliser les accents sur la liste (comme > sur toutes les >> listes de diffusion). J'ai un peu de mal a dechiffrer. >> >> Sur une liste de diffusion francophone, qui se veut en plus une >> liste de traduction, h=E9 bien nous pouvons montrer le bon >> exemple en =E9crivant fran=E7ais. Av=E9 les accents, donc. >>Le problème c'est que le mail est sensé être en iso-8859-1 (comme spécifié dans l'en-tête de mail (Content-Type: text/plain; charset=iso-8859-1), mais que les caractères spéciaux sont codés comme en mime i.e : =E9 pour é etc.
Non, le mail original de Dominique était envoyé avec une vieille version de KMail et ne contenait que le Content-Type: text/plain sans charset. Dans ce temps-là, c'est souvent considéré comme du us-ascii alors que c'était bien du iso-8859-1. Peut-être qu'une version plus récente de KMail ira mieux. Sinon, considérez avertir les auteurs du problème (c'est facile à régler, suffit d'ajouter le charset obtenu à partir de la police de caractère utilisée couramment).
Et puis, remplacer les caractères non-imprimables par un ? ou par la version "quoted-printable" est un bon comportement, évitant de détruire un écran pour rien.
Je ne sais pas d'où ça peut venir.
A+
Olivier.
[Cc sabré]
The Sat, May 12, 2001 at 01:35:24PM -0400, Fabien Ninoles wrote :
Non, le mail original de Dominique était envoyé avec une vieille version de KMail et ne contenait que le Content-Type: text/plain sans charset. Dans ce temps-là, c'est souvent considéré comme du us-ascii alors que c'était bien du iso-8859-1. Peut-être qu'une version plus récente de
^^^^^^^^^^ La formulation exacte serait plutôt: [...] Dans ce temps-là, c'est souvent considéré comme du us-ascii alors que ça n'en est pas.
Je m'explique: Compte tenu de ce que certains ont vu, il est clair que le codage du message reçu évoquait le quoted-printable. L'absence de charset dans le message ne gène pas sendmail qui remarque qu'il est en présence d'en-têtes foobarisés et convertit courageusement les données de qp ou de base64 en 8bits. Pour ce faire il n'a pas besoin de charset: il repère le Content-Transfer-Encoding, vomit du 8bits et le MUA se débrouille (-> bien car on a tous le bon charset). Il n'y a priori pas de lien entre le type des données et l'encodage pour le transfert (à peut-être une exception près, cf + loin). On note que l'équation "pas de charset = us-ascii" n'est pas fameuse car la présence d'un Content-Transfer-Encoding type qp ou base64 claironne l'arrivée de données qui représentent autre chose que du 7bit (il est tout à fait licite de coder du 7bits en base64 ou en quoted-printable mais ça présente tellement peu d'intérêt que je vois mal qui coderait un truc aussi shadock, cf rfc2045). Je pense que dans le message d'origine figurait au moins un Content-Transfer-Encoding et que sendmail n'a quand même pas poussé le vice jusqu'à se baser sur la présence de séquences licites en qp ou sur l'allure du flot pour effectuer une conversion depuis le base64 ou le qp (là j'ai envie d'aller prendre une bière, pas de me plonger dans le code de sendmail pour comprendre le sens de la vie donc je laisse cette question en l'air). Dans le cas où le MTA n'a rien fait, Netscape n'y a vu que du feu et a gaiement affiché du qp (ça c'est de la gestion du MIME).
Moralité: C'est bien la peine d'écrire avec amour de superbes sendmail.cf pour que des MUA foireux échangent du n'importe quoi :o(
On Sat, May 12, 2001 at 10:15:31PM +0200, Francois Romieu wrote:
[Cc sabré]
The Sat, May 12, 2001 at 01:35:24PM -0400, Fabien Ninoles wrote :
Non, le mail original de Dominique était envoyé avec une vieille version de KMail et ne contenait que le Content-Type: text/plain sans charset. Dans ce temps-là, c'est souvent considéré comme du us-ascii alors que c'était bien du iso-8859-1. Peut-être qu'une version plus récente de
^^^^^^^^^^La formulation exacte serait plutôt: [...] Dans ce temps-là, c'est souvent considéré comme du us-ascii alors que ça n'en est pas.
Euh, oui, bon. C'est bien ce que je voulais dire si on généralise mais la formulation est quand même exacte puisque mon exemple était spécifique. Remarquez que plusieurs MUA s'en foutent éperduement et affichent quand même les caractères, que ce soit du iso-8859-1, des séquences d'échappement ANSI ou des virus VBS...
Moralité: C'est bien la peine d'écrire avec amour de superbes sendmail.cf pour que des MUA foireux échangent du n'importe quoi :o(
Morale de la Moralité: "Boguez" (orth?) donc les auteurs de vos MUA pour qu'ils ajoutent toujours le charset sur un text/plain (s'ils ne le font pas déjà). ;)
-- Ueimor
-
fabien＠Nightbird.TZoNE.ORG -
Francois Romieu -
Olivier