Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Probl=c3=a8me d'encodage =3f

8 réponses
Avatar
pehache
Bonjour,

Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ?
Les caractères accentués dans la partie HTML apparaissent correctement
chez la plupart des destinataires, mais pas tous... Et bizarremment
uniquement depuis un changement de SMTP (c'est une newsletter).


=====================================================================

MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_bbb1f465d410c161fd408c7513182b31"

This is a message in Mime Format. If you see this, your mail reader
does not support this format.

--=_bbb1f465d410c161fd408c7513182b31
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><meta http-equiv="Content-Type" content="text/html;
charset=UTF-8"><title>xxxxxxxxxxxxxxxxxxxxx</title><style
type="text/css">body, #general {
margin:0;
padding:0;
background-color: #1E72B2;
font-size:12px;
font-family: Arial, Helvetica, sans-serif;
text-align: justify;
}
...
...
...
...
</html>

--=_bbb1f465d410c161fd408c7513182b31--

=====================================================================

8 réponses

Avatar
Olivier Miakinen
Le 23/05/2017 23:40, pehache a écrit :
Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ?
Les caractères accentués dans la partie HTML apparaissent correctement
chez la plupart des destinataires, mais pas tous... Et bizarremment
uniquement depuis un changement de SMTP (c'est une newsletter).

Voyons voir...
==================================================================== >
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_bbb1f465d410c161fd408c7513182b31"
This is a message in Mime Format. If you see this, your mail reader
does not support this format.
--=_bbb1f465d410c161fd408c7513182b31

Jusque là ça me semble correct.
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

???
Il y a du HTML, alors que ça devrait être du « text/plain ». Qui plus
est, vu qu'aucun charset n'est annoncé, ça doit être de l'ASCII et
l'encodage 7bit devrait suffire.
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><meta http-equiv="Content-Type" content="text/html;
charset=UTF-8"><title>xxxxxxxxxxxxxxxxxxxxx</title><style

Ici il est annoncé de l'UTF-8.
Et donc, au lieu de :
Content-Type: text/plain
il faudrait :
Content-Type: text/html; charset=UTF-8
Conclusion : pas casher du tout. Non seulement à cause des caractères
accentués, mais aussi et surtout les courrielleurs qui interprètent ce
message comme du HTML ont tort.
--
Olivier Miakinen
Avatar
pehache
Le 25/05/2017 à 22:02, Olivier Miakinen a écrit :
Le 23/05/2017 23:40, pehache a écrit :
Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ?
Les caractères accentués dans la partie HTML apparaissent correctement
chez la plupart des destinataires, mais pas tous... Et bizarremment
uniquement depuis un changement de SMTP (c'est une newsletter).

Voyons voir...
==================================================================== >>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_bbb1f465d410c161fd408c7513182b31"
This is a message in Mime Format. If you see this, your mail reader
does not support this format.
--=_bbb1f465d410c161fd408c7513182b31

Jusque là ça me semble correct.
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

???
Il y a du HTML, alors que ça devrait être du « text/plain ». Qui plus
est, vu qu'aucun charset n'est annoncé, ça doit être de l'ASCII et
l'encodage 7bit devrait suffire.
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><meta http-equiv="Content-Type" content="text/html;
charset=UTF-8"><title>xxxxxxxxxxxxxxxxxxxxx</title><style

Ici il est annoncé de l'UTF-8.
Et donc, au lieu de :
Content-Type: text/plain
il faudrait :
Content-Type: text/html; charset=UTF-8
Conclusion : pas casher du tout. Non seulement à cause des caractères
accentués, mais aussi et surtout les courrielleurs qui interprètent ce
message comme du HTML ont tort.

OK merci. Ca me semblait curieux aussi, même si je me disais que
l'entête HTML prenait peut-être le pas sur ce qui précédait.
C'est dans une newsletter d'association, gérée par un prestataire dont
la compétence me parait de plus en plus douteuse... les gars ont déjà
réussi à se griller auprès d'OVH (et à nous griller par ricochet) en ne
gérant pas les bounces donc sans jamais nettoyer notre base d'abonnés
des adresses en erreur, jusqu'au moment où OVH a tout bloqué vu les taux
d'erreurs. Ils ne savaient pas non plus qu'il fallait des enregistrement
SPF et DKIM sur le nom de domaine pour optimiser la distribution...
Avatar
pehache
Le 23/05/2017 à 23:40, pehache a écrit :
Bonjour,
Est-ce que la façon dont est codé le mail ci-dessous est casher ou pas ?
Les caractères accentués dans la partie HTML apparaissent correctement
chez la plupart des destinataires, mais pas tous... Et bizarremment
uniquement depuis un changement de SMTP (c'est une newsletter).

Un truc que j'avais complètement zappé c'est qu'il y a deux blocs MIME
qui se suivent et qui ont des contenus rigoureusement identiques, à part
que le premier est déclaré en texte brut, et le second en HTML (mais
toujours sans charset déclaré).
C'est censé être interprété comment, ça ?? Dans les mails reçu je ne
vois qu'une fois le contenu, pas deux.
Pour info, ils ont ajouté "charset=UTF-8" au Content-Type du second bloc
(celui déclaré en HTML) et ça semble avoir résolu le problème des
caractères mal décodés.
================================================================
.
.
.
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_6fc4b161d4938105579eb4211e64e434"
.
.
.
This is a message in Mime Format. If you see this, your mail reader
does not support this format.
--=_6fc4b161d4938105579eb4211e64e434
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><meta http-equiv="Content-Type" content="text/html;
charset=UTF-8"><title>xxxxxxxxxx</title><style type="text/css">body,
#general {
margin:0;
padding:0;
background-color: #1E72B2;
font-size:12px;
font-family: Arial, Helvetica, sans-serif;
text-align: justify;
}
.
.
.
</html>
--=_6fc4b161d4938105579eb4211e64e434
Content-Type: text/html
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html><head><meta http-equiv="Content-Type" content="text/html;
charset=UTF-8"><title>xxxxxxxxxx</title><style type="text/css">body,
#general {
margin:0;
padding:0;
background-color: #1E72B2;
font-size:12px;
font-family: Arial, Helvetica, sans-serif;
text-align: justify;
}
.
.
.
</html>
--=_6fc4b161d4938105579eb4211e64e434--
Avatar
Olivier Miakinen
Bonjour,
Le 30/05/2017 14:05, pehache a écrit :
Un truc que j'avais complètement zappé c'est qu'il y a deux blocs MIME
qui se suivent et qui ont des contenus rigoureusement identiques, à part
que le premier est déclaré en texte brut, et le second en HTML (mais
toujours sans charset déclaré).

Ah, ben si tu ne donnes pas toutes les infos, aussi ! ;-)
C'est censé être interprété comment, ça ?? Dans les mails reçu je ne
vois qu'une fois le contenu, pas deux.

