На заре Интернета все пользователи сети говорили по-английски, и вся электронная почта также была на английском языке. Для того чтобы текст отображался на мониторе, каждому символу должен соответствовать числовой код. Основным набором кодов был и остается ASCII, коды которого были рассчитаны на дешевые и надежные телетайпы, которые раньше повсеместно использовались для ввода и вывода текста и обменом информацией между компьютерами. ASCII — семибитный набор символов, каждому из которых соответствуют числа от 0 до 127, он включает в себя заглавные и строчные буквы и знаки пунктуации, употребляемые на письме в английском языке. Также в ASCII есть некоторые редкие символы, такие как «собачка», которую стали использовать для написания адресов электронной почты, потому что этот знак есть в ASCII, но он практически нигде не употребляется.
Однако почти каждый письменный язык нуждается в символах, не входящих в ASCII. Сегодня пользователи Интернета живут в каждой стране мира и пишут на бесчисленном множестве языков, и электронная почта, хотя и медленно, но все же делает шаги вперед.
Почта MIME
Первым из основных расширений почты был MIME (Multipurpose Internet Mail Extensions, 1992 г.). Раньше почтовое сообщение представляло собой неструктурированный блок текста ASCII. С MIME сообщение стало группой структурированных блоков данных, часть которых могла быть текстом, а другая часть — изображением, документами, или любым другим видом данных, которые могли бы храниться в файле. Благодаря MIME стало возможным кодировать данные, которые не являются семибитовым ASCII, так, если вы прикрепляете изображение или другой файл к своему письму, вы используете MIME.
MIME также дает возможность указывать параметры для заголовков MIME, описывающих каждый блок данных, такие как тип данных (например, изображение JPEG или документ PDF), и (для текстовых блоков) набор символов, которым закодирован текст, например:
Content-type: text/plain; charset=us-ascii
Content-type: text/plain; charset=UTF-8
Набор символов по умолчанию оставался ASCII (сейчас он называется US-ASCII, так как это американский стандарт), но вы могли использовать и некоторые другие.
MIME также позволяет указать набор символов для многих заголовков в письме (Subject:line). Эти же наборы символов и кодировки используются в теле сообщения. Например, этот заголовок закодирован в UTF-8 (см. ниже), и содержит символ, которому соответствует код C2 B0 в шестнадцатиричной системе исчисления. Этот символ — строчная буква «o».
Subject: =? utf-8? Q? Your_reservation_N=C2=B0_F39-04XS? =
Кодирование MIME может применяться в большинстве заголовков сообщений, но не в адресах электронной почты, которые все еще должны кодироваться в ASCII.
Наборы символов, Unicode, и UTF-8
Так как ASCII — семибитный код, а большинство компьютеров имеет восьмибитную память, очевидным способом добавить в ASCII больше символов стало его расширение до восьми битов и прикрепление неанглийских символов к значениям от 128 до 255. Сегодня существует множество восьмибитовых расширений для ASCII. Международная организация по стандартизации (ISO) стандартизировала более десятка из них, от ISO-8859-1 до ISO-8859-15. Существуют и иные кодировки, утвержденные Microsoft, IBM, и другими. Преимущество восьмибитных кодировок ASCII — в их компактности, но вскоре с ними стало неудобно обращаться и из-за множества несовместимых кодировок, потому что нередко было трудно определить, какое расширение ASCII используется в файле. И, конечно, ни один восьмибитный набор знаков не подходит для китайского и других неалфавитных видов письма.
В конце 1980-ых, был создан проект Unicode, цель которого — создать один гигантский набор знаков, включающий в себя каждый символ, который когда-либо использовался. Проект был успешным благодаря поддержке всей индустрии. Изначальный план состоял в том, чтобы использовать 16-битную систему, время шло, в список добавлялись новые языки и символы, и их количество превысило 100 000. Таким образом символы Unicode стали кодироваться 32-битными последовательностями чисел. Так как все 100 000 знаков поддерживаются далеко не во всех системах, в Unicode есть параметр, поддерживает система тот или иной символ или нет, поэтому невозможна ситуация, при которой в разных контекстах отображались бы разные символы.
Так как компьютеры все еще используют восьмибитные байты, Кен Томпсон изобрел систему кодирования UTF-8, в которой каждый символ Unicode представлен как последовательность 1 или более байтов. Первые 128 символов Unicode — 128 знаков ASCII, и в UTF-8 этим 128 знакам соответствуют сами эти знаки, таким образом, любая последовательность символов ASCII — также является последовательностью UTF-8. Поэтому сейчас не имеет смысла использовать любой расширенный набор символов ASCII, кроме Unicode и UTF-8, кроме как для совместимости со старым программным обеспечением. В MIME-тексте электронной почты, как правило, используется UTF-8.
Нелатинские доменные имена
Разумеется пользователи Интернета хотят использовать символы, не включенные в ASCII, не только в письмах, но и в доменных именах. Хотя внутри системы доменных имен (DNS) используются байты на восемь битов и, теоретически, она могла бы использовать UTF-8 уже сейчас, существует огромное количество программного обеспечения для поддержки DNS, в котором может применяться только ASCII и Unicode (в некоторых случаях, когда один и тот же символ пишется разными способами, например, «е» и "é" под ударением). Сообщество DNS придумало систему punycode, которая кодирует в ASCII большую часть знаков Unicode. Доменное имя в ней имеет вид xn — ххх, где ххх отображение в punycode последовательности UTF-8. В punycode существуют сложные правила кодирования, которые введены для того, чтобы выбрать уникальные отображения для символов, у которых есть несколько вариантов Unicode. Имя, начинающееся с xn — известно как A-Label, соответствующее имя Unicode — U-Label, а вся система известна как IDNA (Internationalized Domain Names in Applications). IDNA поддерживают веб-браузеры, которые трансформируют имена на Unicode в адресной строке в A-Label перед тем, как искать их в Интернете. Сейчас есть много доменных имен на китайском, индийском, арабском видах письма и на кириллице.
Часть адреса электронной почты после собачки является доменным именем, поэтому в ней допустимо использовать A-Label. Но часть адреса электронной почты перед cобачкой, имя почтового ящика, не является доменным именем, и, по многим причинам, не поддается кодированию в punycode или A-Label, хотя имя почтового ящика написано в UTF-8. Поэтому, для того чтобы использовать нелатинские e-mail адреса, мы нуждаемся в расширении системы почты, которое даст возможность кодировать UTF-8 в имени почтового ящика, и других укромных уголках, которые не затрагивает MIME.
Главная проблема
Основное препятствие на пути к нелатинским почтовым адресам — это сами почтовые адреса, как в заголовках «от кого» и «кому», так и непосредственно в сессии SMTP, т.е. при передаче сообщения. Чтобы система почты полностью стала многоязычной, она должна позволять не-ASCII символам появляться в подсказках, сообщениях об ошибках и вообще в любом тексте. Следовательно, придется переделывать почти каждый элемент программного обеспечения в экосистеме электронной почты, MUA (пользовательские программы), программы-агенты, которые рассылают почту из пользовательских программ, MTA, которые передают почту от одного сайта другому, и POP и IMAP-cервера, которые позволяют пользовательским программам принимать поступающую почту. Изменения POP, IMAP и пользовательских программ, которые сделают их независимыми от языка, — относительно понятны, поэтому я сосредоточусь на хитрых моментах: формат почтового сообщения, и процесс доставки SMTP.
Люди давно пытались изобрести способ сделать почтовые адреса независимыми от ASCII и при этом более или менее совместимыми со старой почтой. Работа в этом направлении началась в Китае и Японии, где почта только для ASCII была и остается неудовлетворительной. Сначала применялись простые подходы, такие как разрешение различных восьмибитовых расширенных наборов символов в заголовках почты и адресах. В этих наборах символов, таких как ISO-2022-x используются последовательности контрольных знаков, при помощи которых происходит переключение между разными «страницами» набора символов, то есть, значение каждого отдельного символа зависело от того, что предшествовало ему. Такие кодировки плохо работали по множеству причин: из-за «контрольных символов» значение последовательности знаков зависит от того, какой символ стоит перед ней, что приводило к двусмысленности, тот же самый набор знаков мог быть представлен многими различными способами, также почтовая система могла не принимать эти расширенные наборы символов.
В UTF-8 нет проблемы с переключением, но в ней все же используются символы, которых нет в ASCII, которые не будет работать с почтовой системой. Новый подход состоял в том, чтобы разрешить адреса UTF-8, но закодировать их как ASCII. Для доменных имен это уже сделано с помощью A-Labels и punycode; у каждого не-ASCII-домена есть ASCII-версия, которая начинается с xn-. К сожалению, это не работает с именами почтовых ящиков (часть адреса перед собачкой). С одной стороны, все специальные символы, которые можно было бы использовать, чтобы отметить закодированные имена UTF-8, уже где-нибудь используются, и, следовательно, не могут обозначать что-то еще. Дефисы и плюс используются для обозначения подадресов, восклицательные знаки — для адресов uucp, процент — для маршрутизации от отправителя (source routing), слэш — для адресов, совместимых с X.400, знак равенства — в технологии VERP, и так далее. Даже если бы существовали такие маркирующие знаки, которые никто бы не использовал, имена почтовых ящиков ограничены 64 знаками ASCII, и, если вы закодируете адрес UTF-8 при помощи punycode или чего-то подобного, длина адреса UTF-8 будет ограничена приблизительно 18 знаками, а это довольно мало и не дает возможности полноценно пользоваться подадресами и другими расширениями адреса.
Наиболее успешным стал эксперимент, зарегистрированный в RFC 5335 и 5336. Была добавлена новая функция SMTP под названием UTF8SMTP, при которой адреса электронной почты могут быть почти произвольной последовательностью UTF-8, ограниченной 64 байтами. Доменное имя в адресе должно быть при этом переведено в A-Labels. Сообщения посылаются с применением 8BITMIME, и UTF-8 может использоваться почти везде, где и ASCII. Каждый, у кого есть адрес UTF-8, может также иметь адрес ASCII, и можно отправить почту на любой из них:
To: <utf8mailbox@utf8domain <asciimailbox@asciidomain>>
Посылая почту на сервер UTF8SMTP, клиент посылает почту на адрес UTF-8, при этом сохраняется поддержка адресов ASCII. Если почта должна быть отправлена на сервер, который не может работать с UTF8SMTP, сложный алгоритм даунгрейда переведет любые заголовки с UTF-8 в заголовки с МIME-версией UTF-8, заменит любые адреса UTF-8 в строках «Кому» и «От кого» на строчки с комментраиями, и отправит сообщение по адресу ASCII.
Это было великолепной идеей, но через некоторое время стало ясно, что эта двойная система адресов тоже не работает. Одна из причин — то, что очень трудно одновременно поддерживать UTF-8, и ASCII, таким образом почта UTF-8 будет просачиваться в обычный траффик SMTP, и тогда весь почтовый траффик становился UTF-8. Кроме того, даже при том, что двойные адреса были введены лишь на время перехода, в Интернете не бывает переходных периодов, и японские и китайские пользователи не без основания отказались от системы, которая потребует, чтобы у них всегда был адрес ASCII.
Таким образом рабочая группа EAI (Email Address Internationalization) отбросила большинство проектов и почти закончила создание системы многоязычных почтовых адресов.
Как будет работать многоязычная почта
Сейчас рабочая группа EAI занимается пересмотром RFC. Существующий проект будет упрощен, и он будет представлять собой создание нового многоязычного поток почты с текстом UTF-8 в заголовках почты и адресами UTF-8 в сессиях SMTP. (MIME и функция 8BITMIME ESMTP уже работают с телами сообщений UTF-8). Почтовый сервер объявляет, что он может работать с нелатинским почтовым адресом, объявляя об использовании функции ESMTP, которая в настоящее время имеет неприглядное название UTF8SMTPbis, но позже будет изменено на что-то более простое.
Почтовый клиент, если он видит объявление сервера о способности работать с EAI, может включить параметр «EAI» в команду MAIL FROM во время сессии SMTP, чтобы сообщить серверу, что это сообщение — нелатинское, и затем отправляет сообщение. Любой почтовый сервер, который поддерживает EAI, поддерживает и 8BITMIME, таким образом сообщение может содержать любой текст UTF-8 без специального кодирования. RFC также регламентирует варианты EAI для команд SMTP — EXPN и VRFY, которые принимают и возвращают адреса электронной почты, и некоторые улучшения системных сообщений. Если клиент не использует функцию EAI, сообщение идет по «старой» почте (Legacy Mail). Функцию EAI можно включать или отключать для каждого сообщения, следовательно, каждое сообщение может быть или сообщением EAI или сообщением старой почты.
RFC позволяет использовать UTF-8 везде, где и ASCII, кроме некоторых мест, таких как логин и пароль, дата и время. Фактически создан новый MIME, позволяющий полноценно общаться по электронной почте на любом языке. Уже не нужно изобретать способы адаптировать нелатинские адреса к старой почте.
Как мы видим на диаграмме выше, возникнет новый поток почты EAI, который будет параллелен существующему потоку SMTP. Если в сообщении есть заголовки на UTF-8, или адрес отправителя UTF-8, оно войдет в поток EAI. Если же нет — оно может войти как в поток старой почты, так и в поток EAI.
Сплошная диагональная стрелка обозначает, что сообщение старой почты всегда может переместиться в поток EAI, так как EAI — дополненный вариант прежней почты. Пунктирная стрелка обозначает, что сообщение EAI может иногда входить в поток старой почты, если MTA просматривает сообщение и замечает, что адрес отправителя и все тело сообщения состоят только из символов ASCII.
Клиент не сможет послать сообщение EAI на сервер, который не может работать с EAI, поскольку пока не разработаны стандарты даунгрейда. Этим вопросом сейчас занимаются соответствующие рабочие группы.
Например, MSA (программа, которая принимает почту от почтовых пользовательских программ) может использовать резервный старый почтовый адрес для своих пользователей EAI. Если она заметит отправку сообщения EAI от одного из своих пользователей на старый адрес, она может переписать заголовки сообщения так, чтобы заменить адрес EAI пользователя его старым адресом, и MIME перекодирует текст заголовка UTF-8 в ASCII, и затем отправит сообщение как сообщение старой почты. Такая функция может оказаться довольно нужной, но пока трудно понять, как ее стандартизировать.
Существуют сообщества, в которых все пользователи читают и пишут на языках с нелатинской письменностью, таким образом, может оказаться, что почта всех пользователей поддерживает EAI, и совместимость со старой почтой не имеет значения. Или же старая почта будет использоваться лишь в особых случаях, например, при работе с незнакомой почтовой программой.
Рабочая группа EAI разработала полностью интернационализированную систему почты, которая позволяет пользователям отправлять сообщения на своем родном языке, зашифрованном в кодировке UTF-8, во всех без исключения частях сообщения. Все изменения, необходимые для адекватной, и даже превосходной поддержки EAI почтовыми программами достаточно легко провести в жизнь. Особенности перехода со старой почты на EAI — предмет текущих исследований, также как и то, как пользователи EAI будут отправлять сообщения пользователям старой почты. Но внедрение EAI неизбежно, и полная свобода общения по почте на всех языках мира вскоре станет реальностью. Разумеется, станут доступны и адреса электронной почты, написанные только на кириллице, которые будут прекрасно сочетаться с кириллическим доменом в зоне.РФ.
