← RFC Reference

RFC 2047 : MIME Partie 3 — Extensions d'en-tête de message pour texte non-ASCII

Pourquoi cela existe

RFC 2045 et RFC 2046 ont résolu le problème du contenu non-ASCII dans les corps de messages avec Content-Transfer-Encoding. Mais les en-têtes d'e-mail — Subject, noms d'affichage From, noms d'affichage To, et autres — sont régis par RFC 5322, qui les restreint à 7 bits US-ASCII.

Cela crée un problème évident : des milliards d'utilisateurs d'e-mail écrivent dans des langues qui nécessitent des caractères non-ASCII. Sans RFC 2047, vous ne pouviez pas envoyer un e-mail avec :

• Une ligne Subject en chinois, japonais, coréen, arabe, hébreu ou thaï
• Un nom d'affichage d'expéditeur avec caractères accentués (René, Müller, Björk)
• Tout champ d'en-tête contenant des caractères en dehors de la plage ASCII

RFC 2047 définit la syntaxe encoded-word : un moyen compact d'intégrer du texte non-ASCII dans les en-têtes ASCII uniquement, lisibles par tout client de messagerie compatible MIME.

Comment cela fonctionne

Le format Encoded-Word

Un encoded-word a cette structure :

=?charset?encoding?encoded-text?=

Les trois composants sont :

Encodage B (Base64)

Utilise l'encodage base64 standard. Meilleur pour le texte fortement non-ASCII, comme les scripts CJK :

; Subject: "Meeting confirmation" en japonais
Subject: =?UTF-8?B?5Lya6K2w44Gu56K66KqN?=

; Nom d'affichage From en chinois
From: =?UTF-8?B?5byg5LiJ?= <zhang@example.com>

Encodage Q (variante Quoted-Printable)

Un encodage quoted-printable modifié optimisé pour les en-têtes. Comme QP de corps, les octets non-ASCII deviennent des paires hexadécimales =XX. Différence clé : les espaces sont codés comme des traits de soulignement (_) :

; Subject: "Café menu" avec e accentué
Subject: =?UTF-8?Q?Caf=C3=A9_menu?=

; Nom d'affichage From : "René Dupont"
From: =?UTF-8?Q?Ren=C3=A9_Dupont?= <rene@example.com>

; Subject: "Gruße aus Berlin" (salutations allemandes)
Subject: =?UTF-8?Q?Gru=C3=9Fe_aus_Berlin?=

L'encodage Q est plus lisible quand la plupart du texte est ASCII avec seulement quelques caractères non-ASCII. L'encodage B est plus compact quand la plupart des caractères sont non-ASCII.

Où les Encoded-Words peuvent apparaître

Les encoded-words sont autorisés dans des positions spécifiques dans les en-têtes :

• Subject, Comments, Keywords : N'importe où où du texte est attendu (en remplacement d'un atom ou quoted-string).
• From, To, Cc, Bcc, Reply-To, Sender : Seulement dans la partie nom d'affichage, jamais dans l'adresse e-mail elle-même.
• Content-Description : Autorisé pour décrire les parties MIME.

Les encoded-words ne sont pas autorisés à l'intérieur des quoted-strings, dans la local-part ou le domaine d'une adresse e-mail, ou comme valeurs de paramètres dans les en-têtes structurés comme Content-Type (utilisez RFC 2231 pour cela).

Détails techniques clés

Limites de longueur

Chaque encoded-word ne doit pas dépasser 75 caractères. Si le texte codé est plus long, il doit être divisé en plusieurs encoded-words séparés par un espace plié (CRLF + espace ou tabulation) :

; Long subject divisé sur deux encoded-words
Subject: =?UTF-8?B?5LuK5pel44Gu5Lya6K2w44Gr44Gk44GE44Gm?=
 =?UTF-8?B?44GU5qGI5YaF44GE44Gf44GX44G+44GZ?=

Quand deux encoded-words adjacents sont séparés seulement par un espace linéaire, l'espace entre eux est ignoré pendant le décodage. Cela permet de diviser facilement le texte long sur plusieurs encoded-words.

Sélection du charset

Utilisez toujours UTF-8 pour les nouveaux messages. Les autres charsets existent pour des raisons d'héritage :

Interaction avec le pliage d'en-tête

RFC 5322 limite les lignes d'en-tête à 998 caractères et recommande de les maintenir sous 78. Les encoded-words interagissent avec le pliage : vous pouvez casser entre encoded-words aux limites d'espace, mais vous ne devez jamais casser au milieu d'un encoded-word. Le wrapper =?...?= doit être sur une seule ligne.