Au plus haut niveau, tu as un Content-Type: multipart/alternative,
ce qui signifie que le courrielleur du destinataire choisira le
contenu correspondant en principe à ce que le lecteur humain
préfère voir.
Dans sa configuration par défaut, Thunderbird affiche de préférence
la partie en text/html, et la partie en text/plain est alors ignorée.
Moi qui préfère réserver le HTML aux sites web et voir les courriels
sans mickeys qui clignotent, je choisis de n'afficher que du texte
simple. Du coup, Thunderbird affiche de préférence la partie en
text/plain et ignore celle en text/html. S'il n'y a que du text/html,
Thunderbird en extrait le texte et ignore la mise en page.
Pour voir ce que cela donne toi-même :
Affichage > Corps du message en > Texte seul
C'est vraiment un réglage que je conseille à tous, d'autant que
souvent cela permet de ne pas être agressé par un certain nombre
de spams où la partie text/plain existe mais est vide ou constituée
du seul message « votre logiciel ne sait pas afficher du HTML ».
Il est toujours possible de revenir en mode HTML les rares fois où
cela s'avère nécessaire.
Pour info, ils ont ajouté "charset=UTF-8" au Content-Type du second bloc
(celui déclaré en HTML) et ça semble avoir résolu le problème des
caractères mal décodés.

