Encodeur et décodeur quoted-printable

Qu'est-ce que le quoted-printable ?

Le quoted-printable est l'une des deux façons dont le courrier électronique transporte du texte qui ne survivrait pas à un canal sur sept bits. Il est défini par la RFC 2045, le document qui définit aussi base64, et les deux sont des solutions concurrentes pour exactement le même travail. Son astuce consiste à laisser intact tout ce qui est déjà sûr et à n'échapper que le reste, en écrivant chaque octet gênant sous la forme d'un signe égal suivi de deux chiffres hexadécimaux : une lettre accentuée devient ainsi quelque chose comme =C3=A9, et tout ce qui l'entoure reste lisible.

Cette lisibilité est précisément le but. Un message en base64 est un bloc opaque ; un message en quoted-printable est le texte d'origine parsemé d'échappements, et c'est pourquoi on peut en général ouvrir la source d'un courriel et comprendre ce qu'il dit. Si vous avez déjà vu =E2=80=99 à la place d'une apostrophe, vous avez vu du quoted-printable affiché sans avoir été décodé.

Cet outil fonctionne dans les deux sens. Il encode du texte en quoted-printable et le décode en retour, et il vous indique à côté du résultat si base64 aurait été plus compact pour ce que vous lui avez donné — car pour certains textes ce serait le cas, et la spécification vous laisse ce choix.

Comment l'utiliser

1. Choisissez le sens. Encoder transforme du texte ordinaire en quoted-printable ; Décoder prend du quoted-printable et vous rend le texte. La sortie se met à jour à mesure que vous tapez.
2. Collez votre texte. Tout convient : une phrase, le corps entier d'un message, ou le fragment abîmé d'un courriel que vous êtes en train de déboguer. Les sauts de ligne sont traités comme la spécification l'exige.
3. Lisez la comparaison. Sous la sortie figurent la taille de votre texte dans les deux encodages et celui qui l'emporte. En décodage, tout ce qui s'écarte des règles dans l'entrée y est également listé.

Quoted-printable ou base64, et où passe la frontière

Les deux encodages ont des modèles de coût entièrement différents : la réponse dépend donc du texte et non du goût. Le quoted-printable dépense un caractère par octet qu'il peut laisser tel quel et trois par octet qu'il ne peut pas, si bien qu'un texte dont une fraction p des octets doit être échappée coûte 1 + 2p par octet. Base64 dépense quatre caractères pour trois octets quels qu'ils soient, soit 4/3. En égalant les deux, on obtient p = 1/6 : vers 16,7 % d'octets non ASCII les deux se rejoignent, et au-delà base64 l'emporte.

Ce chiffre ignore les sauts de ligne, et les compter le déplace — de moins d'un point, mais dans un sens qu'il est facile d'inverser. Les deux encodages doivent tenir leurs lignes dans 76 caractères. Un saut souple en quoted-printable coûte trois caractères, car le signe égal qui le signale en fait partie ; un saut base64 en coûte deux. Les surcoûts ne s'annulent pas, et en les portant tous les deux la bascule réelle se situe plutôt vers 15,8 %. L'arithmétique paraît symétrique exactement jusqu'au moment où l'on compte le signe égal.

En pratique, la ligne de partage suit l'écriture. Un message en français, en espagnol, en anglais ou en portugais est presque entièrement ASCII avec quelques accents : le quoted-printable revient donc à environ trois quarts de la taille de base64, et reste lisible par-dessus le marché. Un message en arabe ou en japonais est non-ASCII d'un bout à l'autre, et le quoted-printable en fait plus que doubler la taille — ceux-là relèvent de base64, et aucune préférence n'y changera rien.

Cela vaut d'être su, car beaucoup de logiciels choisissent une fois pour toutes et n'y reviennent jamais. Si votre courrier est surtout en alphabet latin, le quoted-printable est à la fois plus compact et lisible. Sinon, vous payez trois caractères par octet pour rien.

Limites assumées

Une règle surprend, et c'est elle qui explique le =20 en fin de ligne. Une espace est normalement laissée telle quelle, mais une espace ou une tabulation qui tombe en fin de ligne doit être encodée. La RFC 2045 est d'une franchise inhabituelle sur la raison : on sait que certains serveurs de messagerie complètent les lignes avec des espaces et que d'autres suppriment l'espace final, si bien qu'une espace laissée visible en fin de ligne peut tout simplement ne pas arriver. L'encoder est le seul moyen de garantir sa survie.

En décodage, cet outil signale au lieu de réparer. La spécification clôt sa définition par une liste de choses qu'un encodeur correct ne peut jamais produire — chiffres hexadécimaux en minuscules, signe égal suivi d'autre chose qu'un chiffre hexadécimal, signe égal tout à la fin, octets bruts au-delà de 126, lignes de plus de 76 caractères — et suggère comment un décodeur devrait réagir à chacune. Ces suggestions sont suivies ici, puis on vous dit ce qui a été trouvé : si vous décodez un message abîmé, vous voulez probablement savoir qu'il l'était.

Les encodeurs ont aussi le droit de diverger entre eux. La spécification dit que les caractères imprimables peuvent être laissés tels quels, non qu'ils doivent l'être : deux implémentations correctes peuvent donc produire des sorties différentes pour la même entrée et avoir toutes les deux raison. C'est pourquoi cet outil a été vérifié en confirmant que sa sortie et celle d'une implémentation de référence se décodent vers les mêmes octets dans les deux sens, plutôt qu'en exigeant que les deux chaînes coïncident.

Une différence réelle mérite d'être signalée : les fins de ligne. Cet outil normalise les sauts en CRLF, la forme que la spécification qualifie de canonique pour le texte. Certaines implémentations conservent ce qu'on leur a donné. Les deux sont permises, ce qui signifie qu'une comparaison octet par octet entre deux outils peut ne différer que par les fins de ligne sans qu'aucun ait tort.

Pourquoi est-ce gratuit ?

Tout se passe dans votre navigateur. Remplacer des octets par des séquences d'échappement n'est pas un travail qui réclame un serveur : il n'y a donc rien à faire tourner, rien à facturer et aucun compte à créer.

Rien de ce que vous collez n'est envoyé, conservé ni journalisé. Le corps d'un courriel compte parmi les choses les plus privées qu'on puisse mettre dans une zone de texte, et la seule manière fiable de traiter cela est de ne jamais le recevoir.