Câmpul antet „Content-Type“
Scopul acestui domeniu - descrierea cât mai completă a datelor conținute în organism, astfel încât agentul de e-mail (program) beneficiarul ar putea alege un mecanism adecvat pentru obabotki lor. Pentru prima dată în acest domeniu a fost definit în RFC 1049, dar a avut o sintaxă mai simplă.
Deși multe opțiuni (modificatori de subtipuri) sunt semnificative numai pentru un anumit tip, unele sunt încă la nivel mondial în acest sens. că acestea sunt aplicabile tuturor tipurilor (de exemplu, parametrul „limita“ se aplică numai la tipul de „multipart“, iar parametrul „charset“ poate fi folosit cu mai multe tipuri).
Până în prezent, doar șapte tipuri de nume, și în timp ce acest lucru este suficient. În plus, este de așteptat ca extinderea setului existent de tipuri de date suportate vor fi cheltuieli de introducere a unor noi sub-tipuri de tipuri de date definite inițial. În viitor, adăugarea de tipuri de nivel superior a numelor se poate face numai cu adoptarea unei noi versiuni a standardului MIME. În cazul în care pentru orice alt motiv, versiunea existentă este utilizat tip neînregistrat conținutului ar putea fi, el trebuie să primească un nume care începe cu „X“, pentru a sublinia statutul non-standard și pentru a preveni conflictul, în prealabil, cu denumirea oficială a unui tip, care pot fi introduse ulterior.
umplerea corectă a câmpului Content-Type:
Aici, un set de caractere speciale, diferite din setul definit în RFC 822 doar de caracterele „/“, „?“, „=“ Și lipsa de „“ Caracter.
Notă subtip în acest domeniu este obligatorie, deoarece Nu există subtipuri implicite. Spre deosebire de denumirile de tip, și subtipuri de parametri, valorile parametrilor sunt în general sensibile la caz, dar poate fi insensibil și - în funcție de un parametru. De exemplu, valorile limită multipart litere sunt sensibile, iar valoarea „tip de acces“ pentru mesajul / extern-corp nu este.
Există două mecanism acceptabil pentru introducerea de noi sub-tipuri pentru câmpul Content-Type:
Șapte tipuri de nivel superior predefinite, mai multe detalii sunt după cum urmează:
Text - informații de text. Baza de subtipul - „plain“ - corespunde textului neformatirovnnomu de obicei și nu are nevoie de un software special pentru a afișa textul cu excepția sprijinului pentru codificări naționale. Alte subtipuri sunt utilizate în cazul textului marcat atunci când utilizați software-ul, vă puteți îmbunătăți vizualzatsiyu, dar pentru o înțelegere a conținutului ideilor pe care le puteți face fără a dpolnitelnogo software-ul. subtipuri posibile pot descrie usor de citit formate de diverse procesoare de text.
multipart - conținutul mesajului este format dintr-o multitudine de porțiuni care conțin date reciproc diferite tipuri. Inițial definite patru subtipuri:
- „Mixt“ - principal;
- „Alternative“ - pentru a reprezenta aceleași date în diferite formate;
- „Paralel“ - în cazul în care diferitele părți ale documentului ar trebui să fie revizuite în același timp;
- „Digest“ - în cazul în care fiecare dintre părți ale corpului mesajului are un tip de „mesaj“.
mesaj - literă cu literă. Un organism care conține tipul de date „mesaj“, este ea însăși o parte dintr-o literă sau litere, complet formatate în conformitate cu standardul RFC 822, care, la rândul său, poate conține propriul său câmp de antet „Content-Type“.
subtipuri:
- "Rfc822" - de bază;
- „Parțială“ - definit pentru scrisorile parțial citate pentru a preveni fragmentarea organismelor conținute literele în cazul prea mult din lungimea totală a capacităților de transport e-mail;
- „Extern-corp“ - este utilizat pentru a indica faptul că corpul mesajului este foarte mare și este dincolo de litera.
imagine - datele de imagine. Grafica necesită dispozitive corespunzătoare de ieșire (afișaj grafic, imprimantă, fax) pentru a afișa informațiile sale. Inițial identificate două subtipuri de cele mai comune formate de imagine - jpeg si gif.
audio - informații audio. Necesită dispozitiv audio (difuzor sau căști) pentru afișarea informațiilor. Principalul sub-tip - „de bază“.
aplicație - de obicei, cod binar neinterpretabil sau informații destinate program de procesare de e-mail.
În mod implicit, literele, ca în standardul RFC 822, scrie pur și simplu text (neetichetată) în limba codificată în US-ASCII, caietul de sarcini MIME care poate fi descris ca "Content-type: text / plain; charset = ne-ascii". Această valoare este asumată, în cazul în care câmpul este de tip de conținut nu este definit. Prin urmare, programul de e-mail a destinatarului poate interpreta greșit conținutul mesajului, în cazul în care trimiterea nu a fost specificat câmpul de conținut de tip, dar, de fapt textul scrisorii are o codificare diferită, sau chiar de tip.
În absența câmpului de conținut de tip sau de câmp MIME-Version nu poate fi exact sigur de antet MIME-scris, că scrisul este de codificare limbă este US-ASCII, deoarece acestea pot întâlni în continuare corespondență internă care nu utilizează acorduri MIME. Dar, deși este posibil ca scrisoarea nu conține în antetul câmpurile MIME-Version și Content-Type, poate conține orice doriți, de exemplu, de Unix tar-arhivă, comprimat cu gzip si a terminat UUEncode, dar creatorii recomandat să lăsați programe de e-mail acest fapt fără o atenție și să se concentreze pe valoarea implicită, adică "Text / plain; charset = ne-ascii".
Trebuie să se înțeleagă faptul că creșterea preconizată a numărului de tipuri și subtipuri notabile înregistrate, în special conținutul scrisorilor în viitor. În cazul în care plicului se va întâlni valoarea necunoscută a câmpului de conținut de tip, acesta trebuie să interpreteze conținutul scrisorii ca „application / octet-stream“.