Multipurpose Internet Mail Extensions (MIME) saumultifuncțional Extensions Internet maileste unstandard de internetcare extindeformatul de dateale-mailurilorpentru a accepta textul încodificare de caracterediferită deASCII, conținut non-text, conținut multiplu și informații despre antet în alte codificări decâtASCII. Deoarece e-mailurile sunt de obicei trimise prinSMTPîn format MIME, aceste e-mailuri sunt adesea denumite e-mailuriSMTP / MIME.
Inițial, SMTP a fost conceput pentru a transfera numai fișiere text (codate în ASCII ). Odată cu apariția multimedia și utilizarea tot mai mare a aplicațiilor de birou, a apărut nevoia de a schimba, pe lângă fișiere text, fișiere binare (formatul aplicațiilor de birou, imagini, sunete, fișiere comprimate).
Tipurile de conținut definite de standardul MIME pot fi utilizate în alte scopuri decât trimiterea de e-mailuri, în protocoale de comunicare precum HTTP pentru World Wide Web .
MIME este specificat inițial în cinci RFC-uri : RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049. RFC 2045 este completat de RFC 2077. RFC 2048 , acum învechit, este înlocuit de RFC 6838 și RFC 4289.
Protocolul de bază de transmitere a e-mailului, SMTP, acceptă numai caractere ASCII (care au o lungime de 7 biți ). Acest lucru limitează e-mailurile la mesajele care includ numai aceste caractere, care este un număr mic de limbi precum engleza . Alte limbi bazate pe alfabet latin , inclusiv diacritice , nu sunt acceptate de ASCII, astfel încât aceste mesaje nu pot fi reprezentate corect în e-mailurile de bază.
MIME definește mecanisme pentru trimiterea altor tipuri de informații, cum ar fi textul folosind alte codificări de caractere decât ASCII (și, prin urmare, posibil într-o altă limbă decât engleza), sau date binare (inclusiv fișiere care conțin imagini , sunete , filme sau programe pentru computer ).
MIME este, de asemenea, o componentă fundamentală a protocoalelor de comunicații precum HTTP , care necesită trimiterea de date în același context cu trimiterea e-mailurilor , Chiar dacă aceste date nu sunt e-mail. Integrarea sau extragerea datelor în format MIME se face de obicei automat de către clientul de e-mail sau de către serverul de e - mail atunci când e-mailul este trimis sau primit.
Formatul de bază al e-mailului este definit în RFC 2822, care este o actualizare a RFC 822. Aceste standarde specifică formatul antetelor și al corpului de e-mailuri care conțin text, precum și anteturile generale, cum ar fi " To: ", " Subject: ", " From: " Sau " Date: " . MIME definește un set de antete suplimentare pentru tipul de conținut al mesajului (" Content‑Type: ") și codificarea acestuia de transfer (" Content-Transfer-Encoding: "). Codificarea prin transfer este modalitatea de a traduce conținutul mesajului în ASCII. Datorită acestei traduceri, conținutul inițial poate conține date arbitrare pe 8 biți (text în UTF-8 , fișier binar etc.). MIME definește, de asemenea, un mecanism pentru utilizarea acestei funcționalități în antetele mesajelor; acest lucru permite, de exemplu, accente în subiectul unui e-mail sau în numele unui destinatar.
MIME este extensibil. Definiția sa include o metodă de înregistrare a unor noi tipuri de conținut sau a altor valori ale atributelor.
Unul dintre celelalte scopuri explicite ale definiției MIME nu este acela de a schimba serverele de poștă preexistente și de a permite e-mailului de bază să funcționeze corect cu clienții pre-existenți. Acest obiectiv este atins de faptul că atributele mesajelor MIME sunt opționale și că comportamentul implicit este crearea unui mesaj text fără MIME care poate fi interpretat corect de către un client.
Prezența acestui antet indică faptul că conținutul mesajului este formatat în MIME. Valoarea este de obicei „1.0”, deci antetul apare ca:
MIME-Version: 1.0Acest antet indică tipul de conținut media al internetului , format dintr-un tip și un subtip , de exemplu:
Content-Type: text/plainMIME permite mesajelor să aibă mai multe părți organizate într-o structură de copac , utilizând un tip " multipart " pentru noduri interne.
Acest mecanism susține în special:
Specificația MIME ( RFC 2045 ) definește un set de metode de transfer sau codificări (reamintite în această listă IANA ) pentru a reprezenta date arbitrare ca text ASCII. Antetul MIME " Content-Transfer-Encoding " indică metoda utilizată. Poate avea una dintre valorile de mai jos (care nu sunt susceptibile de rupere ):
Nu este specificată nicio codificare specială pentru trimiterea de date binare arbitrare prin transporturi SMTP cu extensia 8BITMIME. Ar trebui folosite metodele Base64 sau Quoted-Printable (cu ineficiențele lor respective). Aceste restricții nu se aplică altor utilizări ale MIME, cum ar fi serviciile web cu atașament MIME sau MTOM .
Datele text (tipul " text ") sunt scrise într-o anumită codificare a caracterelor , de exemplu latin-9 sau UTF-8 . Această codificare poate fi specificată cu atributul charset= „ Content-Type: ” al antetului „ ”. Aceasta poate lua orice valoare definită de IANA . De exemplu :
Content-Type: text/plain; charset=utf-8Această codificare nu trebuie confundată cu codificarea de transfer , specificată de antetul " Content-Transfer-Encoding: ". În cazul conținutului textual, cele două codificări sunt aplicate succesiv. De exemplu :
Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ceci est un message encod=C3=A9 en UTF-8, puis transform=C3=A9 en ASCII par la m=C3=A9thode "Quoted-Printable".În acest exemplu, litera „é” este codificată în UTF-8 de doi octeți de valori hexazecimale C3 și A9, care sunt la rândul lor codificate în Citat-Printabil prin secvența „ =C3=A9 ”.
Începând cu RFC 2822 , numele antetelor mesajelor și valorile acestora sunt întotdeauna în caractere ASCII. Valorile care conțin date care nu sunt ASCII trebuie să utilizeze așa - numita sintaxă „ cuvânt codat ” a MIME ( RFC 2047 ) în locul valorilor text standard. Această sintaxă folosește șiruri de caractere ASCII atât pentru a specifica codificarea originală a textului (echivalentul atributului charset=antet Content-Type:), cât și codarea de transfer (echivalent cu antetul Content-Transfer-Encoding:).
Sintaxa este:
=?encodage?méthode?texte?=Codurile ASCII pentru semnul întrebării ( ?) și semnul egal ( =) nu ar trebui să fie reprezentate direct, deoarece sunt utilizate pentru a delimita cuvintele codificate. Codul ASCII pentru caracterul spațial nu ar trebui, de asemenea, să fie utilizat, deoarece poate provoca erori la codificatoarele mai vechi, cum ar fi separarea cuvintelor nedorite. Pentru a face codarea mai ușoară și mai ușor de citit, caracterul de subliniere (" _ ") este utilizat pentru a reprezenta spațiul. Prin urmare, caracterul de subliniere nu mai poate fi reprezentat direct. Utilizarea cuvintelor codificate în anumite părți ale antetelor impune restricții caracterelor care trebuie reprezentate direct.
De exemplu,
Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=este interpretat ca:
Subiect: ¡Hola, señor!Formatul cuvântului codificat nu este utilizat pentru numele antetelor (de exemplu „ Subject: ”). Aceste nume de antet sunt întotdeauna în limba engleză în mesaj. Când mesajul este vizualizat pe un client de e-mail care nu vorbește în limba engleză, numele antetului pot fi traduse de client.
Un mesaj MIME multipart specifică o linie separatoare în antetul " Content-type: ", prin atributul " boundary= ". Această separare, care nu ar trebui să apară nicăieri altundeva, este plasată între părți și la începutul și la sfârșitul corpului mesajului după cum urmează:
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''--Fiecare dintre aceste părți constă din propriul antet de conținut (zero, unul sau mai multe câmpuri de antet Content-*:) și un corp. Mai multe părți pot fi incluse în alte părți multiple, fiecare având propriile limite. Câmpul Content-Transfer-Encoding:unui tip multipart ar trebui să fie " 7bit ", " 8bit " sau " binary " pentru a evita probleme cu decodarea diferitelor straturi de multipart. Blocul multipart nu are set de caractere, caracterele non-ASCII din anteturi sunt procesate de sistemul de cuvinte codificat, iar corpurile pot avea un set de caractere specificat adecvat conținutului lor.
Note:
Standardul MIME definește mai multe subtipuri de mesaje multipart pentru a specifica natura diferitelor părți ale mesajului și relațiile lor cu alte părți. Subtipul este specificat de antetul " Content-type: " mesajului de atașare. De exemplu, un mesaj MIME multipart care utilizează subtipul " digest " ar trebui să aibă antetul " Content-Type: " la " multipart/digest ". RFC definește inițial patru subtipuri: " mixed ", " alternate ", " digest " și " parallel ". O aplicație trebuie să accepte cel puțin subtipurile „ mixed ” și „ digest ”, celelalte sunt opționale. Subtipuri suplimentare precum " signed " sau " form-data " au fost definite în alte RFC-uri .
Următoarele subtipuri sunt utilizate în principal:
mixedTipul " multipart/mixed " (definit în RFC2046, Secțiunea 5.1.3 ) este utilizat pentru a trimite fișiere cu anteturi diferite " Content-type: " (ca atașamente). Dacă fișierele sunt ușor de citit sau sunt imagini, majoritatea clienților de e-mail afișează aceste fișiere direct în conținutul mesajului (cu excepția cazului în care " Content-disposition: " antetul specifică altfel). În caz contrar, fișierele sunt văzute ca atașamente. Tipul de conținut implicit pentru aceste părți este „ text/plain ”.
RFC specifică, de asemenea, că toate subtipurile de " multipart " nerecunoscute de o implementare ar trebui tratate la fel ca " multipart/mixed ".
digestTipul " multipart/digest " (definit în RFC2046, Secțiunea 5.1.5 ) este modalitatea simplă de a trimite mai multe mesaje text. Tipul de conținut implicit este „ message/rfc822 ”.
alternativeTipul „ multipart/alternative ” (definit în RFC2046, secțiunea 5.1.4 ) indică faptul că fiecare parte este o versiune alternativă a aceluiași conținut într-un format diferit. Formatele sunt ordonate în ordine crescătoare de fidelitate față de conținutul original. Receptorul poate alege astfel cea mai bună reprezentare pe care este capabil să o proceseze, în general, pe ultima din listă.
Deoarece un client nu dorește, în general, să trimită conținut mai puțin semnificativ decât textul simplu, acesta este trimis mai întâi, ceea ce simplifică procesarea pentru clienții care nu înțeleg tipul " multipart ", deoarece este partea vizibilă din prima.
Principala utilizare a tipului " multipart/alternative " este de a trimite e-mailuri în format HTML cu echivalentul său în format text pentru a menține lizibilitatea mesajului pentru un client de e-mail care nu poate afișa HTML (client text).
Deși fiecare parte a postării ar trebui să reprezinte același conținut, nu există nicio garanție. De exemplu, este mai ușor pentru un filtru de spam să scaneze partea de text simplu a unui mesaj, mai degrabă decât partea HTML; întrucât editorul de spam va construi în schimb un mesaj HTML cu conținutul său publicitar și un mesaj text simplu care este inofensiv sau fără legătură cu publicitatea sa.
Tipul " multipart/related " (definit în RFC2387 ) este utilizat pentru a specifica că diferitele părți nu trebuie tratate individual, ci ca un întreg. Mesajul constă dintr-o parte rădăcină (prima, în mod implicit) care face referire la alte părți, care pot face referire și la alte părți. Părți din mesaje sunt adesea menționate prin identificatorul de conținut (antetul Content-ID: ). Sintaxa referințelor nu este specificată, este lăsată în intenția protocolului utilizat.
Una dintre utilizările obișnuite ale acestui subtip este de a trimite o pagină web cu imaginile sale într-un singur mesaj. Partea rădăcină conține documentul HTML, iar imaginile sunt stocate în următoarele părți.
reportTipul " multipart/report " (definit în RFC3462 ) reprezintă un mesaj care conține date formatate pentru a fi citite de un server de e-mail. Acesta conține o parte a tipului " text/plain " (sau alt conținut ușor de citit) și alta de tip " message/delivery-status " care conține datele formatate pentru serverul de poștă electronică.
signedTipul " multipart/signed " (definit în RFC1847, secțiunea 2.1 ) este utilizat pentru a atașa o semnătură digitală la un mesaj. Este alcătuit din două părți: corpul mesajului și semnătura. Întreaga parte a corpului mesajului, inclusiv antetele MIME, este utilizată pentru a genera semnătura. Sunt posibile diferite tipuri de semnături, cum ar fi „ application/pgp-signature ” sau „ application/x-pkcs7-signature ”.
encryptedTipul " multipart/encrypted " (definit în RFC1847, secțiunea 2.2 ) este utilizat pentru a trimite conținut criptat . Prima parte a acesteia definește informațiile necesare descifrării celei de-a doua părți (de tipul " application/octet-stream ").
form-dataTipul " multipart/form-data " (definit în RFC2388 ) este utilizat pentru a trimite date dintr-un formular. Definit inițial ca parte a HTML 4.0 , este mai frecvent utilizat pentru a trimite fișiere prin HTTP .