MIME-розширення для кодування, відмінною від ASCII
From: [email protected]
Те: [email protected]
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image / jpeg
(Base64 encoded data ... ..
.... base64 encoded data)
З наведеного повідомлення можна дізнатися про те, що агент користувача Аліси кодував JPEG-зображення методом base64. Цей метод стандартизований документом RFC 2045 як спосіб перетворення в 7-розрядну кодування ASCII.
Іншим часто використовуваним методом кодування є перетворення 8-розрядних даних в кодуванні ASCII (зазвичай символів національних алфавітів) в 7-розрядні.
Розглянемо трохи докладніше рядок Content-Type: заголовка. Згідно зі специфікацією MIME, зазначеної в RFC 2046, формат рядка має наступний вигляд:
Content-Type: type / subtype; parameters
Тут parameters - це необов'язкові параметри. Згідно зі специфікацією, рядок Content-Type: використовується для вказівки типу даних, що передаються в повідомленні, і складається з імен типу і підтипу. Крім того, в рядку можуть бути присутніми параметри, призначені для уточненої інформації про підтип і не роблять значного впливу на інтерпретацію даних. Зрозуміло, для кожного підтипу визначається власний набір параметрів. Розробка MIME велася з розрахунком на майбутню розширюваність, і не виключено, що скоро число можливих пар типів і підтипів значно зросте. Для того щоб якось упорядкувати розробку нових типів і підтипів, MIME передбачає необхідність реєстрації в IANA (Internet Assigned Numbers Authority - уповноважена організація за призначенням номерів Інтернету). Реєстраційний процес описаний в документі RFC 2048.
В даний час виділено сім основних типів даних. Для кожного типу даних існує ряд підтипів, число яких з кожним роком стрімко зростає. Нижче наведені описи трьох з семи типів.
□ text. Цей тип вказує агенту одержувача на те, що тіло повідомлення містить текстову інформацію. Дуже часто зустрічається парою тип / підтип є text / plain. Підтип plain означає простий текст, тобто текст не містить команд або директив форматування. Такий текст повинен бути відображений «як є»; ніякого спеціального програмного забезпечення для цього не потрібно. Єдиною умовою коректності відображення тексту є підтримка використовуваного кодування символів. Якщо ви поглянете на MIME-заголовки повідомлень, що зберігаються у вашій поштовій скриньці, то майже напевно знайдете рядки такого змісту: text / plain; charset = "IS0-8859-l». Параметри вказують на назву таблиці символів, що використовувалася при створенні тексту. Інший часто зустрічається парою є text / html. Підтип html вказує на те, що програма читання пошти повинна інтерпретувати теги, включені в повідомлення. Це дозволяє відобразити повідомлення у вигляді web-сторінки, що містить різні шрифти, гіперпосилання, аплети і т. Д.
□ image. Цей тип вказує на те, що інформація, яка перебуває в тексті листа, є зображенням. Двома найбільш поширеними парами тип / підтип для зображень є image / gif і image / jpeg. Розпізнаючи кожен з цих підтипів, агент користувача застосовує відповідний метод декомпресії зображення.
□ application. Це тип для всіх даних, які не можна віднести до інших шести типів. Як правило, сюди потрапляють дані, призначені для обробки різними прикладними програмами. Так, наприклад, якщо включити в повідомлення документ Microsoft Word, агент відправника присвоїть йому пару ар-plication / msword. При обробці повідомлення агент одержувача викличе додаток Microsoft Word і передасть йому декодувати дані.
Існує ще один досить важливий MIME-тип, який заслуговує на окремий розгляд і називається multipart. Подібно до того як web-сторінка може включати в себе різні типи даних (текст, зображення, аплети і т. Д.), Тіло повідомлення також може складатися з різних видів інформації. Згадайте про те, що протокол HTTP посилає кожен об'єкт в окремому відповідному повідомленні; послідовність дій у відповідь повідомлень може передаватися через одне або кілька TCP-з'єднань в залежності від типу з'єднання (постійного або непостійного). Протокол SMTP, навпаки, поміщає всі об'єкти (складові частини) в тіло одного повідомлення. У випадках, коли повідомлення містить більше одного об'єкта (наприклад, кілька зображень, текст і зображення і т. П.), Йому присвоюється пара тип / підтип multipart / mixed. Для обробки тіла такого повідомлення агенту користувача необхідна інформація про те, де знаходиться початок і закінчення кожного з об'єктів, якими способами закодовані об'єкти і які типи і підтипи даних, що містяться в об'єктах. Структура складеного повідомлення включає спеціальні розділові символи, що вставляються між об'єктами, і заголовки Content-Type: і Content-Transfer-Encoding: перед початком даних кожного з об'єктів.
Для того щоб краще зрозуміти принцип організації складеного повідомлення, розглянемо наступний приклад. Нехай Аліса має намір послати Бобу лист, що містить два фрагмента ASCII-тексту, а також JPEG-зображення, що знаходиться між цими фрагментами. За допомогою свого агента Аліса вводить перший текстовий фрагмент, потім приєднує зображення і вводить другий текстовий фрагмент. Після команди відправки агент генерує повідомлення приблизно такого змісту:
From: [email protected]
Те: [email protected]
Subject: Picture of yummy crepe with commentary
MIME-Version: 1.0
Content-Type: multipart / mixed; Boundary = StartOfNextPart
-StartOfNextPart
Dear Bob.
Please find a picture of an absolutely scrumptious crepe.
-StartOfNextPart
Content-Transfer-Encoding: base64
Content-Type: image / jpeg
base64 encoded data ... ..
.... base64 encoded data
-StartOfNextPart
Let me know if you would like the recipe.
Як можна бачити, перший рядок Content-Type: заголовка вказує на послідовність символів, що застосовується для поділу різнорідних частин повідомлення. Розділяє послідовність завжди починається з символів
Відповідальність, за все зміни, внесені в систему за порадами даної статті, Ви берете на себе.