« MIME » redirige ici. Pour les autres significations, voirMime (homonymie).
Multipurpose Internet Mail Extensions (MIME) ouExtensions multifonctions du courrier Internet[1] est unstandard internet qui étend leformat de données descourriels pour supporter des textes en différentscodage des caractères autres que l'ASCII, des contenus non textuels, des contenus multiples, et des informations d'en-tête en d'autres codages que l'ASCII. Les courriels étant généralement envoyés via le protocoleSMTP au format MIME, ces courriels sont souvent appelés courrielsSMTP/MIME.
À l'origine, SMTP avait été prévu pour ne transférer que desfichiers textes (codés enASCII). Avec l'apparition dumultimédia et l'utilisation croissante des applications bureautiques, le besoin s'est fait sentir d'échanger, en plus des fichiers textes, desfichiers binaires (format des applications bureautiques, images, sons, fichiers compressés).
Les types de contenus définis par le standard MIME peuvent être utilisés à d'autres fins que l'envoi de courriels, dans lesprotocoles de communication comme leHTTP pour leWorld Wide Web.
MIME est initialement spécifié dans cinqRFC :RFC 2045[2],RFC 2046[3],RFC 2047[4],RFC 2048[5],RFC 2049[6]. LaRFC 2045 est complétée par laRFC 2077[7]. LaRFC 2048, maintenant obsolète, est remplacée par lesRFC 6838[8] etRFC 4289[9].
Le protocole de base de transmission de courriels, SMTP, ne supporte que les caractères ASCII (qui font 7 bits). Cela limite les courriels aux messages qui n’incluent que ces caractères, soient ceux rédigés dans un nombre très restreint de langues, telles que l’anglais, qui lui-même utilise pourtant occasionnellement des caractères hors ASCII. Les autres langues basés sur l’alphabet latin incluant desdiacritiques ne sont pas supportés par l’ASCII, ces messages ne peuvent donc pas être correctement représentés dans des courriels basiques.
MIME définit des mécanismes pour l’envoi d'autres sortes d’informations, comme des textes utilisant des codages de caractères autres que l’ASCII (et pouvant donc être dans une autre langue que l’anglais), ou des données binaires (dont des fichiers contenant desimages, dessons, desfilms ou desprogrammes informatiques).
MIME est également un composant fondamental des protocoles de communications commeHTTP, qui requièrent l’envoi de données dans le même contexte que l’envoi de courriels[C'est-à-dire ?], même si ces données ne sont pas des courriels. L’intégration ou l’extraction des données au format MIME est généralement automatiquement effectuée par leclient de messagerie ou par leserveur de messagerie électronique quand le courriel est envoyé ou reçu.
Le format de base des courriels est défini dans laRFC 2822[10] qui est unemise à jour de laRFC 822[11]. Ces standards spécifient le format des en-têtes et du corps des courriels contenant du texte, ainsi que les en-têtes généraux comme « To: », « Subject: », « From: » ou « Date: ». MIME définit un ensemble d’en-têtes additionnels pour le type de contenu du message (« Content‑Type: ») et sonencodage de transfert (« Content-Transfer-Encoding: »). L’encodage de transfert est la façon de traduire le contenu du message vers l’ASCII. Grâce à cette traduction, le contenu initial peut contenir des données 8 bits arbitraires (texte enUTF-8, fichier binaire, etc.). MIME définit également un mécanisme pour utiliser cette fonctionnalité dans les en-têtes du message ; ceci autorise par exemple des accents dans le sujet d’un courriel ou dans le nom d’un destinataire.
MIME est extensible. Sa définition inclut une méthode pour enregistrer de nouveaux types de contenus ou d’autres valeurs d'attributs.
Un des autres buts explicites de la définition de MIME est de ne pas avoir à changer les serveurs de messagerie électronique préexistants, et de permettre le fonctionnement correct des courriels de base avec les clients préexistants. Ce but est réalisé par le fait que les attributs de messages MIME sont optionnels et que le comportement par défaut est la création d’un message textuel sans MIME qui peut être interprété correctement par un client.
MIME-VersionLa présence de cet en-tête indique que le contenu du message est formaté en MIME. La valeur est typiquement « 1.0 », donc l'en-tête apparaît comme :
MIME-Version: 1.0
Content-TypeCet en-tête indique letype de média internet du contenu du message, consistant en untype et unsous-type, par exemple :
Content-Type: text/plain
MIME permet aux messages d'avoir plusieurs parties organisées sous forme d'unestructure arborescente, en utilisant un type « multipart » pour les nœuds internes.
Ce mécanisme supporte notamment :
text/plain » (la valeur par défaut de l'en-tête « Content-Type: ») ;text/html » ;multipart/mixed » : ceci permet l’envoi d’un message avecpièces jointes, le corps du message constituant une partie (de type « text »), de même que chaque pièce jointe ; généralement, on indique le nom d’une pièce jointe avec un en-tête « Content-Disposition: » (le type du fichier est alors identifié par le type MIME et sonextension) ;multipart/alternative » : ceci permet l’envoi d’un message contenant plusieurs formats alternatifs (typiquement, texte simple et HTML), le receveur (ou son client de messagerie) choisit alors le format sous lequel il veut visualiser le message.Content-Transfer-EncodingLa spécification du MIME (RFC 2045) définit un ensemble de méthodes ouencodages de transfert (rappelées danscette liste de l'IANA) pour représenter des données quelconques sous forme de texte ASCII. L'en-tête MIME « Content-Transfer-Encoding » indique la méthode utilisée. Il peut avoir l’une des valeurs (non sensibles à lacasse) suivantes :
7bit — aucune transformation, limité aux caractères de l’ASCII (valeurs 1 à 127) avec au plus 998 octets par ligne et les caractèresCR etLF (retour chariot et défilement de ligne,codes 13 et 10 respectivement) réservés pour les fins de ligne (CRLF). C'est la valeur par défaut.quoted-printable — encode des données arbitraires dans un format qui satisfait les règles de7bit. Étudié pour être efficace et lisible par un humain quand il est utilisé pour encoder du texte comportant une majorité de caractères ASCII.base64 — encode des données arbitraires dans un format qui satisfait les règles de7bit. Sa taille est fixe par rapport à la taille des données initiales. Il est utilisé pour les données non textuelles ou des textes à base non ASCII.8bit — aucune transformation, séquence d’octets quelconques avec au plus 998 octets par ligne et les caractèresCR etLF réservés pour les fins de ligne.binary — aucune transformation, séquence quelconque d'octets. Non utilisable avec les courriels SMTP.Aucun encodage n'est spécialement spécifié pour l'envoi de données binaires arbitraires par les transports SMTP avec l'extension 8BITMIME. Les méthodesBase64 ouQuoted-Printable (avec leurs inefficacités respectives) doivent être utilisées. Ces restrictions ne s'appliquent pas aux autres utilisations de MIME comme lesservices web avec attachement MIME ouMTOM.
Les données textuelles (type « text ») sont écrites selon un certainencodage de caractères, par exemplelatin-9 ouUTF-8. Cet encodage peut être précisé avec l’attribut « charset= » de l’en-tête « Content-Type: ». Celui-ci peut prendre n’importe quelle valeur définie par l’IANA. Par exemple :
Content-Type: text/plain; charset=utf-8
Cet encodage ne doit pas être confondu avec l’encodage de transfert, précisé par l’en-tête « Content-Transfer-Encoding: ». Dans le cas d’un contenu textuel, les deux encodages sont appliqués successivement. Par exemple :
Content-Type: text/plain; charset=utf-8Content-Transfer-Encoding: quoted-printableCeci est un message encod=C3=A9 en UTF-8, puis transform=C3=A9 en ASCII parla m=C3=A9thode "Quoted-Printable".
Dans cet exemple, la lettre « é » s’encode en UTF-8 par deux octets de valeurs hexadécimales C3 et A9, qui sont à leur tour encodés enQuoted-Printable par la séquence « =C3=A9 ».
Depuis laRFC 2822, les noms des en–têtes de messages et leurs valeurs sont toujours en caractères ASCII. Les valeurs qui contiennent des données non ASCII doivent utiliser la syntaxe dite « encoded-word » de MIME (RFC 2047) à la place des valeurs textuelles standards. Cette syntaxe utilise deschaînes de caractères ASCII aussi bien pour préciser l'encodage original du texte (équivalent de l’attributcharset= de l’en-têteContent-Type:) que l’encodage de transfert (équivalent de l’en-têteContent-Transfer-Encoding:).
La syntaxe est :
=?encodage?méthode?texte?=
encodage peut être n'importe quel encodage de caractères enregistré par l'IANA. Typiquement, c'est le même que pour le corps du message.méthode est une lettre désignant l’encodage de transfert : soit « Q » pourQ-encoding — encodage similaire àQuoted-Printable —, soit « B » pourBase64.texte est le texte encodé.Les codes ASCII pour le point d'interrogation (?) et lesigne égal (=) ne devraient pas être représentés directement puisqu'ils sont utilisés pour délimiter les mots encodés. Le code ASCII pour le caractère espace ne devrait pas non plus être utilisé car il peut provoquer des erreurs sur les anciens encodeurs comme une séparation de mot non désirée. Pour rendre l'encodage plus léger et plus aisé à lire, le caractèreunderscore (« _ ») est utilisé pour représenter l'espace. Par conséquent, le caractèreunderscore ne peut plus être représenté directement. L'utilisation de mots encodés dans certaines parties des en-têtes impose des restrictions sur les caractères à représenter directement.
Par exemple,
Subject: =?utf-8?Q?=C2=A1Hola, _se=C3=B1or!?=
est interprété comme :
Le format des mots encodés n'est pas utilisé pour les noms des en-têtes (par exemple « Subject: »). Ces noms d'en-têtes sont toujours en anglais dans le message. Quand le message est visualisé sur un client de courriels non anglophone, les noms d'en-têtes peuvent être traduits par le client.
Un message MIME multi-partie spécifie une ligne de séparation dans l'en-tête « Content-type: »,via l’attribut « boundary= ». Cette séparation, qui ne doit apparaître nulle part ailleurs, est placée entre les parties et au début et à la fin du corps du message comme suit :
Content-type: multipart/mixed; boundary="''frontière''" MIME-version: 1.0 This is a multi-part message in MIME format. --''frontière'' Content-type: text/plain This is the body of the message. --''frontière'' Content-type: application/octet-stream Content-transfer-encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --''frontière''--
Chacune de ces parties consiste en son propre en-tête de contenu (zéro, un ou plusieurs champs d'en-têteContent-*:) et un corps. Des parties multiples peuvent être incluses dans d'autres parties multiples avec pour chacune leur propre frontière. Le champContent-Transfer-Encoding: d'un type à parties multiples doit être « 7bit », « 8bit » ou « binary » pour éviter les problèmes de décodage des différentes couches de parties multiples. Le bloc multi-parties n'a pas de jeu de caractères, les caractères non ASCII dans les en-têtes sont traités par le système des mots encodés et les corps peuvent avoir un jeu de caractères spécifié approprié à leur contenu.
Notes :
Le standard MIME définit plusieurs sous-types de messages multi-parties pour en spécifier la nature des différentes parties du message et leurs relations avec les autres parties. Le sous type est spécifié par l'en-tête « Content-type: » du message englobant. Par exemple, un message MIME multi-parties utilisant le sous-type « digest » devrait avoir son en-tête « Content-Type: » à « multipart/digest ».LaRFC[Laquelle ?] définit initialement quatre sous-types : « mixed », « alternate », « digest » et « parallel ». Une application doit supporter au moins les sous-types « mixed » et « digest », les autres sont optionnels. Des sous-types additionnels comme « signed » ou « form-data » ont été définis dans d'autresRFC[Lesquelles ?].
Les sous-types suivants sont ceux principalement utilisés :
mixedLe type « multipart/mixed » (défini dansRFC2046,Section 5.1.3) est utilisé pour envoyer des fichiers avec différents en-têtes « Content-type: » (comme pièces-jointes). Si les fichiers sont facilement lisibles ou sont des images, la plupart des clients de courriels affichent ces fichiers directement dans le contenu du message (à moins qu'un en-tête « Content-disposition: » ne spécifie le contraire). Sinon les fichiers sont vus comme des pièces jointes. Le type de contenu par défaut de ces parties est « text/plain ».
La RFC spécifie également que tous les sous-types de « multipart » non reconnus par une implémentation doivent être traités de la même manière que « multipart/mixed ».
digestLe type « multipart/digest » (défini dansRFC2046,Section 5.1.5) est la manière simple d'envoyer des messages à textes multiples. Le type de contenu par défaut est « message/rfc822 ».
alternativeLe type « multipart/alternative » (défini dansRFC2046,Section 5.1.4) indique que chaque partie est une version alternative d'un même contenu dans un format différent. Les formats sont ordonnés dans l'ordre croissant de fidélité au contenu original. Le receveur peut ainsi choisir la meilleure représentation qu'il est capable de traiter, en général, la dernière de la liste.
Comme un client ne veut généralement pas envoyer un contenu moins significatif que le texte brut, celui-ci est envoyé en premier, ce qui permet de simplifier le traitement par les clients ne comprenant pas le type « multipart » car c'est la partie visible en premier.
L'utilisation principale du type « multipart/alternative » est l'envoi de courriels au formatHTML avec son équivalent au format texte pour conserver la lisibilité du message pour un client courriel ne pouvant afficher de HTML (client texte).
Bien que chaque partie du message soit censée représenter le même contenu, rien ne le garantit. Par exemple, il est plus facile pour unfiltre anti pourriel d'analyser la partie texte pur d'un message plutôt que la partie HTML ; alors que l'éditeur de pourriel va plutôt construire un message HTML avec son contenu publicitaire et un message en texte pur anodin ou sans rapport avec sa publicité.
relatedLe type « multipart/related » (défini dansRFC2387) est utilisé pour préciser que les différentes parties ne devraient pas être traitées individuellement mais comme un tout. Le message consiste en une partie racine (la première, par défaut) qui référence les autres parties, qui peuvent aussi référencer d'autres parties. Les parties de messages sont souvent référencées par leur identifiant de contenu (en-tête « Content-ID: »). La syntaxe des références n'est pas spécifiée, elle est laissée à l'intention du protocole utilisé.
Un des usages courant de ce sous-type est l'envoi d'une page web avec ses images en un seul message. La partie racine contient le document HTML et les images sont stockées dans les parties suivantes.
reportLe type « multipart/report » (défini dansRFC3462) représente un message qui contient des données formatées pour être lues par un serveur de courriels. Il contient une partie de type « text/plain » (ou tout autre contenu facilement lisible) et une autre de type « message/delivery-status » qui contient les données formatées pour le serveur de courriels.
signedLe type « multipart/signed » (défini dansRFC1847,Section 2.1) est utilisé pour attacher unesignature numérique à un message. Il est composé de deux parties : le corps du message et la signature. L'ensemble de la partie corps du message, y compris les en-têtes MIME, est utilisé pour générer la signature. Différents types de signatures sont possibles comme « application/pgp-signature » ou « application/x-pkcs7-signature ».
encryptedLe type « multipart/encrypted » (défini dansRFC1847,Section 2.2) est utilisé pour envoyer un contenuchiffré. Sa première partie définit les informations nécessaires pour déchiffrer sa seconde partie (de type « application/octet-stream »).
form-dataLe type « multipart/form-data » (défini dansRFC2388) est utilisé pour envoyer les données d'un formulaire. Défini à l'origine comme une partie deHTML 4.0, il est plus couramment utilisé pour envoyer des fichiers viaHTTP.
file est une commande Unix qui détermine le type MIME de fichiers.| Officiel | |
|---|---|
| Non-officiel | |
