← RFC Reference

RFC 2231 : Extensions des valeurs de paramètres MIME

Pourquoi cela existe

Les paramètres MIME apparaissent dans les en-têtes comme Content-Type et Content-Disposition. Le cas d'utilisation le plus courant est le paramètre filename pour les pièces jointes :

Content-Disposition: attachment; filename="report.pdf"

Cela fonctionne bien pour les noms de fichiers ASCII. Mais qu'en est-il d'un fichier nommé 報告書.pdf (japonais pour « rapport ») ou d'un nom de fichier avec 200 caractères ? La spécification MIME d'origine (RFC 2045) n'avait aucun mécanisme pour cela. RFC 2231 résout trois problèmes :

• Jeux de caractères : codage des caractères non-ASCII dans les valeurs de paramètres
• Balises de langue : annotation des valeurs de paramètres avec un identifiant de langue
• Continuations : division des longues valeurs de paramètres sur plusieurs lignes

Comment cela fonctionne

Codage du jeu de caractères et de la langue

Pour inclure des caractères non-ASCII, ajoutez un astérisque au nom du paramètre et utilisez le format charset'language'encoded-value :

Content-Disposition: attachment;
    filename*=UTF-8''%E5%A0%B1%E5%91%8A%E6%9B%B8.pdf
             ^^^^^^^  ^^  ^^^^^^^^^^^^^^^^^^^^^^^^
             jeu de car  langue  valeur encodée en pourcentage
                     (vide = aucune balise de langue)

La valeur %E5%A0%B1%E5%91%8A%E6%9B%B8 correspond aux octets UTF-8 pour « 報告書 » encodés en pourcentage. La balise de langue entre les guillemets simples est facultative (souvent laissée vide).

Continuations pour les longues valeurs

Lorsqu'une valeur de paramètre est trop longue pour une seule ligne d'en-tête, divisez-la en utilisant des continuations numérotées :

Content-Type: application/pdf;
    filename*0="very-long-document-name-that-exceeds-the";
    filename*1="-reasonable-line-length-limit-for-headers.pdf"

Les parties sont réassemblées dans l'ordre numérique : *0, *1, *2, etc.

Combiné : continuations avec jeux de caractères

Pour les longues valeurs non-ASCII, combinez les deux fonctionnalités. Seul le premier segment inclut le jeu de caractères et la langue ; les segments suivants sont simplement des valeurs encodées :

Content-Disposition: attachment;
    filename*0*=UTF-8''%E3%81%93%E3%82%8C%E3%81%AF%E9%95%B7;
    filename*1*=%E3%81%84%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB;
    filename*2*=%E5%90%8C%E5%90%8D.pdf
          ^^^^
          numéro + astérisque = continuation encodée

Détails techniques clés

Syntaxe du nom de paramètre

Règles d'encodage

• Utilisez l'encodage en pourcentage (comme l'encodage URL) pour les octets non-ASCII
• Les caractères ASCII sans risque dans les jetons MIME (lettres, chiffres, traits d'union, points) ne nécessitent pas d'encodage
• Le jeu de caractères est presque toujours UTF-8 dans la pratique moderne
• La balise de langue suit BCP 47 (par exemple, en, ja, zh-CN) mais est souvent omise

Interaction avec RFC 2047

RFC 2047 fournit des mots codés (=?UTF-8?B?...?=) pour le texte non-ASCII dans les en-têtes. Cependant, RFC 2047 stipule explicitement que les mots codés ne DOIVENT PAS apparaître dans les chaînes entre guillemets ou les valeurs de paramètres. RFC 2231 est le mécanisme correct pour les paramètres MIME. Malgré cette règle, de nombreux clients de courrier utilisent RFC 2047 dans les paramètres filename de toute façon, les analyseurs robustes doivent donc gérer les deux.

Erreurs courantes

• Utiliser l'encodage RFC 2047 dans les valeurs de paramètres. Écrire filename="=?UTF-8?B?...?=" est techniquement invalide, mais très répandu. Pour une compatibilité maximale, envoyez les deux : un filename ordinaire avec un repli ASCII et un filename* avec la valeur encodée RFC 2231.
• Oublier le double astérisque pour les continuations encodées. filename*1 est une continuation en texte ordinaire. filename*1* est une continuation encodée. L'absence de l'astérisque final signifie que la valeur sera traitée comme du texte littéral, non décodée.
• Mauvais ordre de continuation. Les parties doivent être numérotées séquentiellement à partir de 0. Les lacunes dans la numérotation (0, 1, 3) ou le démarrage à 1 au lieu de 0 causeront des défaillances d'analyse dans les implémentations strictes.
• Utiliser un jeu de caractères autre que UTF-8. Bien que RFC 2231 autorise tout jeu de caractères IANA, la pratique moderne est UTF-8 exclusivement. L'utilisation d'ISO-8859-1 ou Windows-1252 réduit l'interopérabilité avec les destinataires internationaux.
• Ne pas fournir de repli ASCII. Certains anciens clients de courrier ne prennent pas en charge RFC 2231. Incluez toujours un paramètre filename ordinaire avec une approximation ASCII à côté du paramètre filename*.

Impact sur la délivrabilité

• Affichage du nom de fichier de pièce jointe. L'encodage incorrect provoque l'apparition des noms de fichiers des pièces jointes comme du texte garbled ou des points d'interrogation dans le client de messagerie du destinataire. C'est déroutant et peu professionnel, bien que cela n'affecte pas directement la remise du message.
• Déclencheurs de filtres anti-spam. Les paramètres MIME malformés peuvent déclencher des filtres anti-spam. Certains filtres marquent les messages avec des anomalies d'encodage comme suspects, car les campagnes de malware utilisent parfois des en-têtes malformés pour exploiter les vulnérabilités des analyseurs.
• Interopérabilité entre clients. L'état réel du support RFC 2231 varie. Gmail, Apple Mail et Thunderbird le gèrent bien. Certains anciens clients d'entreprise ne le font pas. L'approche la plus sûre est d'inclure toujours les deux paramètres filename (ASCII) et filename* (RFC 2231).
• Paramètres Content-Type aussi. Bien que filename soit le cas d'utilisation le plus visible, RFC 2231 s'applique également aux paramètres Content-Type comme name et charset, et à tout autre paramètre d'en-tête MIME.

Related RFCs