MIME-расширение для кодировки, отличной от ASCII

Если приведенные выше заголовки подходят для сообщений, содержащих текст в кодировке ASCII, то их содержимого недостаточно для сообщений с аудио-, видео- и прочей информацией, формат которой не соответствует ASCII. Это требует включения в сообщение специальных заголовков, а следовательно, расширения стандарта RFC 822. Такое расширение описано в документах RFC 2045 и 2046 и носит название многоцелевых расширений почты Интернета (Multipurpose Internet Mail Extensions, MIME).

Двумя наиболее важными MIME-заголовками, предназначенными для поддержки мультимедиа, являются Content-Type: и Content-Transfer-Encoding:. Заголовок Content-Type: позволяет агенту получателя произвести соответствующую обработку данных сообщения. Так, например, если сообщение содержит изображение в формате JPEG, агент получателя вызовет процедуру декомпрессии файлов JPEG. Для того чтобы понять смысл второго заголовка, Content-Transfer-Encoding:, вспомните о том, что все данные в кодировке, отличной от ASCII, перед передачей по протоколу SMTP должны быть преобразованы в кодировку ASCII. Заголовок Content-Transfer-Encoding: указывает адресату на то, что было произведено преобразование (кодирование) исходной кодировки символов в кодировку ASCII, а также на тип этого кодирования. Таким образом, агент получателя, распознав заголовок Content-Transfer-Encoding:, сможет произвести декодирование сообщения для приведения данных в исходную кодировку, а затем, распознав заголовок Transfer-Encoding:, обработать декодированные данные.

Рассмотрим конкретный пример. Пусть Алиса хочет переслать Бобу электронное письмо, содержащее JPEG-изображение. Для этого она вызывает свой агент, вводит адрес почтового ящика Боба, указывает тему сообщения и вставляет изображение в тело сообщения (в зависимости от используемого агента вставка файла может называться «присоединением»). После команды отправки агент генерирует MIME-сообщение, выглядящее приблизительно так:

From: alice@crepes.fr
То: bob@hamburger.edu
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-Transfer-Encoding: base64 заголовка и декодирует тело сообщения методом base64. Затем агент увидит строку Content-Type: image/jpeg и произведет JPEG-декомпрес-сию полученных данных. Строка MIME-Version: 1.0, как нетрудно догадаться, идентифицирует номер версии MIME. При отсутствии этой строки сообщение будет обработано как стандартное, соответствующее формату RFC 822/SMTP. Как правило, заголовок сообщения отделяется от тела пустой строкой.

Рассмотрим немного подробнее строку 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: alice@crepes.fr
То: bob@hamburger.edu
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: заголовка указывает на последовательность символов, применяющуюся для разделения разнородных частей сообщения. Разделяющая последовательность всегда начинается с символов