<<
>>

MIME — многоцелевые расширения электронной почты в сети Интернет

На заре существования сети ARPANET электронная почта состояла исключительно из текстовых сообщений, написанных на английском языке и представленных символами ASCII. Для подобного применения стандарта RFC 822 было вполне достаточно: он определял формат заголовков, но оставлял содержимое сообщения полностью на усмотрение пользователей.
На сегодняшний день такой подход уже не удовлетворяет пользователей, привыкших к Интернету. Требуется обеспечить возможность оправления сообщений со следующими характеристиками.

1. Сообщения на языках с надстрочными знаками (например, на французском,

немецком, испанском и т. д.).

2. Сообщения на языках, использующих алфавиты, отличные от латинского (например, на иврите или русском).

3. Сообщения на языках без алфавитов (например, китайском, японском, корейском).

4. Сообщения, вообще не являющиеся текстом (например, аудио или видео). Решение было предложено в документе RFC 1341, а более новая редакция

была опубликована в RFC 2045-2049. Это решение, получившее название MIME (Multipurpose Internet Mail Extensions, — многоцелевые расширения электронной почты в Интернете), широко применяется в настоящий момент.

Далее приведено его описание. Дополнительную информацию о наборе стандартов MIME см. в RFC.

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

Стандартами MIME определяются пять новых заголовков сообщения, приведенных в табл. 7.6. Первый заголовок просто информирует пользовательского агента, получающего сообщение, что тот имеет дело с сообщением MIME, а также сообщает ему номер версии MIME, используемой в этом сообщении.

Если сообщение не содержит такого заголовка, то оно считается написанным на английском языке и обрабатывается соответствующим образом.

Таблица 7.6. Заголовки RFC 822, добавленные MIME

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

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

Заголовок Content-Transfer-Encoding сообщает о способе упаковки тела сообщения для его передачи по сети, которая может возражать против символов, отличных от букв, цифр и знаков препинания. Разработано пять схем (имеется

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

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

Еще хуже обстоит дело с сообщениями в двоичной кодировке.

К ним относятся произвольные двоичные файлы, которые не только используют все 8 разрядов в байте, но еще и не соблюдают ограничение на 1000 символов в строке. К этой категории относятся исполняемые программные файлы. Не дается никакой гарантии, что эти двоичные сообщения будут доставлены корректно, но, тем не менее, очень многие пользователи все равно пересылают их друг другу.

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

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

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

Последний заголовок в табл. 7.6 представляет наибольший интерес. Он указывает тип тела сообщения. В документе RFC 2045 определены семь типов содержимого сообщений, каждый из которых распадается на несколько подтипов.

Подтип отделяется от типа косой чертой, например,

Content-Type: video/mpeg

Подтип должен быть явно указан в заголовке; подтипов по умолчанию нет. Начальный список типов и подтипов, определенный в документе 11ЕС 2045, приведен в табл. 7.7. С тех пор к ним было добавлено много новых типов и подтипов. Этот список пополняется всякий раз при возникновении соответствующей необходимости.

Таблица 7.7. Типы стандарта MIME и подтипы, определенные в RFC 2045

Рассмотрим перечисленные в таблице типы сообщений. Тип text означает обычный текст. Комбинация text/plain служит для обозначения обычного текстового сообщения, которое может быть отображено на экране компьютера сразу после получения. Для этого не требуется дополнительной обработки или перекодировки. Это значение поля заголовка позволяет передавать обычные сообщения в MIME с добавлением небольшого количества дополнительных заголовков.

Подтип text/enriched позволяет включать в текст простой язык разметки документа. Этот язык обеспечивает системно-независимый способ выделять участки текста жирным или наклонным стилями, использовать шрифты самых разных размеров и цветов, отступы, выравнивание, верхние и нижние индексы и формировать простой макет страницы. В основе этого языка разметки лежит язык SGML (Standard Generalized Markup Language — стандартный обобщенный язык разметки), на базе которого был также создан язык HTML (HyperText Markup Language), применяемый в WWW. Например, сообщение

Момент настал, - сказал моряк

<< | >>
Источник: Э. ТАНЕНБАУМ. КОМПЬЮТЕРНЫЕ СЕТИ 4-Е ИЗДАНИЕ. 2003

Еще по теме MIME — многоцелевые расширения электронной почты в сети Интернет:

  1. 2. Расширение сети вольной русской прессы в 1860-е годы
  2. 4. Договоры перевозки пассажира, багажа и почты
  3. Статья 924. Ответственность перевозчика за потерю, недостаток, порча или повреждение груза, багажа, почты
  4. Статья 919. Срок доставки груза, пассажира, багажа, почты
  5. В .А. Галкин, Ю .А. Григорьев. Телекоммуникации и сети, 2003
  6. Социальные сети
  7. § 3. Интервью в глобальной сети
  8. 3. Новости по почте. Электронной
  9. 3.5. Подключение к сети
  10. 4. Электронные газеты
  11. ВАРИКОЗНОЕ РАСШИРЕНИЕ ВЕН