Descrierea mimei

Specificația MIME

MIME (extindere prin poștă electronică multifuncțională)

Într-un sens, standardul MIME este ortogonal față de standardul RFC822. În cazul în care acesta din urmă este descrisă în detaliu în scrierea textului antet e-mail și mecanismul său de a trimite organismului, apoi MIME, orientat în principal descrierii din antetul subiect pentru structura corpului mesajului de e-mail și posibilitatea elaborării unei scrisori de articole de informații de diferite tipuri.







În standard, sunt rezervate mai multe modalități de reprezentare a informațiilor eterogene. În acest scop, sunt utilizate câmpuri speciale pentru antetul mesajului de poștă electronică:
  • câmpul versiunii MIME, care este folosit pentru a identifica mesajul pregătit în noul standard;
  • un câmp pentru descrierea tipului de informații din corpul mesajului, care permite interpretarea corectă a datelor;
  • un câmp al tipului de codificare a informațiilor din corpul mesajului indicând tipul procedurii de decodare;
  • două câmpuri suplimentare rezervate pentru o descriere mai detaliată a corpului mesajului.

Standardul MIME este conceput ca o specificație extensibilă, ceea ce înseamnă că numărul de tipuri de date va crește odată cu evoluția formelor de prezentare a datelor. Trebuie avut în vedere faptul că anarhia de tipuri (creștere nelimitată) nu este de asemenea permisă. Fiecare tip nou trebuie în mod obligatoriu înregistrat la IANA (Autoritatea pentru Numere Atribuite la Internet). Să trăim în mai multe detalii cu privire la forma și scopul câmpurilor definite de standard.

Câmpul tipului de codare al mesajului de e-mail (Content-Transfer-Encoding).
Multe date sunt trimise prin poștă în forma lor originală. Acesta poate fi caractere 7bit, caractere 8bit, caractere 64base și așa mai departe. Cu toate acestea, atunci când lucrăm în medii de e-mail eterogene, este necesar să determinăm mecanismul prezentării lor într-o formă standard - US-ASCII. Pentru aceasta, există proceduri pentru codificarea unui astfel de tip de date. Cel mai utilizat pe scară largă este uuencode. Pentru ca datele să fie despachetate corect și câmpul "Send-Encoding" este setat în standard. Sintaxa pentru acest câmp este:

Câmp de versiune MIME (versiunea MIME)

Câmpul de versiune este indicat în antetul mesajului de poștă electronică și vă permite să determinați programul de livrare a poștei prin care mesajul este pregătit în standardul MIME. Formatul câmpului arată astfel:

Câmpul versiunii este indicat în antetul general al mesajului de e-mail și se referă la întregul mesaj. Aici este pertinent faptul că, spre deosebire de standardul RFC822, standardul MIME vă permite să amestecați câmpurile antetului mesajului cu corpul mesajului. Prin urmare, toate câmpurile sunt împărțite în două clase: câmpuri antet comune care sunt scrise la începutul mesajului de poștă și câmpuri antet privat care se referă numai la anumite părți ale mesajului compozit și sunt scrise înaintea lor.

Câmpul tipului de conținut al corpului mesajului (Content-Type)

Să examinăm mai atent fiecare dintre tipurile acceptate de standardul MIME.

"Richtext" definește textul cu secvențe de control speciale încorporate în el, numite etichete în conformitate cu standardul de limbaj de marcare SGML. Etichetele reprezintă o secvență de caractere, cum ar fi "<строка-символов>"" Șir de caractere "definește o acțiune de control.Etichetele sunt împărțite în etichete de la începutul elementului de text ("<.>") și etichete ale capătului elementului text ("") Ca exemplu al unei astfel de marcări, poate fi citat următorul fragment de text:

În acest fragment înseamnă alocarea de caractere "bold", - italic, - imprimare fină, - semn "<", игнорирование обозначено как , linie nouă ca .

"Multipart".
Acest tip de conținut corporal al mesajului poștal definește un document mixt. Un document mixt poate consta din fragmente de date de diferite tipuri. Acest tip are un număr de subtipuri.

Subtipul "mixt" specifică un mesaj format din mai multe fragmente care sunt separate printr-o limită definită ca parametru de subtip. Iată un exemplu simplu:

Subtipul "digest" este destinat unui mesaj de mail multifuncțional atunci când sunt necesare diferite părți pentru a atribui informații mai detaliate decât un tip:







Exemplul de mai sus arată cum puteți utiliza subtipul "digest" pentru a trimite e-mail diferiților utilizatori și în moduri diferite, utilizând câmpurile "De la:" și "Subiect" ca anteturi private.

Introduceți mesajul ".
Acest tip este conceput pentru a lucra cu mesajele obișnuite de poștă electronică, care totuși nu pot fi trimise prin poștă din mai multe motive. Aceste motive sunt explicate prin subtipurile de acest tip.

Subtipul "parțial" este destinat trimiterii unui mesaj mare în părți pentru asamblarea automată ulterioară la receptor.
Acest mecanism poate fi util atunci când gateway-urile de poștă intermediară limitează dimensiunea individuală a mesajelor trimise. astfel Acest subtip indică faptul că litera conține numai o parte dintr-un mesaj mare.

Pentru acest subtip, trebuie să specificați trei parametri:
  1. "id" este un identificator unic care vă permite să găsiți restul mesajului.
  2. "număr" este un număr care indică numărul piesei mesajului.
  3. "total" este un număr întreg care înseamnă numărul total de piese. Este necesar numai în ultima parte și este opțională (deși recomandată) pentru părțile anterioare. Acești parametri pot urma în orice ordine.
