Multipurpose Internet Mail Extensions

ÔĽŅ
Multipurpose Internet Mail Extensions
Pile de protocoles
7.  Application
6.  Pr√©sentation
5.  Session
4.  Transport
3.  R√©seau
2.  Liaison
1.  Physique
Modèle Internet
Modèle OSI
Page d'aide sur les redirections ¬ę MIME ¬Ľ redirige ici. Pour les autres significations, voir Mime (homonymie).

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 et l'utilisation croissante des applications bureautiques, le besoin 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 comme le HTTP pour le World Wide Web.

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

Sommaire

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 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 basiques.

MIME définit des mécanismes pour l'envoi d'autre sortes d'informations dont des textes dans des langages autres que l'anglais utilisant des codages de caractères autres que l'ASCII et des données 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 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 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 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 d'attributs additionnels d'en-têtes de courriels pour le type de contenu du message, et son codage. 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 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.

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 internet 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 messages 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 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 (ou son client de messagerie) choisit le format sous lequel il veut visualiser le message.

Content-Transfer-Encoding

La sp√©cification du MIME (RFC 2045) d√©finit un ensemble de m√©thodes pour repr√©senter des donn√©es binaires sous forme de texte ASCII. L'en-t√™te MIME Content-Transfer-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 avec le SMTP :
    • 7bit - jusqu'√† 998 octets par ligne dans la gamme 1...127 avec CR et LF (retour chariot 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 8BITMIME comme extension SMTP :
    • 8bit - jusqu'√† 998 octets par ligne avec CR et LF (retour chariot 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-transfer-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 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 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-partie contient une s√©paration dans l'en-t√™te "Content-type:". Cette s√©paration, qui ne doit √™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 consiste 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 incluses dans d'autres parties multiples avec pour chacune leur propre frontière (boundary) définit. Le champ content-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 :

  • 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 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'un 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.

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.

Défini dans RFC2046, 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 RFC2046, 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 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 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 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√©.

Défini dans RFC2046, 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 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.

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 √† 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 chiffré. Sa première partie définit les informations nécessaires pour décrypter la seconde 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éfini à l'origine comme une partie de HTML 4.0, il est plus couramment utilisé pour envoyer des fichiers via HTTP.

Défini dans RFC2388

Références

RFC 1847 
Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
RFC 2045 
MIME Part One: Format of Internet Message Bodies.
RFC 2046 
MIME Part Two: Media Types. N. Freed, Nathaniel Borenstein. November 1996.
RFC 2047 
MIME Part Three: Message Header Extensions for Non-ASCII Text. Keith Moore. November 1996.
RFC 4288 
MIME Part Four: Media Type Specifications and Registration Procedures.
RFC 4289 
MIME Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005.
RFC 2049 
MIME Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996.
RFC 2231 
MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997.
RFC 2387 
The MIME Multipart/Related Content-type

Voir aussi

Liens connexes

Liens externes


Wikimedia Foundation. 2010.

Contenu soumis à la licence CC-BY-SA. Source : Article Multipurpose Internet Mail Extensions de Wikipédia en français (auteurs)

Regardez d'autres dictionnaires:

  • Multipurpose internet mail extensions ‚ÄĒ ¬ę MIME ¬Ľ redirige ici. Pour les autres significations, voir Mime (homonymie). 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… ‚Ķ   Wikip√©dia en Fran√ßais

  • Multipurpose Internet Mail Extensions ‚ÄĒ Multipurpose Internet Mail Extensions, ¬† MIME ‚Ķ   Universal-Lexikon

  • Multipurpose Internet Mail Extensions ‚ÄĒ Die Multipurpose Internet Mail Extensions (MIME) sind Erweiterungen des Internetstandards RFC 822, der das Datenformat von E Mails definiert. Jener sieht nur den American Standard Code for Information Interchange (ASCII) vor. Die MIME schaffen… ‚Ķ   Deutsch Wikipedia

  • Multipurpose Internet Mail Extensions ‚ÄĒ Para otros usos de este t√©rmino, v√©ase Mime. Multipurpose Internet Mail Extensions o MIME (en espa√Īol extensiones multiprop√≥sito de correo de internet ) son una serie de convenciones o especificaciones dirigidas al intercambio a trav√©s de… ‚Ķ   Wikipedia Espa√Īol

  • multipurpose internet mail extensions ‚ÄĒ ¬†¬†¬†(MIME) ¬†¬†¬†Protocol for sending and receiving Internet e mail ‚Ķ   IT glossary of terms, acronyms and abbreviations

  • Multipurpose Internet Mail Extensions ‚ÄĒ ‚Ķ   –í–ł–ļ–ł–Ņ–Ķ–ī–ł—Ź

  • Multipurpose Internet Mail Extensions protocol ‚ÄĒ MIME protokolas statusas T sritis informatika apibrńóŇĺtis ‚ÜĎElektroninio paŇ°to ‚ÜĎprotokolas, papildantis laiŇ°kŇ≥ siuntimo ‚ÜĎSMTP protokolńÖ taip, kad elektroniniu laiŇ°ku bŇętŇ≥ galima siŇ≥sti ńĮvairiŇ≥ tipŇ≥ duomenis: 8 bitŇ≥ tekstńÖ, ‚ÜĎvaizdo ir ‚ÜĎgarso failus ‚Ķ   Enciklopedinis kompiuterijos Ňĺodynas

  • Multimedia Internet Message Extensions ‚ÄĒ Multipurpose Internet Mail Extensions (MIME) ist ein Kodierstandard, der die Struktur und den Aufbau von E Mails und anderen Internetnachrichten festlegt. Ferner findet MIME Anwendung bei der Deklaration von Inhalten in verschiedenen… ‚Ķ   Deutsch Wikipedia

  • Internet security ‚ÄĒ is a branch of computer security[1] specifically related to the Internet. Its objective is to establish rules and measures to use against attacks over the Internet.[2] The Internet represents an insecure channel for exchanging information leading ‚Ķ   Wikipedia

  • Internet media type ‚ÄĒ Internet Media Types –≤–į–∂–Ĺ–į—Ź —á–į—Ā—ā—Ć –í–Ķ–Ī –į—Ä—Ö–ł—ā–Ķ–ļ—ā—É—Ä—č[1] –°–ĺ–ī–Ķ—Ä–∂–į–Ĺ–ł–Ķ 1 –°–Ņ–ł—Ā–ĺ–ļ —ā–ł–Ņ–ĺ–≤ 1.1 application 1.2 audio 1.3 image ‚Ķ   –í–ł–ļ–ł–Ņ–Ķ–ī–ł—Ź


Share the article and excerpts

Direct link
… Do a right-click on the link above
and select ‚ÄúCopy Link‚ÄĚ

We are using cookies for the best presentation of our site. Continuing to use this site, you agree with this.