Электронная почтаИзначальный стандарт на электронное сообщение (RFC822, 1991 г.) разрешал исключительно 7-битные символы в сообщении, т.е. кодировку ASCII (American Standard Code for Information Interchange). Через некоторое время появился и устоялся стандарт MIME (Multipurpose Internet Mail Extensions, RFC1341, 1992 г., затем RFC1521, 1993 г., последняя редакция - RFC2045 - RFC2049, 1996 г.), определяющий способы передачи через Интернет любых сообщений. И хотя терминология там отнюдь не самоочевидна (английские выражения "character set" и "encoding" сами по себе не менее многозначны и не более конкретны, чем русское "кодировка"), сами сущности формализованы довольно четко и дают хорошую основу для конкретных обсуждений, не связанных даже с MIME непосредственно. В соответствии с этим мы различаем, что мы передаем в электронном письме - какого типа его содержание, и как мы это передаем - как это содержание кодируется. Что - это, в первую очередь, текст или двоичный файл, еще один вариант - многосекционное сообщение, каждая из секций которого тоже относится к одному из типов. Основное отличие - тексты, в общем и целом, предназначены для чтения человеком, независимо от используемого программного обеспечения, главное здесь - их читаемость. Двоичные файлы предназначены для передачи понимающей их программе или сами являющиеся программой, и главное здесь - передать их в неизменном виде. Разумеется, могут быть пограничные случаи, различие типов не абсолютное, но тем не менее классическая телеграмма "Шлите апельсины бочками. Братья Карамазовы" является чистым примером чистого текста, а исполняемый модуль программы, зараженный вирусом, - чистым примером передачи двоичного файла. И если двоичный файл самодостаточен, то текст, превращенный в последовательность байтов, неотделим от своей кодовой таблицы, или (языковой) кодировки. Как - способ дополнительно закодировать превращенное в последовательность байтов содержание, чтобы его можно было передать по электронной сети, что может быть необходимо даже для текста и практически всегда необходимо для двоичных файлов, которые вполне могут содержать не только символы, не входящие в ASCII, но и управляющие коды (от 0 до 31), типа "возврата каретки" или "перевода строки". Этот способ тоже может быть назван кодировкой, но, в отличие от предыдущего абзаца, - транспортной кодировкой. Существует несколько кодировок кириллицы, всеми пользуются. Internet - это то место, где вопрос, какую кодировку применять, перестает быть личным делом каждого. Если вы отправляете кому-то сообщение, то затем, вероятно, чтобы его прочитали. Если ваш получатель работает в DOS, а вы в Windows, то простая пересылка текста вам вряд ли поможет. Даже если письмо, отправленное в Альтернативной кодировке из DOS, дойдет до адресата в неискаженном виде, получателю придется: Проще говоря, для того, чтобы обмениваться почтой по-русски, надо что-то наладить. Об этом мы и поговорим. А если не налаживать Для тех, кто не хочет ничего налаживать, есть готовые решения.Например для DOS - пакет под названием UUPC. Вам придется его установить и пользоваться только им и только в DOS и только в сочетании с модемом. Зато он будет конвертировать отправляемую корреспонденцию в кодировку КОИ-8,а приходящую - в Альтернативную. Вам об этом думать не надо. Существует несколько способов обработать передаваемую по Сети электронную почту (аналогичные рассуждения применимы и к новостям, поэтому мы больше небудем их упоминать). Эти способы естественным образом вытекают из того,как организована передача почты. Посмотрите на схему. user agent - delivery agent - (delivery agent) - delivery agent - user agent Пользователь взаимодействует с почтовой программой (user agent), которая позволяет ему вводить и читать письма, организовывать хранение пришедших писем, вести адресные книги и так далее. Можно сказать, что основная функция user agent - предоставить удобный пользовательский интерфейс.Чтобы доставить или получить письмо user agent обращается к ДОСТАВЩИКУ (delivery agent), который пользовательского интерфейса не имеет, зато владеет тонкостями маршрутизации корреспонденции. ДОСТАВЩИК напрямую или через промежуточные машины передает письмо другому ДОСТАВЩИКУ, который обслуживает адресата. Тот кладет письмо в персональный почтовый ящик, откуда его забирает user agent (почтовая программа) получателя.Это схема общая, в реальной жизни пользовательская почтовая программа можетвключать в себя часть функций ДОСТАВЩИКА. Итак, где-то надо перекодировать письма. Уходящие - в КОИ-8, приходящие -в ту кодировку, которую предпочитает пользователь. Исходя из нашей схемы,это может сделать: Вообще-то в идеале надо приводить почту к стандартному виду как можнораньше, еще перед отправкой. В этом случае мы не рискуем нарваться нана ошибку или сбой при доставке, связанную с неправильной кодировкой письма. Однако здесь есть сложности. Как вы, наверное, заметили, модульность приведенной выше схемы предоставляет нам свободу выбора почтовой программы. Таких программ достаточно много.Их десятки для UNIX и сотни для Windows. Один этот факт должен нас насторожить, если мы собираемся выработать сколько-нибудь общее решение. Ведь все это изобилие создано другими людьми, в большинстве своем американцами, которые не подозревали о нашей с вами потребности почту перекодировать. И никак не приспособили свои программы к такой перекодировке. В спецификации MIME описывается, как в заголовке сообщения передать информацию о кодировке самого сообщения (его тела). Для этого используются три строчки заголовка примерно следующего вида: MIME-Version: 1.0
Здесь Content-Type описывает, что передается - text/plain (чистый текст, для письма в HTML будет стоять text/html), определено также несколько мультимедийных типов, charset (от character set) - указатель на языковую кодировку, а "KOI8-R" - стандартизованное обозначение кодировки. В RFC2046 приводятся обозначения кодировок US-ASCII и наборы ISO-8859-1 - ISO-8859-9. Другие обозначения кодировок и новые типы должны быть зарегистрированы в IANA (Internet Assigned Number Autority). Content-Transfer-Encoding содержит обозначение транспортной кодировки:
В многосекционных сообщениях (например, с приложенными файлами - attachments) тип сообщения обозначается примерно таким образом:
Каждая из секций сообщения (разделенных строчками boundary) содержит при этом свои строчки с Content-Type и Content-Transfer-Encoding. Описанная схема, стандартизуя способы передачи национальных символов и двоичных файлов в теле письма, не затрагивает их заголовков, где тоже могут быть национальные символы - в поле Subject (тема) или в полях From, To (в пояснениях к адресам). Эта проблема решается в RFC2047, где требуется кодировать 8-битные заголовки и вставлять в них "микрообозначения" кодировки - "Q" для Quoted-Printable и "B" для Base64 примерно следующим образом:
Нельзя не отметить, что и тот, и другой вариант выглядят равно нечитаемыми, и что вообще требования MIME к передаче национальных - в частности русских - символов в электронных сообщениях не очень сочетаются с идеей "чтобы все было попросту и читалось глазами". И последнее замечание "для полноты": о применении HTML в почте. Этот формат оказывается более сложным за счет возможности включения в сообщение картинок и других ссылочных объектов, что укладывается в многосекционную схему MIME, но способы организации ссылок внутри одного сообщения в MIME не конкретизируются. На этот счет существует сравнительно новый RFC2110 "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)" (март 1997 г.) и ряд других уточняющих документов (RFC2387, RFC2392), но все это уже выходит за пределы темы почтовых кодировок, в которую HTML никакой новизны не вносит. Также особняком, но по-другому, стоит еще одна, причем 7-битная, русская кодировка - транслитерация, или латиница, когда русские буквы передаются похожими по звучанию английскими primerno takim obrazom (в релкомовской терминологии почему-то используется обозначение "волапюк" - по названию одного из проектов искусственного языка конца XIX века). |
