| OSI modelis |
| 7:Lietojumslānis |
|---|
| 6:Pasniegšanas slānis |
| 5:Sesijas slānis |
| 4:Transporta slānis |
| 3:Tīkla slānis |
| 2:Datu posma slānis |
| 1:Fiziskais slānis |
Multipurpose Internet Mail Extensions (angļu valodā "interneta pasta vairākmērķu paplašinājumi") jebMIME irinterneta standarts, kas paplašinae-pasta vēstules formātu. Galvenie paplašinājumi:
MIME ir aprakstīts sešosRFC:RFC 2045,RFC 2046,RFC 2047,RFC 4288,RFC 4289 unRFC 2077.
MIME standartā definētie satura tipi tiek izmantoti arī ārpus e-pasta, piemēram,HTTP protokolā.
E-pasta sūtīšanas protokolsSMTP pieļauj vēstules tikai 7bituASCII kodējumā. Tas bija pietiekami, rakstot tikai arlatīņu alfabēta burtiem. Citās valodās, kas izmantoja latīņu alfabētu, kurā iekļautasdiaktriskās zīmes (izmantoti 8 biti kā ASCII papildkodējums), rakstīto nevarēja korekti attēlot e-pasta vēstulē (8. bits tika nonullēts). To atrisināja ar SMTP paplašinājumu8BITMIME, kas tika publicēts1994. gadā (RFC 1652).
E-pasta vēstules pamatformāts ir definētsRFC 2822, kas nosaka, kādā veidā jāveido sūtījuma galvenes lauki un ķermenis. MIME paredzēti papildu galvenes lauki, kurā paziņo par satura tipu, vēstules ķermeņa teksta kodējumu. MIME ir ietverts kodēšanas mehānisms galvenes laukiem, piemēram, "Subject", kas ļauj galvenē izmantot citu valodu simbolus.
MIME standarts ir paplašināms. Tajā ir noteikts, kādā veidā var reģistrēt jaunus satura tipus un citas MIME atribūtu vērtības.
MIME tika izstrādāts tādā veidā, lai eksistējošie pasta serveri varētu darboties bez izmaiņām, ļaujot sūtīt parasta teksta vēstules abos virzienos kā agrāk. Tas tika panākts, izmantojot papilduRFC 822 veida galvenes laukus visiem MIME atribūtiem un veidojot MIME galvenes laukus neobligātus ar vērtībām pēc noklusējuma, kas nodrošināja, ka MIME neatbilstošus sūtījumus korekti interpretēts MIME atbalstošs klients. Bez tam, vienkāršu MIME teksta vēstuli MIME neatbilstošs klients pareizi interpretētu, pat nezinot MIME lauku nozīmi, un tekstu, kas saturētu ASCII simbolus, lietotājs varētu izlasīt.
GalveneMIME-Version norāda, ka sūtījums ir formatēts MIME standartā. Tā vērtība parasti ir "1.0". Galvene tiks parādīta:
MIME-Version: 1.0
Content-Type rāda sūtījuma saturainterneta medija tipu, kas sastāv no tipa un apakštipa. Piemēram:
Content-Type: text/plain
Izmantojot vairākdaļu tipu, MIME ļauj veidot vēstuli no vairākām daļām, kas izkārtotaskoka struktūrā, kurā lapu mezgli ir ar nevairākdaļas tipu, un nelapu mezgliem ir kāds no vairākdaļu tipa. Šis mehānisms atbalsta:
text/plain (tā ir arī noklusējuma vērtība);multipart/mixed artext/plain un citām neteksta daļām);multipart/mixed artext/plain daļu un oriģinālo vēstuli kāmessage/rfc822 daļu);multipart/alternative ar saturutext/plain untext/html formātā);image/jpg,audio/mp3,video/mp4, andapplication/mswork);1992. gada jūnijā (RFC 1341, vēlāk tika aizstāts arRFC 2045) tika noteiktas MIME metodes, kā attēlot bināros datus ASCII teksta formātā. GalveneContent-Transfer-Encoding rāda, kura kodēšanas metode tiek lietota:
7bit — līdz 998oktetiem rindā ar kodu no 1 līdz 127, kur ir atļauti tikai CR un LF (attiecīgi 13 un 10) kā daļa no CRLF rindas beigām. Šī ir vērtība pēc noklusējuma.quoted-printable — lieto, lai kodētu 8 bitu simbolus formā, kas apmierina7bit noteikumus. Paredzēts, ja dati pamatā sastāv noUS-ASCII simboliem, bet ir arī neliels daudzums baitu, kuru kodi ir virs 127.base64 — lieto, lai kodētu 8 bitu simbolus formā, kas apmierina7bit noteikumus. Pamatā izmanto 8 bitu neteksta datiem, bet reizēm arī teksta datiem, kuros bieži ir neUS-ASCII simboli.8bit — līdz 998 oktetiem rindā, kur ir atļauti tikai CR un LF (attiecīgi 13 un 10) kā daļa no CRLF rindas beigām.binary — jebkurā oktetu secībā.PēcRFC 2822 standarta sūtījuma galvenes nosaukumiem un vērtībām vienmēr jābūt ar ASCII simboliem; vērtībām, kuras satur ne ASCII datus, jālieto MIME kodēto vārdu sintaksi (RFC 2047). Šī sintakse izmanto ASCII simbolus, ar kuriem parāda gan oriģinālorakstzīmju kopu (charset), gan satura pārkodēšanas shēmu, kas parāda, kādā veidā simboli tikuši pārkodēti ASCII kodējumā.
Formāts ir: "=?rakstzīmju kopa?kodējums?pārkodētais teksts?=".
Kodētajā vārdājautājuma zīme "?" unvienādības zīme "=" ir rezervētie simboli, tad tie ir jāpārveido citādi. Arī atstarpes rakstzīmi nevar tieši attēlot, jo vecākiparseri var nevēlami sadalīt vārdu. Lai samazinātu pārkodēto tekstu un padarītu to vieglāk lasāmu, atstarpe tiek aizvietota ar pasvītrojuma rakstzīmi, bet līdz ar to pasvītrojumu nevar tieši attēlot.
Piemērs:
Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=
ko var interpretēt kā "Subject: ¡Hola, señor!".
Kodēto vārdu formātu nevar izmantot galvenes nosaukumam (piem.,Subject). Galvenes nosaukumi vienmēr irangļu valodā. Ja tiek skatīta vēstule ar citas valodas e-pasta klientu, tad galvenes nosaukumus klienta programma var parādīt pārtulkotus, ja tai ir tāda funkcija.
MIME vairākdaļu sūtījumaContent-type: galvenē ir jānorāda robežatdalītājsboundary. Šai simbolu virknei nav jāparādās nevienā no vēstules daļām, tā atrodas starp daļām, ka arī sūtījuma ķermeņa sākumā un beigās. Piemēram:
MIME-version: 1.0Content-type: multipart/mixed; boundary="frontier"This is a multi-part message in MIME format.--frontierContent-type: text/plainThis is the body of the message.--frontierContent-type: application/octet-streamContent-transfer-encoding: base64PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUgYm9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==--frontier--
Katra daļa sastāv no pašas satura galvenes (neviens vai vairākiContent- galvenes lauki) un ķermeņa. Vairākdaļu saturs var būtligzdojams.Content-Transfer-Encoding jābūt7bit,8bit vaibinary. Vairākdaļu blokam kā veselam nav rakstzīmju kopas, no ASCII atšķirīgi simboli daļas galvenē tiek pārveidoti pēc kodēto vārdu sistēmas, un daļas ķermenim ir rakstzīmju kopa, kas noteikta satura tipā (content-type.
Piezīmes:
MIME standarts paredz dažādus vairākdaļu sūtījuma apakštipus, kuru raksturo vēstules daļas un to saistību vienai ar otru. Apakštipu norāda visa sūtījumaContent-Type galvenē.RFC sākotnēji definēja četrus apakštipus:mixed,digest,alternative unparallel. Minimālā prasība pasta programmām ir tāda, ka tām jāatbalstamixed undigest, citi apakstipi nav obligāti. Citi apakštipi tika definēti vēlāk.
Zemāk ir apskatīti biežāk lietotie apakštipi.
Multipart/mixed tiek lietoti, lai sūtītufailus ar iekļautām dažādāmContent-Type galvenēm (jeb kā pievienojums). Ja tiek pārsūtīti attēli vai citi viegli lasāmi faili, vairums mūsdienu klientprogrammu var tos attēlot iekļautajā skatītājā. Citādi tie tiks piedāvāti kā pievienojumfaili. Pēc noklusējuma satura tips katrai daļai irtext/plain
DefinētsRFC 2046, sekcija 5.1.3
Multipart/digest ir vienkāršs veids, kā sūtīt saliktas teksta vēstules. Pēc noklusējuma satura tips katrai daļai irmessage/rfc822
DefinētsRFC 2231, sekcija 5.1.5
Multipart/alternative rāda, ka katra daļa ir "alternatīva" versija vienam un tam pašam (vai līdzīgam) saturam, katra dažādā formātā, kas noteikts tāsContent-Type galvenē. Šis formāts ir paredzēts, lai formatētam saturam līdzi tiktu "dots" arī oriģināls, ar "uzticamāko" (vienkārša teksta variantā) vispirms, un "mazāk uzticamo" beigās. Sistēma attēlošanai izvēlas labāko sūtījuma daļu, ja labāko daļu klientprogramma nespēj apstrādāt, tiek parādīta vienkāršākā daļa. Tas dod iespēju vēstuli vienkāršāk izlasīt lietotajiem, kuru klienti neatbalsta vairākdaļu sūtījumus.
Visbiežāk alternatīvo veidu izmantoHTML e-pasta sūtīšanai. To sagatavo no divām daļām: pirmajā ir vienkāršais teksts (text/plain), otrajā ir teksts, formatētsHTML (text/html). Ja klients neatbalsta HTML formatēšanu, tas parādīs vēstuli kā vienkāršu tekstu, HTML atbalstošs parādīs līdzīgu kā HTML lapu.
DefinētsRFC 2046, sekcija 5.1.4
Multipart/related izmanto, lai informētu, ka sūtījuma daļas nav jāapskata individuāli, bet gan ka tās ir daļas no viena vesela. Vēstule sastāv no "saknes" daļas (pēc noklusējuma pirmās), kas norāda uz citām iekļautajām daļām, kuras savukārt var saistīt citas daļas. Sūtījuma daļas parasti saista ar daļas galveniContent-ID. Atsauces sintakse nav noteikta, un to nosaka atkarībā no kodējuma vai protokola, kuru izmanto saistāmajā daļā.
Šo apakštipu plaši izmanto, lai sūtītu vēstuli kātīmekļa lappusi kopā ar attēliem. Saknes daļai jāsatur HTML dokuments, un tajā ietvertie attēlu tagi atsaucas uz attēliem, kas ir saglabāti nākamajās daļās.
DefinētsRFC 2387
Multipart/report ir sūtījuma tips, kas paredzēts e-pasta servera informēšanai. Tas ir sadalīts divās daļās, no kurām viena irtext/plain (vai cits viegli lasāms satura tips), bet otra irmessage/delivery-status, kura satur īpaši e-pasta serverim formatētus datus.
DefinētsRFC 3462
Multipart/signed lieto, lai sūtījumam pievienotuciparu parakstu. Tas sastāv no divam daļām: ķermeņa daļas un paraksta daļas. Ir iespējami daudzi paraksta tipi, piemeram,application/pgp-signature,application/x-pkcs7-signature.
DefinētsRFC 1847, sekcija 2.1
Multipart/encrypted izmanto, lai sūtītu šifrētu vēstuli. Pirmā daļa satur kontrolinformāciju, kas nepieciešama, lai atšifrētuapplication/octet-stream otro daļu.
DefinētsRFC 1847, sekcija 2.2
Multipart/form-data ir paredzēts vērtību nosūtīšanai ar formas palīdzību. Sākotnēji tas ir definēts kā daļa noHTML 4.0, un tiek plaši lietots, lai nodotu failus arHTTP.
DefinētsRFC 2388
| ||||||||||||||||||||||