header területén content-type

A fejléc mező „Content-Type”

E területen - a legteljesebb leírását szereplő adatok a testet úgy, hogy az e-mail szer (program) a kedvezményezett választhatott egy megfelelő mechanizmust, azok obabotki. Ez az első alkalom ezen a területen már az RFC 1049, de volt egy egyszerűbb szintaxist.

Bár sok lehetőség (módosítók altípus) van értelme csak egy bizonyos típusú, néhány még mindig globális ebben az értelemben. hogy azok alkalmazhatók az összes típusú (például, a paramétert „határ” csak akkor alkalmazható, hogy milyen típusú „multipart”, és a paraméter „charset” is használható többféle).

Eddig csak hétféle nevek, és bár ez elég. Emellett várható, hogy a bővítés a meglévő készlet támogatott adattípusok lesz rovására az új altípusai az eredetileg definiált adattípusok. A jövőben, a mellett a felső szintű névtípusokról lehet csak elfogadásával egy új változata a MIME szabványt. Ha bármely más ok miatt, a jelenlegi változat használatos nem regisztrált típusú tartalmak lehetnek, azt meg kell adni egy nevet kezdődő „X”, hogy hangsúlyozzák a nem szabványos állapotát, és megakadályozza a konfliktus előre a hivatalos neve annak a típus, hogy lehet beírni később.

A megfelelő feltöltés a mező Content-Type:

Itt egy sor speciális karakterek, eltér a beállított RFC 822 csak a karakterek „/”, „?”, „=” És a hiánya „” karakter.

Megjegyzés altípus ezen a területen kötelező, mert nincs alapértelmezett altípusok. Ezzel szemben a típus nevét, és altípusok paraméterek, a paraméter értékek általában kis- és nagybetűket, de lehet érzéketlen és - attól függően, hogy a paraméter. Például határ értékeket többrészes írni érzékenyek, és az értéke „hozzáférés” típusú üzenet / Külső-test nem.

Két elfogadható mechanizmus az új altípusai a mező Content-Type:

Hétféle előre magasabb szintű, további részletek a következők:

szöveg - szöveges információ. Az alapot a altípus - „sima” - megfelel a szokásos neformatirovnnomu szöveget, és nem igényel speciális szoftvert, hogy a szöveg, kivéve a támogatás nemzeti kódolást. Más altípusok esetében alkalmazott az elkészült szöveget, ha a szoftver segítségével, javíthatja azt vizualzatsiyu, hanem annak megértését, a tartalom az ötleteket tehet anélkül dpolnitelnogo szoftver. Lehetséges altípusok leírni könnyen olvasható formában a különböző szövegszerkesztők.

többrészes - üzenet tartalmát áll több adagban tartalmazó adatok kölcsönösen különböző típusú. Kezdetben meghatározott négy altípusa:

1. „Vegyes” - a legfontosabb;
2. „Alternatív” -, hogy képviselje ugyanazokat az adatokat különböző formátumokban;
3. „Párhuzamos” - ha a különböző részein a dokumentumot kell vizsgálni egyidejűleg;
4. „Digest” - ha az egyes részek az üzenet test egy „üzenet” típus.

üzenet - betűnként. A szervezet adatait tartalmazó típusa „message”, maga is része egy vagy több betűből, teljesen formázott szabvány szerinti RFC 822, ami viszont tartalmazhat saját fejléc mező „Content-Type”.
altípusok:

1. "Rfc822" - alapanyagok;
2. A „részleges” - számára meghatározott részlegesen idézett levelek fragmentáció elkerüléséhez a testek szereplő betűk esetében túl sok a teljes hossza a megfelelő átviteli kapacitás;
3. „Külső-test” - jelöli, hogy az üzenet test nagyon nagy, és túl van a levél.

A kép - a kép adatait. Graphics megköveteli a megfelelő kimeneti eszközök (grafikus kijelző, nyomtató, fax) megjelenítéséhez információkat. Kezdetben azonosított két altípusa a leggyakoribb képformátumok - JPEG és GIF.

audio - audio információk. Szükség van audio eszközt (hangszóró vagy fejhallgató) információ megjelenítésére. A fő altípusát - „alap”.

alkalmazás - általában értelmezhetetlen bináris kódot vagy információt feldolgozásra szánt e-mail program.

Alapértelmezésben a betűket, mint az RFC 822 szabvány, csak írj (címkézetlen) szöveg azon a nyelven kódolt US-ASCII, MIME-előírásoknak, lehet leírni, mint a "Content-type: text / plain; charset = us-ascii". Ezt az értéket feltételezünk, ha a mező Content-type nincs definiálva. Ezért a címzett e-mail program félreértelmezi a az üzenet tartalmát, ha a küldő nem tárgykörbe Content-type, de valójában a levél szövegét egy másik kódolási, vagy akár írja.

Ennek hiányában a területen Content-type vagy MIME-Version mező nem lehet pontosan, a fejléc MIME-írás, hogy az írás nyelve kódolás US-ASCII, mert még mindig eleget küldemények, amelyek nem használják megállapodások MIME. De bár az is lehetséges, hogy a levél nem tartalmaz a fejléc mezők MIME-Version és Content-Type, bármit tartalmazhat szeretne, például a Unix tar-archívum, gzip-pel tömörítve és befejezte a uuencode, mégis az alkotók ajánlatos az e-mail programok ezt a tényt anélkül, hogy figyelmet és hangsúlyt az alapértelmezett érték, azaz "Text / plain; charset = us-ascii".

Meg kell érteni, hogy a várható növekedése a regisztrált méltó típusok és altípusok, különösen a tartalom a levelek a jövőben. Ha a levelező ez megfelel az ismeretlen mező értéke Content-type, meg kell értelmezni a tartalmát a levél, mint az „application / octet-stream”.