Поле заголовка content-type

Поле заголовка 'Content-Type'

Призначення цього поля - найбільш повний опис даних, що містяться в тілі, з тим, щоб поштовий агент (програма) одержувача могла вибрати відповідний механізм для їх обаботкі. Вперше це поле було визначено в RFC 1049, але мало більш простий синтаксис.

Хоча багато параметрів (модифікатори підтипів) мають сенс лише для конкретного типу, деякі все ж є глобальними в тому сенсі. що вони можуть бути застосовані до всіх типів (наприклад, параметр "boundary" застосовується лише до типу "multipart", а параметр "charset" може використовуватися з декількома типами).

Поки імен типів тільки сім, і поки цього достатньо. Крім того, передбачається, що розширення існуючого набору підтримуваних типів даних буде проводитися зарахунок введення нових підтипів цих спочатку певних типів даних. В майбутньому додавання імен типів верхнього рівня може бути зроблено тільки після ухвалення нової версії стандарту MIME. Якщо з якої-небудь іншої причини в існуючій версії використовується Незареєстровані тип содежімого, йому повинно бути дано ім'я, яке починається з "X-", щоб підкреслити його нестандартний статус і заздалегідь попередити конфлікт з офіційним ім'ям типу, яке може бути введено пізніше.

Правильне заповнення поля Content-Type:

Тут набір спеціальних символів відрізняється від набору, визначеного в RFC 822 тільки наявністю символів "/", "?", "=" І відсутністю символу ".".

Вказівка ​​підтипу в даному полі є обов'язковим, тому що немає підтипів за замовчуванням. На відміну від імен типів, підтипів і параметрів, значення параметрів в загальному випадку є чутливими до регістру букв, але можуть бути і нечутливими - в залежності від параметра. Наприклад, значення кордонів multipart-листи є чутливими, а значення "access-type" для message / External-body не є.

Існує два прийнятних механізму для введення нових підтипів для поля Content-Type:

Сім визначених типів верхнього рівня, більш детально, є наступними:

text - текстова інформація. Основою підтип - "plain" - відповідає звичайному неформатіровнному тексту і не вимагає спеціального програмного забезпечення для відображення цього тексту за винятком підтримки національних кодувань. Інші підтипи використовуються в разі розміченого тексту, коли за допомогою спеціальної програми можна поліпшити його візуалзацію, але для розуміння ідеї змісту можна обійтися і без дполнітельного ПО. Можливі підтипи можуть описувати легко прочитувані формати різних текстових процесорів.

multipart - вміст листа складається з певної кількості частин, що містять дані різних взаємонезалежних типів. Спочатку визначено чотири підтипи:

  1. "Mixed" - основний;
  2. "Alternative" - ​​для подання одних і тих же даних в різних форматах;
  3. "Parallel" - якщо різні частини документа повинні проглядатися одночасно;
  4. "Digest" - якщо кожна з частин тіла листи має тип "message".

message - лист в листі. Тіло, що містить дані типу "message", саме є листом або частиною листа, повністю відформатованого відповідно до стандарту RFC 822, яке, в свою чергу, може містити своє власне поле заголовка "Content-Type".
підтипи:

  1. "Rfc822" - основний;
  2. "Partial" - визначено для частково-цитованих листів для запобігання фрагментації тел містяться листів в разі занадто великий їх загальної довжини для можливостей поштового транспорту;
  3. "External-body" - використовується, щоб вказати, що тіло листа дуже велике і знаходиться поза листи.

image - графічні дані. Графіка вимагає відповідного пристрою виведення (графічний дисплей, принтер, факс) для відображення своєї інформації. Спочатку визначені два підтипу для найбільш поширених графічних форматів - jpeg і gif.

audio - звукова інформація. Вимагає звуковий пристрій (динамік або навушники) для виведення інформації. Основний підтип - "basic".

application - як правило, неінтерпретіруемий двійкового коду або інформація, призначена для обробки поштової програмою.

За замовчуванням, листи, як і в стандарті RFC 822 пишуться простим (як немарковані) текстом у мовній кодуванні US-ASCII, що по специфікації MIME може бути описано як "Content-type: text / plain; charset = us-ascii". Це значення покладається, якщо поле Content-type не визначене. Тому поштова програма одержувача може невірно витлумачити вміст листа, якщо при відправці не було вказано поле Content-type, але насправді текст листа має іншу систему кодування або навіть тип.

При відсутності поля Content-type або поля MIME-Version в заголовку MIME-листи можна бути точно впевненим, що лист має мовне кодування саме US-ASCII, оскільки можуть ще зустрічатися поштові програми, які не використовують угоди MIME. Але хоча можливо, що лист, що не містить в заголовку полів MIME-Version і Content-Type, може містити все, що завгодно, наприклад, юніксовскій tar-архів, стиснений gzip'ом і оброблений uuencode, все ж, творцям поштових програм рекомендується залишати цей факт без уваги і орієнтуватися на значення за замовчуванням, тобто "Text / plain; charset = us-ascii".

Необхідно врахувати, що в майбутньому очікується помітне збільшення числа реєстрованих типів і особливо підтипів вмісту листів. Якщо поштова програма зустріне невідоме їй значення поля Content-type, вона повинна інтерпретувати вміст цього листа як "application / octet-stream".