Компьютерные сети. 6-е изд. - Эндрю Таненбаум

определял формат заголовков, но оставлял содержимое сообщения полностью на усмотрение пользователей. В 1990-е годы повсеместное распространение интернета и необходимость передавать через почтовую систему более разнообразный контент показали, что такой подход уже не отвечает требованиям. К примеру, нужно было обеспечить передачу сообщений на разных языках: с диакритическими знаками (французском или немецком), с алфавитом, отличным от латинского (иврите или русском), или вовсе без алфавита (китайском или японском). Также требовалась возможность отправки сообщений, не являющихся текстом (например, аудио, изображений или бинарных документов и программ).

Решением стала разработка стандарта многоцелевых расширений интернет-почты (Multipurpose Internet Mail Extensions, MIME). Он широко применяется как для сообщений электронной почты, передаваемых по интернету, так и для описания контента в других случаях, например при просмотре сайтов. Изначально MIME описан в RFC 2045, а последующие его версии — в RFC 4288 и 4289.

Основная идея стандарта MIME сводилась к тому, чтобы продолжить использование формата RFC 822, но при этом придать структуру телу сообщения и определить правила кодирования для пересылки сообщений без ASCII-символов. Не отклоняясь от стандарта RFC 822, MIME-сообщения могут передаваться с помощью обычных агентов передачи сообщений и протоколов (ранее основанных на RFC 821, а сейчас на RFC 5321). Все, что нужно было изменить, — отправляющие и принимающие программы; это пользователи могли сделать самостоятельно.

MIME задает пять новых заголовков сообщений (илл. 7.14). Первый заголовок (MIME-Version:) просто информирует пользовательского агента, что он имеет дело с сообщением MIME, и указывает номер версии MIME. Если в сообщении нет такого заголовка, то оно считается написанным на английском языке (или по крайней мере использующим только ASCII-символы) и обрабатывается соответственно.

Поле

Значение

MIME-Version:

Указывает версию MIME

Content-Description:

Строка обычного текста, описывающая содержимое сообщения

Content-Id:

Уникальный идентификатор

Content-Transfer-Encoding:

Указывает способ кодировки тела сообщения для его передачи

Content-Type:

Тип и формат содержимого сообщения

Илл. 7.14. Заголовки сообщений, добавленные в стандарте 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 символов в строке. К этой категории относятся исполняемые программные файлы. Сегодня почтовые серверы могут проверять, есть ли возможность переслать данные в бинарной (или 8-битной) кодировке, и если это расширение не поддерживается на обеих сторонах, данные будут передаваться в ASCII.

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

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

Изначально в RFC 1521 были определены семь MIME-типов. У каждого из них есть один или несколько доступных подтипов. Подтип отделяется от типа косой чертой, например: Content-Type: video/mpeg. Впоследствии было добавлено более 2700 подтипов, а также два новых типа (font и model). Новые сущности добавляются постоянно, по мере появления новых типов контента.

Список утвержденных типов и подтипов поддерживается организацией IANA и расположен по адресу www.iana.org/assignments/media-types. Существующие типы, а также несколько примеров часто используемых подтипов показаны на илл. 7.15.

Тип

Примеры подтипов

Описание

text

plain, html, xml, css

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

image

gif, jpeg, tiff

Изображения

audio

basic, mpeg, mp4

Звуки

video

mpeg, mp4, quicktime

Видеофильмы

font

otf, ttf

Шрифты для форматирования текста

model

vrml

3D-модель

application

onoctet-stream, pdf, javascript, zip

Данные, производимые приложениями

message

http, rfc822

Инкапсулированное сообщение

multipart

mixed, alternative, parallel, digest

Комбинация нескольких типов

Илл. 7.15. Типы содержания MIME и примеры подтипов

Назначение MIME-типов на илл. 7.15 вполне очевидно, за исключением, возможно, последнего. Тип multipart служит для передачи сообщений с несколькими вложениями разного MIME-типа.

7.2.4. Пересылка сообщений

Теперь, когда мы описали пользовательские агенты и