Multipurpose Internet Mail Extensions
Source: Wikipédia sous licence CC-BY-SA 3.0.
La liste des auteurs de cet article est disponible ici.

Multipurpose Internet Mail Extensions (MIME) est un standard internet qui étend le format de données des courriels pour supporter des textes en différents codage de 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 protocole SMTP au format MIME, ces courriels sont souvent appelés courriels SMTP/MIME.

À l'origine SMTP avait été prévu pour ne transférer que des fichiers textes (codés en ASCII). Avec l'apparition du multimédia (Le mot multimédia est apparu vers la fin des années 1980, lorsque les CD-ROM se sont développés. Il désignait alors les applications qui, grâce à la mémoire du CD et aux capacités de l'ordinateur, pouvaient générer, utiliser ou...) et l'utilisation croissante des applications bureautiques, le besoin (Les besoins se situent au niveau de l'interaction entre l'individu et l'environnement. Il est souvent fait un classement des besoins humains en trois grandes catégories : les besoins primaires, les besoins...) s'est fait sentir d'échanger, en plus des fichiers textes, des fichiers 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 les protocoles de communication (La communication concerne aussi bien l'homme (communication intra-psychique, interpersonnelle, groupale...) que l'animal (communication intra- ou inter- espèces) ou la machine (télécommunications, nouvelles technologies...), ainsi que leurs...) comme le HTTP pour le World Wide Web (Le World Wide Web, littéralement la « toile (d’araignée) mondiale », communément appelé le Web, le web parfois la Toile ou le WWW, est un...).

MIME est spécifié dans cinq RFC : RFC 2045, RFC 2046, RFC 2047, RFC 2048 et RFC 2077.

Introduction

Le protocole de base de transmission de courriels, SMTP, ne supporte que les caractères ASCII 7-bits. Cela limite les courriels aux messages qui n'incluent que ces caractères, soit un petit nombre (La notion de nombre en linguistique est traitée à l’article « Nombre grammatical ».) de langages comme l'anglais. Les autres langages basés sur l'alphabet latin incluant des diacritiques ne sont pas supportés par l'ASCII 7-bits, ces messages ne peuvent donc pas être correctement représentés dans des courriels basics.

MIME définit des mécanismes pour l'envoi d'autre sortes d'informations dont des textes des langages autres que l'anglais utilisant des codages de caractères autres que l'ASCII et des données (Dans les technologies de l'information (TI), une donnée est une description élémentaire, souvent codée, d'une chose, d'une transaction d'affaire, d'un événement, etc.) binaires comme des fichiers contenant des images, des sons, des films ou des programmes informatiques. MIME est également un composant fondamental des protocoles de communications comme HTTP, qui requièrent l'envoi de données dans le même contexte (Le contexte d'un évènement inclut les circonstances et conditions qui l'entourent; le contexte d'un mot, d'une phrase ou d'un texte inclut les mots qui l'entourent. Le concept...) que l'envoi de courriels, même si les 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 le client de messagerie (Un client de messagerie est un logiciel qui sert à lire et envoyer des courriers électroniques. Les Webmails offrent les mêmes fonctionnalités.) ou par le serveur de messagerie électronique quand le courriel est envoyé ou reçu.

Le format de base des courriels est défini dans la RFC 2822 qui est une mise à jour (Une mise à jour, souvent abrégé en MAJ ou MàJ, est l'action qui consiste à mettre « à jour », ou bien « à niveau », un outil informatique, un service ou une prestation en...) de la RFC 822. Ces standards spécifient le format des en-têtes et du corps des courriels contenant du texte, ainsi que les règles d'en-têtes générales comme "To:", "Subject:", "From:" ou "Date:". MIME définit un ensemble (En théorie des ensembles, un ensemble désigne intuitivement une collection d’objets (les éléments de l'ensemble), « une...) d'attributs additionnels d'en-têtes de courriels pour le type de contenu du message (La théorie de l'information fut mise au point pour déterminer mathématiquement le taux d’information transmis dans la communication d’un message...), et son codage (De façon générale un codage permet de passer d'une représentation des données vers une autre.). Le codage étant la façon de traduire en ASCII 7-bits, les données 8 bits du message. MIME définit également des règles spécifiques pour encoder des caractères non ASCII dans les en-têtes de messages, pour, par exemple, autoriser des caractères accentués dans le sujet d'un courriel.

MIME est extensible. Sa définition (Une définition est un discours qui dit ce qu'est une chose ou ce que signifie un nom. D'où la division entre les définitions réelles et les définitions nominales.) 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 (Le mot client a plusieurs acceptations :).

En-têtes MIME

MIME-Version

La 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 apparait comme MIME-Version: 1.0

Content-Type

La présence de cet en-tête indique le type de média (On nomme média un moyen impersonnel de diffusion d'informations (comme la presse, la radio, la télévision), utilisé pour communiquer. Les médias permettent de...) internet (Internet est le réseau informatique mondial qui rend accessibles au public des services variés comme le courrier électronique, la messagerie...) du contenu du message, consistant en un type et un sous-type, par exemple : Content-Type: text/plain

Avec l'utilisation d'un type multipart, MIME permet aux messages d'avoir plusieurs parties organisées sous forme d'une structure arborescente où les nœuds feuilles sont des contenus non multipart et les nœuds internes sont de type multipart. Ce mécanisme supporte notamment :

  • les message en texte simple avec text/plain (la valeur par défaut de l'en-tête Content-Type:)
  • le texte avec des pièces jointes (multipart/mixed avec une partie text/plain et d'autres parties non textuelles). Un message MIME incluant un fichier ( Un fichier est un endroit où sont rangées des fiches. Cela peut-être un meuble, une pièce, un bâtiment, une base de données informatique. Par exemple : fichier des patients d'un médecin, fichier des ouvrages...) joint indique généralement le nom d'origine du fichier avec l'en-tête Content-disposition: donc le type du fichier est identifié par le type MIME et son extension de nom de fichier
  • les contenus alternatifs : chaque message est envoyé avec plusieurs contenu (texte simple et HTML par exemple), le receveur choisit le format sous lequel il veut visualiser le message.

Content-Transfert-Encoding

La spécification du MIME (RFC 2045) définie un ensemble de méthodes pour représenter des données binaires sous forme de texte ASCII. L'en-tête MIME Content-Transfert-Encoding indique la méthode utilisée. La RFC la liste de l'IANA définissent les valeurs non sensibles à la casse (typographie) :

  • Appropriées pour l'usage (L’usage est l'action de se servir de quelque chose.) avec le SMTP:
    • 7bit - jusqu'à 998 octets par ligne dans la gamme 1...127 avec CR et LF (retour charriot et défilement de ligne - codes 13 et 10 respectivement) autorisés uniquement pour une fin de ligne CRLF. C'est la valeur par défaut.
    • Quoted-Printable - utilisé pour encoder des séquences d'octets dans un format qui satisfait les règles de l'encodage 7bit. Étudié pour être efficace et lisible par un humain quand il est utilisé pour encoder des données comportant majoritairement du texte avec des caractères ASCII avec quelques caractères non ASCII.
    • Base64 - utilisé pour encoder des données arbitraires dans une forme satisfaisant les règles de l'encodage 7bit. 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.
  • Appropriées pour les serveurs SMTP qui supportent le transport (Le transport, du latin trans, au-delà, et portare, porter, est le fait de porter quelque chose, ou quelqu'un, d'un lieu à un autre.) 8BITMIME comme extension SMTP:
    • 8bit - jusqu'à 998 octets par ligne avec CR et LF (retour charriot et défilement de ligne - codes 13 et 10 respectivement) autorisés uniquement pour une fin de ligne CRLF.
  • Non approprié avec SMTP :
    • binary - 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. base64 ou quoted-printable (avec leurs inefficacités respectives) doivent être utilisées. Ces restrictions ne s'appliquent pas aux autres utilisations de MIME comme les services web avec attachement MIME ou MTOM.

Mots encodés

Depuis la RFC 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 encoded-word de MIME (RFC 2047) à la place des valeurs textuelles standards. Cette syntaxe utilise des chaines de caractères ASCII aussi bien pour préciser l'encodage original des caractères (charset) que le content-transfert-encoding utilisé pour faire correspondre les données du codage des caractères aux caractères ASCII.

La forme est: "=?charset?encodage?texte?=".

  • charset peut être n'importe quel jeu de caractères enregistré par l'IANA. Typiquement, c'est le même jeu d'encodage que le corps du message.
  • encodage peut être soit "Q" pour Q-encoding qui est similaire à l'encodage Quoted-Printable ou "B" pour l'encodage Base64.
  • texte est le texte encodé par le Q-encoding ou le base64.

Différence entre Q-encodage et quoted-printable

Les codes ASCII pour le point (Graphie) d'interrogation (?) et le signe é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 être non plus utilisé car il peut provoquer des erreurs sur les anciens encodeurs comme une séparation (D'une manière générale, le mot séparation désigne une action consistant à séparer quelque chose ou son résultat. Plus particulièrement il est employé dans plusieurs...) de mot non désirée. Pour rendre l'encodage plus léger et plus aisé à lire, le caractère underscore (_) est utilisé pour représenter l'espace. Par conséquent, le caractère underscore 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 "Subject: ¡Hola, señor!".

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.

Message à plusieurs parties

Un message MIME multi parties contient une séparation dans l'en-tête "Content-type:". Cette séparation, qui ne doit pas être présente dans aucune des autres parties, est placée entre les parties et au début et à la fin du corps du message comme suit :

 
 Content-type: multipart/mixed; boundary="frontier" 
 MIME-version: 1.0 
 This is a multi-part message in MIME format. 
 --frontier 
 Content-type: text/plain 
 This is the body of the message. 
 --frontier 
 Content-type: application/octet-stream 
 Content-transfer-encoding: base64 
 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg 
 Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== 
 --frontier-- 
 

Chacune de ces parties consistent en sa propre en-tête de contenu (zéro, un ou plusieurs champs d'en-tête Content-) et un corps. Des parties multiples peuvent être incluent dans d'autres parties multiples avec pour chacune leur propre frontière (Une frontière est une ligne imaginaire séparant deux territoires, en particulier deux États souverains. Le rôle que joue une frontière...) (boundary) définit. Le champ (Un champ correspond à une notion d'espace défini:) content-transfert-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'as 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 :

  • La zone se trouvant avant le premier séparateur est ignorée par les clients MIME. Cette zone est généralement utilisée pour stocker un message à l'attention des client ne supportant pas MIME.
  • Le choix du séparateur de parties revient au programme client. Celui-ci doit le choisir de façon à éviter toute collision (Une collision est un choc direct entre deux objets. Un tel impact transmet une partie de l'énergie et de l'impulsion de l'un des corps au second.) avec le contenu des différents contenus. Généralement, le séparateur est généré à partir d'une large chaine de caractères aléatoires.

Sous-types

Le standard MIME définit plusieurs sous types de messages multiparties 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. La RFC définit initialement quatre sous types : mixed, alternate, digest et parallel. Une application qui implémente le minimum de cette spécification doit supporter les types mixed et digest, les autres sous types sont optionnels. Les sous types additionnels, comme signed ou form-data ont été définis dans d'autres RFCs.

Les sous types suivants sont ceux principalement utilisés :

Mixed

multipart/mixed est utilisé pour envoyer des fichiers avec différentes en-têtes Content-type (comme attachements). 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'une en-tête Content-disposition ne la spécifie). Sinon les fichiers sont vus comme des pièces jointes. Le type de contenu par défaut de ces parties est "text/plain".

Défini dans RFC2231, Section 5.1.3

Digest

multipart/digest est la manière simple d'envoyer des messages à textes multiples. Le type de contenu par défaut est "message/rfc822".

Défini dans RFC2231, Section 5.1.5

Alternative

multipart/alternative 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 meilleur représentation qu'il est capable de traiter, en générale, la dernière de la liste.

Comme un client ne veut généralement pas envoyer un contenu plus 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 multipart car c'est la partie visible en premier.

L'utilisation principale du type multipart/alternative est l'envoi de courriels au format HTML 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 est censée représenter le même contenu, rien ne le garantit. Par exemple, il est plus facile pour un filtre (Un filtre est un système servant à séparer des éléments dans un flux.) 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é (Bien que le terme (Werbung en allemand, Publicity et Advertising en anglais) désignât d'abord le mot qui aux yeux d'Habermas qualifie la Modernité et la Démocratie —( Publicité, sauvegarde du peuple...).

Défini dans RFC2231, Section 5.1.4

Related

multipart/related est utilisé pour préciser que les différentes parties ne devraient pas être traitées individuellement mais comme un tout (Le tout compris comme ensemble de ce qui existe est souvent interprété comme le monde ou l'univers.). 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 (En informatique, on appelle identifiants (également appelé parfois en anglais login) les informations permettant à une personne de...) 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 (Une page Web est une ressource du World Wide Web conçue pour être consultée par des visiteurs à l'aide d'un navigateur Web. Elle a une adresse Web. Techniquement, une page Web...) avec ses images en un seul message. La partie racine contient le document (Dans son acception courante un document est généralement défini comme le support physique d'une information.) HTML et les images sont stockées dans les parties suivantes.

Défini dans RFC2387

Report

multipart/report est un type de message qui contient des données formatées pour être lues par un serveur de courriels. Il est séparé entre un text/plain (ou tout autre contenu facilement lisible) et un message/delivery-status qui contient les données formatées pour le serveur de courriels.

Défini dans RFC3462

Signed

multipart/signed est utilisé pour attacher une signature numérique (Une information numérique (en anglais « digital ») est une information ayant été quantifiée et échantillonnée, par opposition à une...) à un message. Il est composé de deux parties : le corps du message et la partie 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.

Défini dans RFC1847, Section 2.1

Encrypted

multipart/encrypted est utilisé pour envoyer un contenu encrypté. Sa première partie définit les informations nécessaires pour décrypter la seconde ( Seconde est le féminin de l'adjectif second, qui vient immédiatement après le premier ou qui s'ajoute à quelque chose de nature identique. La seconde est une unité de mesure du temps. La seconde d'arc est une mesure d'angle plan. ...) partie (application/octet-stream).

Défini dans RFC1847, Section 2.2

Form Data

multipart/form-data est utilisé pour envoyer les données d'un formulaire. définit à l'origine comme une partie de HTML 4.0, il est plus couramment utilisé pour envoyer des fichiers via HTTP.

Défini dans RFC2388

Page générée en 0.267 seconde(s) - site hébergé chez Amen
Ce site fait l'objet d'une déclaration à la CNIL sous le numéro de dossier 1037632
Ce site est édité par Techno-Science.net - A propos - Informations légales
Partenaire: HD-Numérique