Când se asamblează astfel de mesaje la destinație, trebuie luate în considerare următoarele reguli:
  1. Toate câmpurile de antet ale părții 1, cu excepția celor care încep cu "Conținut" și "Mesaje-ID", "Criptare" și "MIME-Versiune" speciale, trebuie copiate în antetul noii litere generale.
  2. Numai câmpurile de antet imbricate litere care încep cu „Content-“, precum și câmpul „ID-ul mesajului“, „criptat“ și „MIME-Version“, trebuie să fie adăugate la antetul unei noi scrisori comune, toate celelalte domenii ar trebui să fie ignorate
  3. Titlurile celei de-a doua părți și ale pieselor ulterioare sunt complet ignorate.

Comentarii despre codificare organism MIME litere încheiat în cadrul mesajului corpului / partiala: ca tipul de date „mesajul“ niciodată nu poate fi codificat în Base64 sau Quoted-tipărit, poate să apară următoarea problemă în cazul în care tipul de mesaj / partiala literele organism, în care suportă transportul pe 8 biți. Datele binare vor fi împărțite în mai multe mesaje / obiecte parțiale, fiecare dintre acestea fiind obligat să fie transportate în formă binară. Dacă aceste obiecte au trebuit să treacă prin poarta de acces la mediul transportului pe 7 biți, acestea nu au putut fi recodate în formă seimbitnuyu fără a aștepta sosirea tuturor părților mesajului, colectarea acestora împreună, și apoi codificarea unui mesaj în codificare pe 7 biți (Base64 sau citat-printable) . Deoarece există posibilitatea ca diferitele părți să meargă în moduri diferite (prin intermediul unor gateway-uri diferite), o astfel de decizie nu este acceptabilă. Prin urmare, MIME determină faptul că scrisorile de tip mesaj / parțial trebuie să aibă o codificare pe 7 biți și o valoare corespunzătoare a câmpului de codare a transferului de conținut. Chiar și pentru sistemele de transport care susțin "8-bit" și "binar", este interzisă utilizarea acestora pentru mesaje / date parțiale.

Mulți agenți de e-mail pot fragmenta automat literele mari.

Includerea câmpului "Referințe" în anteturile părții a doua și ulterioare referitoare la identificatorul părții anterioare poate fi utilă pentru programele de poștă electronică care înțeleg și procesează legături. Cu toate acestea, prezența acestui câmp nu este necesară.

Câmpul antet "Criptare" nu este folosit, dar regulile de mai sus oferă o interpretare corectă a acestuia dacă apare atunci când procesează mesaje / fragmente parțiale. Iată un exemplu de trimitere a unui mesaj audio rupt în părți:

Atributele subtipului definesc identificatorul mesajului (id), numărul porțiunii (numărul) și numărul total de porțiuni (total). Trebuie notat că fiecare parte are propriul câmp "Content-Type". Aceasta înseamnă că întreg mesajul poate consta din părți de diferite tipuri.

Un alt subtip este "Organismul extern", care vă permite să vă referiți la sursele de informație care sunt externe mesajului. Acest subtip este similar cu un hypertext link de tipul "text". Să dăm un exemplu concret:

Singurul parametru întotdeauna necesar pentru "mesaj / corp exterior" este "tip de acces". Parametrii rămași pot sau nu pot fi obligatorii, în funcție de valoarea parametrului "tip acces".

Valoarea acestui parametru este un cuvânt insensibil în cazul literelor, adică mecanismul de acces prin care fișierul sau datele pot fi preluate. Valorile pot fi următoarele (dar fără a se limita la aproape): "FTP", "anon-FTP", "TFTP", "AFS", "LOCAL-FILE" si "E-mail-server". Viitoarele valori posibile, altele decât cele experimentale, începând cu "X", ar trebui înregistrate la IANA.

În plus, următorii trei parametri sunt opționali pentru toate metodele de acces:

EXPIRARE - Data (sintaxa "data-timp" RFC 822 permite 4 cifre în acest câmp), după care nu este garantată existența datelor externe.

SIZE - dimensiunea (în octeți) a datelor. Permite destinatarului să decidă dacă să cheltuiască resurse pentru citirea datelor externe. Dimensiunea este specificată pentru forma canonică a datelor (adică înainte de aplicarea oricărei transformări).

PERMIS - un câmp insensibil la caz, care indică dacă clientul se așteaptă sau nu să suprascrie datele. În mod implicit, sau când acest parametru are valoarea "citit", se presupune că clientul nu are acest drept și că dacă datele sunt citite o dată, nu vor mai fi necesare. Dacă PERMISIA are valoarea "read-write", orice copie locală nu poate fi considerată decât o cache. "citirea" și "scrierea" sunt singurele valori predefinite pentru PERMIS.

Nivelele antetului în toate caroseria mesajului / corpului exterior TREBUIE să includă câmpul antetului Content-ID pentru a specifica un identificator unic indicând datele externe.

Legenda care descrie datele corpului extern, cum ar fi numele de fișiere sau comenzile serverului de mail, trebuie să fie în setul de caractere US-ASCII.

Ca și mesajul / tipul parțial, corpul mesajului / tipul corpului extern trebuie să aibă o valoare de codificare a transferului de conținut de "7-biți" (implicit). În special, chiar și în sistemele care suportă transportul pe 8 biți, este interzisă aplicarea codării de transfer de conținut "8-bit" și "binar" pentru datele de tip de mesaj / corpul exterior.







Articole similare

Trimiteți-le prietenilor: