Többcélú internetes levélkiterjesztések (MIME) vagytöbbfunkciós kiterjesztések Az internetes levelezésolyaninternetes szabvány,amely kiterjeszti aze-mailekadatformátumátazASCIIkivételévelkülönbözőkarakterkódolásúszövegek, nem szöveges tartalom, több tartalom és fejlécinformációk támogatására azASCIIkivételével. Mivel az e-maileket általábanSMTP-nkeresztül küldikMIME formátumban, ezeket az e-maileket gyakranSMTP / MIMEe-maileknek nevezik.
Eredetileg az SMTP-t csak szöveges fájlok továbbítására tervezték ( ASCII kódolással ). A multimédia megjelenésével és az irodai alkalmazások növekvő használatával felmerült az igény a szöveges fájlok, a bináris fájlok (irodai alkalmazások formátuma, képek, hangok, tömörített fájlok) cseréjére.
A MIME szabvány által meghatározott tartalomtípusok az e-mailek küldésén kívül más célokra is felhasználhatók olyan kommunikációs protokollokban , mint a HTTP a világhálón .
A MIME-t eredetileg öt RFC-ben határozták meg : RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049. Az RFC 2045- et kiegészíti az RFC 2077. Az immár elavult RFC 2048 helyébe RFC 6838 és RFC 4289 lép.
Az alapvető e-mail továbbítási protokoll, az SMTP, csak az ASCII karaktereket támogatja (amelyek 7 bit hosszúak ). Ez korlátozza az e-maileket olyan üzenetekre, amelyek csak ezeket a karaktereket tartalmazzák, ami kevés olyan nyelv, mint az angol . Az ASCII nem támogat más latin ábécé alapú nyelveket, beleértve a diakritikus nyelveket is , ezért ezeket az üzeneteket nem lehet megfelelően megjeleníteni az alapvető e-mailekben.
A MIME meghatározza az egyéb típusú információk elküldésének mechanizmusait, például az ASCII-től eltérő karakterkódolással (tehát esetleg nem angol nyelven) vagy bináris adatok (ideértve a képeket , hangokat , filmeket vagy számítógépes programokat tartalmazó fájlokat) szöveges küldését .
A MIME szintén alapvető eleme a kommunikációs protokolloknak, mint például a HTTP , amelyek megkövetelik az adatok küldését ugyanabban a kontextusban, mint az e-mailek küldése , Annak ellenére, hogy ezek az adatok nem e-mailek. Az adatok MIME formátumú integrálását vagy kibontását általában az e-mail kliens vagy az e-mail szerver végzi automatikusan, amikor az e-mailt elküldi vagy fogadja.
Az alapvető e-mail formátum határozza RFC 2822, amely egy frissítés az RFC 822. Ezek a szabványok formátumát fejlécek és a test tartalmazó e-mail szövegének, valamint az általános fejlécek, mint a „ To: ”, „ Subject: »« From: »vagy« Date: ”. A MIME további fejléceket határoz meg az üzenet tartalomtípusához (" Content‑Type: ") és átviteli kódolásához (" Content-Transfer-Encoding: "). Az átviteli kódolással az üzenet tartalma lefordítható az ASCII-be. Ennek a fordításnak köszönhetően a kezdeti tartalom tetszőleges 8 bites adatokat tartalmazhat (szöveg UTF-8-ban , bináris fájl stb.). A MIME meghatározza ennek a funkciónak az üzenetfejlécekben történő felhasználásának mechanizmusát is; ez lehetővé teszi például az ékezeteket az e-mail tárgyában vagy a címzett nevében.
A MIME bővíthető. Meghatározása tartalmaz egy módszert új tartalomtípusok vagy más attribútumértékek regisztrálására.
A MIME definíciójának egy másik kifejezett célja nem az, hogy megváltoztassa a már létező levelezőszervereket, hanem az, hogy az alapvető e-mailek megfelelően működjenek a már meglévő ügyfelekkel. Ezt a célt azzal érjük el, hogy a MIME üzenetek attribútumai nem kötelezőek, és az alapértelmezett viselkedés egy MIME nélküli szöveges üzenet létrehozása, amelyet az ügyfél helyesen értelmezhet.
Ennek a fejlécnek a jelenléte azt jelzi, hogy az üzenet tartalma MIME formátumban van formázva. Az érték általában "1,0", így a fejléc a következőképpen jelenik meg:
MIME-Version: 1.0Ez a fejléc jelzi az üzenet tartalmának internetes média típusát , amely típusból és altípusból áll , például:
Content-Type: text/plainA MIME lehetővé teszi, hogy az üzenetek több részből álljanak egy fa struktúrában , multiparta belső csomópontok " " típusával .
Ez a mechanizmus különösen a következőket támogatja:
A MIME specifikáció ( RFC 2045 ) meghatározza az átviteli módszerek vagy kódolások készletét (ebben az IANA-listában felidézve ), hogy bármilyen adatot ASCII szöveg formájában ábrázoljon. A MIME fejléc " Content-Transfer-Encoding " jelzi az alkalmazott módszert. Lehet, hogy az alábbi értékek egyike van (nem hajlamos a törésre ):
Nincs külön kódolás megadva az önkényes bináris adatok küldéséhez a 8BITMIME kiterjesztésű SMTP transzportokon keresztül. A Base64 vagy Quoted-Printable módszereket kell használni (azok hatékonyságával együtt). Ezek a korlátozások nem vonatkoznak a MIME egyéb felhasználási módjaira, például a MIME vagy MTOM mellékletű webszolgáltatásokra .
A szöveges adatokat (" text " típus ) egy bizonyos karakterkódolással írják , például latin-9 vagy UTF-8 . Ez a kódolás megadható charset= a „ Content-Type: ” fejléc „ ” attribútumával . Ez bármely, az IANA által meghatározott értéket vehet igénybe . Például :
Content-Type: text/plain; charset=utf-8Ezt a kódolást nem szabad összekeverni a " " fejlécben megadott átviteli kódolássalContent-Transfer-Encoding: . Szöveges tartalom esetén a két kódolást egymás után alkalmazzák. Például :
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".Ebben a példában az "é" betűt az UTF-8 kódolja két bájt hexadecimális C3 és A9 értékkel, amelyeket viszont az " " szekvencia idézőjelben nyomtat=C3=A9 .
Az RFC 2822-től kezdődően az üzenetfejlécek neve és értéke mindig ASCII karakterben szerepel. Azoknál az értékeknél, amelyek nem ASCII adatokat tartalmaznak, a szabványos szöveges értékek helyett a MIME úgynevezett " kódolt szó " szintaxisát kell használniuk ( RFC 2047 ). Ez a szintaxis ASCII karakterláncokat használ a szöveg eredeti kódolásának (a charset=fejléc attribútumának megfelelője Content-Type:) és az átviteli kódolásának (a fejlettel egyenértékű) megadásához Content-Transfer-Encoding:.
A szintaxis a következő:
=?encodage?méthode?texte?=A kérdőjel ( ?) és az egyenlőségjel ( ) ASCII-kódjait =nem szabad közvetlenül ábrázolni, mivel kódolt szavak elhatárolására használják őket. A szóköz karakter ASCII kódját szintén nem szabad használni, mivel ez hibákat okozhat a régebbi kódolókban, például nem kívánt szóelválasztást. A kódolás könnyebbé és könnyebben olvashatóvá tételéhez az aláhúzás karaktert (" _ ") kell használni a szóköz képviseletében. Ezért az aláhúzás karakter már nem ábrázolható közvetlenül. A kódolt szavak használata a fejlécek bizonyos részeiben korlátozásokat szab a közvetlenül ábrázolandó karakterekre.
Például,
Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=úgy értelmezik:
Tárgy: ¡Hola, señor!A kódolt szóformátumot nem használják a fejlécek nevéhez (például " Subject: "). Ezek a fejlécnevek mindig angolul szerepelnek az üzenetben. Ha az üzenetet nem angolul beszélő e-mail kliensen tekintik meg, az ügyfél lefordíthatja a fejlécek nevét.
A többrészes MIME üzenet elválasztó sort ad meg a " Content-type: " fejlécben , a " " attribútumon keresztülboundary= . Ezt a szétválasztást, amelynek sehol máshol nem szabad megjelennie, az üzenet törzse részei között, valamint az üzenet törzsének elején és végén a következőképpen kell elhelyezni:
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''--Ezen részek mindegyike a saját tartalmi fejlécéből (nulla, egy vagy több fejlécmező Content-*:) és egy törzsből áll. Több rész is beilleszthető más több részbe, mindegyiknek megvan a maga határa. A Content-Transfer-Encoding:többrészes mező mezőjének " 7bit ", " 8bit " vagy " binary " kell lennie , hogy elkerülje a többrészes különböző rétegek dekódolásával kapcsolatos problémákat. A többrészes blokknak nincs karakterkészlete, a fejlécekben szereplő nem ASCII karaktereket a kódolt szórendszer dolgozza fel, és a testek rendelkezhetnek a tartalmuknak megfelelő meghatározott karakterkészlettel.
Megjegyzések:
A MIME-szabvány a többrészes üzenetek több altípusát definiálja, hogy meghatározza az üzenet különböző részeinek jellegét és kapcsolatát más részekkel. Az altípust Content-type: a csatoló üzenet " " fejléce határozza meg . Például a " digest " altípust használó, többrészes MIME-üzenetek fejlécének " Content-Type: " - " multipart/digest " - ig kell lennie . Az RFC Kezdetben négy altípust határoz meg: " mixed ", " alternate ", " digest " és " parallel ". Egy alkalmazásnak támogatnia kell legalább a „ mixed ” és „ digest ” altípust , a többi választható. További altípusokat, például " signed " vagy " form-data ", más RFC-k definiáltak .
Főként a következő altípusokat használják:
mixedA " multipart/mixed " típust (az RFC2046 5.1.3. Szakaszában definiálva) különböző fejlécű fájlok küldésére használják Content-type: (mellékletként). Ha a fájlok könnyen olvashatók vagy képek, a legtöbb e-mail kliens ezeket a fájlokat közvetlenül az üzenet tartalmában jeleníti meg (hacsak a " Content-disposition: " fejléc másként nem rendelkezik). Ellenkező esetben a fájlok mellékletként tekinthetők meg. Ezen részek alapértelmezett tartalomtípusa " text/plain ".
Az RFC azt is meghatározza, hogy multipart a megvalósítás által nem felismert " " összes altípust ugyanúgy kell kezelni, mint a " multipart/mixed ".
digestA " multipart/digest " típus (az RFC2046 5.1.5. Szakasza meghatározza ) az egyszerű mód több szöveges üzenet küldésére. Az alapértelmezett tartalomtípus " message/rfc822 ".
alternativeA " multipart/alternative " típus (az RFC2046 5.1.4. Szakaszában definiálva ) azt jelzi, hogy minden rész ugyanazon tartalom alternatív változata, különböző formátumban. A formátumokat az eredeti tartalomhoz való hűség növekvő sorrendjében rendezik. A vevő így kiválaszthatja a legjobb ábrázolást, amelyet általában képes feldolgozni a lista utolsó.
Mivel egy kliens általában nem akar kevesebb tartalmú tartalmat küldeni, mint a sima szöveg, ezt először elküldik, ami egyszerűbbé teszi a feldolgozást azoknak az ügyfeleknek, akik nem értik a " multipart " típust , mivel az először a látható rész.
A " multipart/alternative " típus fő célja az, hogy e-maileket küldjön HTML formátumban , ennek megfelelő szöveges formátumban, hogy fenntartsa az üzenet olvashatóságát egy olyan e-mail kliens számára, amely nem képes megjeleníteni a HTML-t (szöveges kliens).
Bár a bejegyzés egyes részei vélhetően ugyanazt a tartalmat képviselik, nincs garancia. Például a spamszűrő számára könnyebb az üzenet egyszerű szöveges részét beolvasni, nem pedig a HTML részt; mivel a spamszerkesztő ehelyett egy HTML-üzenetet állít össze hirdetési tartalmával és egy sima szöveges üzenettel, amely ártalmatlan vagy nem kapcsolódik a hirdetéséhez.
A multipart/related ( z ) " " típus (az RFC2387- ben definiálva ) annak meghatározására szolgál, hogy a különböző részeket nem külön-külön, hanem egészükként kell kezelni. Az üzenet egy gyökér részből áll (alapértelmezés szerint az első), amely más részekre hivatkozik, amelyek más részekre is hivatkozhatnak. Az üzenetek egyes részeire gyakran a tartalomazonosítójuk (" Content-ID: " fejléc ) hivatkozik. A hivatkozások szintaxisa nincs meghatározva, hanem az alkalmazott protokoll szándékára van bízva.
Ennek az altípusnak az egyik leggyakoribb felhasználása az, hogy a képeket tartalmazó weboldalt egyetlen üzenetben küldje el. A gyökérrész tartalmazza a HTML dokumentumot, és a képeket a következő részek tárolják.
reportA multipart/report ( z ) " " típus (az RFC3462- ben definiálva ) olyan üzenetet jelent, amely az e-mail szerver által olvasásra formázott adatokat tartalmaz. Ez tartalmaz egy " text/plain " típusú (vagy más könnyen olvasható tartalmat) egy részt, és egy " message/delivery-status " típusú részt, amely tartalmazza a levelezési kiszolgálóhoz formázott adatokat.
signedA " multipart/signed " típust (az RFC1847 2.1 szakaszában definiálva ) használják digitális aláírás csatolására egy üzenethez. Két részből áll: az üzenet törzséből és az aláírásból. Az üzenet teljes törzsrésze, beleértve a MIME fejléceket is, az aláírás előállítására szolgál. Különböző típusú aláírások lehetségesek, például " application/pgp-signature " vagy " application/x-pkcs7-signature ".
encryptedA " multipart/encrypted " típust (az RFC1847 2.2 szakaszában definiálva ) titkosított tartalom küldésére használják . Első része meghatározza a második rész (" application/octet-stream " típusú ) megfejtéséhez szükséges információkat .
form-dataAz " multipart/form-data " típust (az RFC2388- ban definiálva ) az adatok küldésére használják egy űrlapról. Eredetileg a HTML 4.0 részeként definiálták, és gyakrabban használják fájlok küldésére HTTP-n keresztül .