Таблица 7.5. Заголовки сообщений, добавленные MIME

Заголовок Content-Description: представляет собой ASCII-строку, информирующую о том, что находится в сообщении. Этот заголовок позволяет пользователю принять решение о том, нужно ли ему декодировать и читать сообщение. Если в строке сказано: «Фотография тушканчика Барбары», а получивший это сообщение не является любителем тушканчиков, то, вероятнее всего, он сразу удалит это сообщение, а не станет перекодировать его в цветную фотографию высокого разрешения.

Заголовок Content-Id: содержит идентификатор содержимого сообщения. В нем используется тот же формат, что и в стандартном заголовке Message-Id:.

Заголовок Content-Transfer-Encoding: сообщает о способе упаковки тела сообщения для его передачи по сети. Во времена разработки MIME основной проблемой были протоколы передачи сообщений (SMTP), предполагавшие, что сообщение будет в формате ASCII, при этом в строке должно было быть не более 1000 символов. Символы ASCII используют 7 бит из каждого восьмибитного байта. Бинарные данные, такие как исполняемые программы и изображения, используют все 8 бит байта, так же как и расширенные наборы символов. Не было никакой гарантии того, что эти данные будут передаваться безопасно. В результате этого потребовался метод передачи бинарных данных, который заставлял бы их выглядеть как обычное почтовое сообщение ASCII. Расширения SMTP, введенные с момента разработки MIME, на самом деле позволяют передавать восьмибитные бинарные данные, хотя даже сегодня незакодированные бинарные данные не всегда корректно передаются почтовой системой.

MIME обеспечивает пять схем кодирования, предназначенных для передачи данных (кроме того, имеется возможность добавления новых схем; на всякий случай). Простейшая из них заключается в передаче просто текстовых сообщений ASCII. Символы ASCII используют 7 разрядов и могут передаваться напрямую протоколом электронной почты, при условии, что строка не превышает 1000 символов.

Следующая по простоте схема аналогична предыдущей, но использует 8-разрядные символы, то есть все значения байта от 0 до 255 включительно. Сообщения, использующие 8-разрядную кодировку, также должны соблюдать правило о максимальной длине строки.

Еще хуже обстоит дело с сообщениями в настоящей двоичной кодировке. К ним относятся произвольные двоичные файлы, которые не только используют все 8 разрядов в байте, но еще и не соблюдают ограничение на 1000 символов в строке. К этой категории относятся исполняемые программные файлы. Сегодня почтовые серверы могут проверять, есть ли возможность переслать данные в бинарной (или восьмибитной) кодировке, и если на обоих концах не поддерживается данное расширение, данные будут передаваться в ASCII.

Кодировка бинарных данных в формате ASCII называется base64 (64-символьная кодировка). При использовании данного метода группы по 24 бита разбиваются на четыре единицы по 6 бит, каждая из которых посылается в виде обычного разрешенного ASCII-символа. В этой кодировке 6-разрядный символ 0 кодируется ASCII-символом «A», 1 — ASCII-символом «В» и т. д. Затем следуют 26 строчных букв, затем 10 цифр и, наконец, + и / для кодирования 62 и 63 соответственно. Последовательности == и = говорят о том, что последняя группа содержит только 8 или 16 бит соответственно. Символы перевода строки и возврата каретки игнорируются, поэтому их можно вставлять в любом месте закодированного потока символов для того, чтобы строки

выглядели не слишком длинными. Таким способом можно передать любой двоичный код, хотя и достаточно не эффективно. Эта кодировка была крайне популярна до того, как приобрели широкое распространение почтовые серверы, способные передавать бинарную информацию.

Для сообщений, почти полностью состоящих из символов ASCII, но с небольшими включениями не-ASCП-символов, подобный метод несколько неэффективен. Вместо него лучше применять кодировку quoted-printable (цитируемое печатное кодирование). Это просто 7-битный ASCII, в котором символы, соответствующие значениям ASCII-кода свыше 127, кодируются знаком равенства, за которым следуют две шестнадцатеричных цифры — ASCII-код символа. Кроме конечных пробелов кодируются также символы управления, некоторые пунктуационные знаки и математические символы.

Наконец, когда имеются веские причины не использовать эти методы, можно указать в заголовке Content-Transfer-Encoding: свою кодировку.

Последний заголовок в табл. 7.5 представляет наибольший интерес. Он указывает тип тела сообщения и его применение выходит далеко за пределы электронной почты. Например, контент, загружаемый из Интернета, помечается символами MIME, что позволяет браузеру адекватно отображать информацию. Так обстоит дело с контентом, пересылаемым через потоковое мультимедиа, и передачей в реальном времени, например голоса через IP (VoIP).

Изначально в документе RFC 1521 были определены семь типов содержимого сообщений, каждый из которых распадается на несколько доступных подтипов. Подтип отделяется от типа косой чертой, например «Content-Type: video/mpeg». С тех пор к ним было добавлено много новых типов и подтипов. Этот список пополняется всякий раз при возникновении соответствующей необходимости. В сети его поддерживает IANA, он доступен по адресу www.iana.org/assignments/media-types.

Типы и примеры часто используемых подтипов приведены в табл. 7.6. Давайте кратко остановимся на каждом из них, начиная с типа text. Комбинация text/plain служит для обозначения обычного текстового сообщения, которое может быть отображено на экране компьютера сразу после получения. Для этого не требуется дополнительной обработки или перекодировки. Это значение поля заголовка позволяет передавать обычные сообщения в MIME с добавлением небольшого количества дополнительных заголовков. Когда веб-технологии стали популярны, был добавлен новый тип text/html (в RFC 2854), который позволил пересылать веб-страницы в теле письма RFC 822. В RFC 3023 определен подтип для расширяемого языка разметки (extensible Markup Language — XML), text/xml. С развитием Интернета количество документов XML стремительно увеличилось. Ниже, в разделе 7.3, мы рассмотрим HTML и XML.

Следующим типом MIME является image. Он используется для передачи неподвижных изображений. На сегодняшний день существует множество различных форматов хранения и передачи изображений, как с использованием сжатия, так и без него. Некоторые форматы, в том числе GIF, JPEG и TIFF, встроены практически во все браузеры, однако существует еще множество других типов и соответствующих им подтипов.

Типы audio и video предназначены, соответственно, для передачи звука и двигающегося изображения. Обратите внимание на то, что подтип video включает только визуальную информацию, а не звуковую дорожку. Если необходимо передать по электронной почте видеофильм со звуком, то, возможно, придется посылать видеоряд и звуковую дорожку отдельно друг от друга. Это зависит от системы кодирования. Первым видеоформатом, который был определен стандартом MIME, стал формат со скромным названием MPEG (Motion Pictures Experts Group — экспертная группа по вопросам движущегося изображения). С тех пор было добавлено еще несколько форматов. Так, чтобы позволить пользователям пересылать по электронной почте аудиофайлы в формате MP3, в RFC 3003 помимо уже существующего audio/basic был добавлен тип audio/mpeg. Типы video/mp4 и audio/mp4 указывают на видео- и аудиоданные в новом формате MPEG 4.

Таблица 7.6. Типы стандарта MIME и примеры подтипов

Тип

Подтип

Описание

text

plain, html, xml, css

Текст в различных форматах

image

gif, jpeg, tiff

Изображения

audio

basic, mpeg, mp4