Règles de décodage

Quand un client de messagerie rencontre un encoded-word, il :

1. Extrait le charset, le type d'encodage et le texte codé du wrapper =?charset?encoding?text?=.
2. Décode le texte en utilisant base64 (B) ou quoted-printable (Q).
3. Interprète les octets résultants selon le charset déclaré.
4. Affiche le texte Unicode décodé à l'utilisateur.

Si le client ne reconnaît pas le charset, il doit afficher l'encoded-word tel quel plutôt que d'afficher du texte garni.

Exemples

Un message complet avec en-têtes codés

MIME-Version: 1.0
From: =?UTF-8?Q?Ren=C3=A9_Dupont?= <rene@example.fr>
To: =?UTF-8?B?5bGx55Sw5aSq6YOO?= <yamada@example.jp>
Subject: =?UTF-8?Q?Re:_R=C3=A9union_du_15_mars?=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Bonjour Taro,

Confirmons la r=C3=A9union pour le 15 mars.

Remarque : l'en-tête utilise les encoded-words RFC 2047 (=?...?=), tandis que le corps utilise l'encodage quoted-printable régulier (=XX sans le wrapper). Ce sont des mécanismes différents pour différentes parties du message.

Comparaison d'encodage

Le même texte — « München » — encodé des deux façons :

; Encodage Q : lisible, bon pour le texte surtout ASCII
=?UTF-8?Q?M=C3=BCnchen?=

; Encodage B : compact mais opaque
=?UTF-8?B?TcO8bmNoZW4=?=

Erreurs courantes

• Encoder l'adresse e-mail elle-même. Seul le nom d'affichage peut être encodé. =?UTF-8?Q?user?=@example.com est invalide et sera rejeté ou mal interprété. Pour les adresses e-mail internationalisées, voir RFC 6531/6532.
• Espace manquant entre encoded-words et texte régulier. Un encoded-word doit être séparé du texte adjacent par un espace. Hello=?UTF-8?Q?World?= est malformé ; ce devrait être Hello =?UTF-8?Q?World?=.
• Casser un encoded-word sur plusieurs lignes. Le token entier =?...?= doit tenir sur une ligne. Si vous devez plier, divisez en plusieurs encoded-words aux limites de mots.
• Utiliser RFC 2047 dans les paramètres Content-Type. Les encoded-words ne sont pas valides dans les paramètres d'en-têtes structurés comme filename= ou name=. Utilisez l'encodage de paramètres RFC 2231 à la place : filename*=UTF-8''R%C3%A9sum%C3%A9.pdf.
• Dépasser la limite de 75 caractères. Chaque encoded-word doit faire 75 caractères ou moins. Le texte long doit être divisé en plusieurs encoded-words. Les encoded-words surdimensionnés peuvent être silencieusement tronqués par les serveurs de messagerie.
• Double-encodage. Encoder un texte déjà encodé produit des ordures comme =?UTF-8?Q?=3D=3FUTF-8=3FQ=3F...?=. Assurez-vous que votre pipeline d'encodage s'exécute exactement une fois.

Impact sur la livraison

• Un encodage incorrect déclenche les filtres anti-spam. Les encoded-words malformés dans les lignes Subject sont un signal d'alerte. Les filtres anti-spam ont vu des décennies d'encodages cassés provenant d'outils de spam. Un encodage propre et conforme aux normes signale un logiciel d'envoi légitime.
• L'encodage du nom d'affichage affecte la confiance. Si le nom d'affichage From contient des caractères non-ASCII qui ne sont pas correctement encodés, les destinataires voient du texte brut =?UTF-8?Q?...?= à la place d'un nom lisible. Cela semble suspect et nuit aux taux d'ouverture.
• Le rendu de la ligne Subject est critique pour l'engagement. Une ligne Subject garnie due à un mauvais charset ou un encodage cassé signifie que le destinataire ne peut pas la lire. L'e-mail est ignoré ou signalé comme spam.
• Utilisez toujours UTF-8. Les charsets hérités comme ISO-8859-1 ne peuvent pas représenter tous les caractères. Si un système mélange les charsets sur différents en-têtes, les clients peuvent afficher certains correctement et d'autres comme mojibake. Standardisez sur UTF-8 partout.
• Testez sur plusieurs clients. Outlook, Gmail, Apple Mail et Thunderbird ont tous des comportements de décodage RFC 2047 légèrement différents, surtout autour des cas limites comme les encoded-words longs et le mélange d'encodage/non-encodage dans un seul en-tête.

Related RFCs