Le myst=E8re des accents cryptiques...

Le protocole SMTP (Single Mail Transfert Protocol, RFC 821) était à l’origine destiné à émettre de courts textes au format US-ASCII 7 bits. L’ASCII (American Standart Code for Information Interchange) est un système quasi-universel de description des caractères.

Mais les caractères accentués et spéciaux n’y figurent pas et seront interprétés à l’écran sous forme cryptique, du style =E9 pour un « é », ou =E8 pour un « è », ce qui rend les messages difficilement lisibles... L’explication est simple : lors de la création du protocole SMTP, en 1982, les ingénieurs américains, ont tout simplement oublié les caractères diacritiques des langues européennes !

Norme ISO-8859-1

Le problème a été résolu en 1995 par l’écriture du protocole ESMTP (Extended SMTP) utilisant une table de codage ASCII 8 bits étendue à 256 caractères codables. Mais le jeu de codes étendu n’est pas universel, il dépend des plateformes matérielles (IBM, PC, Mac). Ce qui a rendu nécessaire l’adoption d’une norme internationale, ISO-8859-1 ou ISO-latin-1 pour tous les logiciels, serveurs ou clients. En général, les éditeurs de messagerie électronique (clients) sont par défaut configurés pour un fonctionnement en mode 8 bits sur la table ISO-8859-1.

Dans l’entête caché d’un mél reçu, vous pourrez lire ceci :

Received : from smtp-2.nordnet.fr (smtp-2.nordnet.fr [194.206.126.252])
by nordnetmx1.nordnet.fr (8.9.3/8.9.3) with ESMTP id SAA00832
Mime-Version : 1.0
Content-Type : text/plain ; charset="iso-8859-1"

Norme MIME

De plus, une autre norme appelée MIME (Multipurpose Internet Mail Extension, RFC 2045) permet à un logiciel client d’affecter une table de codage différente à diverses partie d’un mél, comme par exemple à un document attaché. Clients et serveurs sont donc aujourd’hui tous compatibles ESMTP-MIME, seuls des routeurs anciens peuvent corrompre votre texte en le convertissant en US-ASCII 7 bits. Si vous recevrez un texte avec des problèmes d’accentuation, il ne vous reste plus qu’à jouer à l’apprenti espion en pratiquant une conversion MIME* manuelle...

X-MIME-Autoconverted : from 8 bit to quoted-printeable

De nos jours, le code ASCII est passé à 8 bits, les tables de caractères comprennent les caractères diacritiques de toutes les langues. De plus le format universel UNICODE s’impose peu à peu pour les échanges de données sur l’internet.

Rester simple : éviter les méls au format HTML

Fin 1999 sont apparus les clients de messagerie supportant le format HTML. Ce procédé consiste a envoyer ou recevoir un mél au format MIME, avec une partie du texte en codage HTML pouvant être considérée aussi comme pièce jointe. Toutes les nouvelles versions des clients de messagerie savent aujourd’hui interpréter le code HTML inventé pour le Web (ils se comportent comme des navigateurs affichant une page web) mais l’envoi de méls dans ce format confine à l’absurde en ce sens où il démultiplie la taille d’un texte (et donc le temps de téléchargement) et opère un trou de sécurité. Une page web peut comporter un javascript ou une applette java pernicieuse. Dans l’entête caché d’un mél reçu au format HTML, vous pourrez lire ceci :

Mime-Version : 1.0 Content-Type : text/html ; charset=us-ascii

Le HTML ayant une manière propre de coder les caractères diacritiques et accentués, envoyer un mél en HTML consiste à ajouter un niveau de codage-décodage supplémentaire et à démultiplier le trafic réseau. En outre, certaines entreprises (des plus au fait des techniques de sécurité) désactivent tout simplement l’envoi et surtout la réception de méls au format HTML. Cependant, bon nombre de newsletters sont désormais et en dépit de la netiquette rédigées en HTML.

Un mél de 10 lignes de 72 caractères au format HTML peut peser le même poids qu’un mél de 100 lignes au format ASCII 8 bits ISO-8859-1.

[Mis en ligne le 4 août 2001]

Statistiques :

Identification :

Utilisateurs :

Il y a actuellement 1 utilisateur connecté.

Droits d'auteur :

Ce site est mis à disposition
sous un contrat Creative Commons :
http://creativecommons.org