Ça marchera donc pour ceux qui ont la configuration par défaut de la
plupart de courrielleurs récents. Mais pas pour les vieux cons comme
moi qui préfèrent l'information brute aux spams colorés.
--
Olivier Miakinen
Avatar
pehache
Le 30/05/2017 à 15:06, Olivier Miakinen a écrit :
Bonjour,
Le 30/05/2017 14:05, pehache a écrit :
Un truc que j'avais complètement zappé c'est qu'il y a deux blocs MIME
qui se suivent et qui ont des contenus rigoureusement identiques, à part
que le premier est déclaré en texte brut, et le second en HTML (mais
toujours sans charset déclaré).

Ah, ben si tu ne donnes pas toutes les infos, aussi ! ;-)

J'avais pas lu tout le source !
C'est censé être interprété comment, ça ? ? Dans les mails reçu je
ne
vois qu'une fois le contenu, pas deux.

Au plus haut niveau, tu as un Content-Type: multipart/alternative,
ce qui signifie que le courrielleur du destinataire choisira le
contenu correspondant en principe à ce que le lecteur humain
préfère voir.
Dans sa configuration par défaut, Thunderbird affiche de préférence
la partie en text/html, et la partie en text/plain est alors ignorée.
Moi qui préfère réserver le HTML aux sites web et voir les courriels
sans mickeys qui clignotent, je choisis de n'afficher que du texte
simple. Du coup, Thunderbird affiche de préférence la partie en
text/plain et ignore celle en text/html. S'il n'y a que du text/html,
Thunderbird en extrait le texte et ignore la mise en page.

OK... Bon, là vu qu'il y a bien une partie text/plain mais qu'elle
contient le code HTML, j'imagine que le lecteur qui choisit le text/plain
de préférence va en fait voir le code HTLM (?)...
Pour voir ce que cela donne toi-même :
Affichage > Corps du message en > Texte seul

Je regarderai ce soir.
Avatar
Otomatic
Olivier Miakinen <om+ écrivait :
Mais pas pour les vieux cons comme
moi qui préfèrent l'information brute aux spams colorés.

Mon courrielleur The Bat a quand même un onglet noté HTML au bas de la
fenêtre de lecture des messages.
Ça me sert de temps en temps.
--
Plastifions le tissu social pour mettre en réseau les synergies
intergénérationelles sur un plan proactif, induisant une sensibilisation
citoyenne et interactive, garantie d'un véritable dialogue pluriel !
Ministère des Partenariats Durables - Objectifs 2015-2035
Avatar
Olivier Miakinen
Le 30/05/2017 16:41, pehache a écrit :
OK... Bon, là vu qu'il y a bien une partie text/plain mais qu'elle
contient le code HTML, j'imagine que le lecteur qui choisit le text/plain
de préférence va en fait voir le code HT[ML] (?)...

C'est ce que je pense. D'ailleurs c'est ce que je t'écrivais dans
ma première réponse, en supposant que cette partie était la seule
existante : si un courrielleur affiche autre chose que le *code*
HTML quand il affiche cette partie en text/plain, il est en tort.
Pour voir ce que cela donne toi-même :
Affichage > Corps du message en > Texte seul

Je regarderai ce soir.

Tiens-nous au courant. Outre le fait que ça doit t'afficher le
code HTML avec toutes ses balises, il risque d'y avoir encore un
problème de charset puisque l'UTF-8 n'y est toujours pas déclaré.
--
Olivier Miakinen
Avatar
pehache
Le 30/05/2017 à 16:59, Olivier Miakinen a écrit :
Le 30/05/2017 16:41, pehache a écrit :
OK... Bon, là vu qu'il y a bien une partie text/plain mais qu'elle
contient le code HTML, j'imagine que le lecteur qui choisit le text/plain
de préférence va en fait voir le code HT[ML] (?)...

C'est ce que je pense. D'ailleurs c'est ce que je t'écrivais dans
ma première réponse, en supposant que cette partie était la seule
existante : si un courrielleur affiche autre chose que le *code*
HTML quand il affiche cette partie en text/plain, il est en tort.
Pour voir ce que cela donne toi-même :
Affichage > Corps du message en > Texte seul

Je regarderai ce soir.

Tiens-nous au courant. Outre le fait que ça doit t'afficher le
code HTML avec toutes ses balises, il risque d'y avoir encore un
problème de charset puisque l'UTF-8 n'y est toujours pas déclaré.

Gagné...
Tous ces gars qui bossent dans les boîte de services web ils ont fait
quoi comme études ? L'école du rire ?