Mon blog

Le format « texte brut » pour le courrier électronique a d'immenses avantages en tant que plus grand dénominateur commun. Mais certaines de ses limites sont peu acceptables aujourd'hui et ce RFC s'attaque notamment à la gestion des paragraphes et aux citations.

Le format que je préfère pour le courrier a le type MIME text/plain. Les messages de ce type, composés uniquement de texte brut sont légers, sont lisibles avec n'importe quel logiciel (même more en cas d'urgence, même si je préfère utiliser mutt) et peuvent facilement être traités par un programme écrit dans un langage quelconque. En outre, ils ne peuvent pas transporter de virus ou autres logiciels malfaisants.

Si on s'intéresse au fond de la communication et non pas à sa forme, le texte brut demeure imbattable. Ouvrez n'importe quel roman ou essai dans une librairie. Du chef d'œuvre de la littérature au dernier des romans de gare, trouve t-on du gras, du souligné, des caractères plus gros que les autres ou bien des changements de police ? Non, le texte brut suffit à tous les auteurs, de Finkielkraut à Sulitzer. Il n'est donc pas étonnant que le format MIME Text/Plain, qui identifie ce texte brut soit toujours si répandu.

Mais le texte brut a des limites. Une des plus agaçantes est la gestion des lignes trop longues. Si je ne mets pas de saut de ligne, le message sera peu lisible par les MUA les plus primitifs. Si j'en mets, cela ne peut être qu'à une taille arbitraire (on cite souvent le chiffre magique de 72 caractères), qui n'est pas forcément la taille de l'écran du lecteur. Peut-être lit-il le courrier sur un PDA avec un petit écran qui va couper les lignes une seconde fois, produisant un texte peu élégant ?

Mettant à jour le RFC 2646, qui avait normalisé le type flowed (texte qui peut être remis en forme par le MUA de lecture), notre RFC précise comment encoder le message pour qu'il soit lisible avec un logiciel de lecture « bête » tout en étant reformatable pour un affichage dans les meilleures conditions. En gros, un espace à la fin d'une ligne indique que le saut de ligne suivant est « mou » et peut être remplacé. Cela revient à introduire le concept de paragraphe, signalé, lui, par un saut de ligne qui n'est pas précédé d'un espace.

Le gros avantage de cette astucieuse technique est qu'un logiciel antérieur à ce RFC n'aura aucun problème à afficher le texte (il traitera les sauts de lignes « mous » comme des sauts de ligne ordinaires). Ce désir de compatibilité est une des caractéristiques importantes de beaucoup de normes Internet : le réseau et ses services sont désormais tellement utilisés partout qu'il n'est pas question de casser gratuitement ce qui marchait avant.

Cet encodage permet également de gérer le cas des citations, introduites par un caractère '>'.

À noter que, pour que mon MUA, mutt, me permette d'afficher ces messages en les formattant comme indiqué dans le RFC, il semble nécessaire de spécifier explicitement :

set wrapmargin = 3 

dans le fichier de configuration (3 peut bien sûr être remplacé par une valeur au choix, il indique le nombre de caractères à laisser en marge gauche).

Par rapport à son prédécesseur, notre RFC introduit un nouveau paramètre, DelSp, qui permet de contrôler plus finement si l'espace final sera supprimé ou pas.

Bien sûr, à long terme, il faudra peut-être passer à un format de marquage plus perfectionné, peut-être avec le jeu de caractères Unicode, qui a des caractères différents pour le saut de ligne (U+2028) et le saut de paragraphe (U+2029), peut-être fondé sur XML et arrêter alors de lire son courrier avec grep et more. Mais, en attendant qu'un tel format, ouvert qui plus est, soit spécifié, mis en œuvre et largement déployé, text/plain, avec ces nouveaux paramètres, a encore de beaux jours devant lui.

Un excellent texte sur le format flowed est la format=flowed FAQ.