(Окончание. Начало в №12, 13)

Перекодировка доставщиком

Итак, не мытьем так катанием можно заставить почтовую программу для Windows отправлять письма в КОИ-8. Но усилия требуются значительные, и не всегда удобно получается.

Гораздо удобнее, если программное обеспечение почтовой машины само может перекодировать почту. Тогда вы берете тот user agent, который вам больше по душе, и все. Только не забудьте отключить шифрацию 8-битных символов.

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

Первая служит для отправки почты и называется "служба SMTP". SMTP - протокол передачи писем в Internet. Вообще-то, служба SMTP и принимает письма, не только отправляет. Однако рассчитывать на SMTP для приема корреспонденции пользователям персоналок не приходится. Дело в том, что служба SMTP исходит из того, что машина-получатель всегда готова к приему почты: 24 часа в сутки, 7 дней в неделю. Конечно, она сможет переждать кратковременный сбой, но это уже ненормально, ЧП. Понятно, что постоянная готовность к приему почты по инициативе удаленного сервера - не есть свойство персональных компьютеров. Их просто выключают, когда не используют, не говоря уже о низкой надежности, ущербной многозадачности и т.д.

Поэтому почта, предназначенная для пользователя ПК, складируется на почтовой машине. Передается она на персоналку ПО ИНИЦИАТИВЕ ПОЛЬЗОВАТЕЛЯ, когда он будет готов ее принять. Этим заведует служба POP (Post Office Protocol).

Дальше все очевидно: надо научить сервер SMTP переводить письма из той кодировки, в которой по воле аллаха представлено отправляемое письмо, в кодировку КОИ-8. Сервер же POP должен переводить письма из КОИ-8 в ту кодировку, которую сможет понять пользователь. В какую только?.. И кто будет учить?..

Как настроить перекодировку на почтовой машине

Как и в случае с почтовыми программами, доставщики уже написаны, причем, не нами с вами. Наиболее известные программы такого рода - sendmail и MMDF. Причем, sendmail является стандартом de-facto. В любой UNIX sendmail входит, и, кроме того, доступен в исходных текстах.

Мы сейчас не будем говорить о несовместимых с SMTP (то-есть с Internet) почтовых системах, таких как Lotus cc:Mail, Microsoft Mail. Внутри сетей, обслуживаемых такими системами, наверняка либо все в порядке с русским языком, либо безнадежно. Нас это не касается, мы рассуждаем о почте в Сети, с которой несовместимые почтовые системы совмещаются с помощью шлюзов, на которых и следует заодно преобразовывать кодировку символов кириллицы.

Кстати, в очередной раз прозвучало слово "UNIX", и надо, наконец, объясниться с теми, кто это имя переносит плохо. Итак, если UNIX вызывает у вас аллергию, подставляйте вместо него далее по тексту одно из слов: NT, VMS, DOS, NetWare. Чем дальше выбранное вами слово стоит в списке, тем ДОРОЖЕ и НЕУДОБНЕЕ будет ваше решение.

В своем оригинальном виде ни sendmail, ни MMDF не предназначены для перекодировки почты. Однако и тот, и другой имеют модульную структуру, то есть состоят из нескольких самостоятельных программ, каждая из которых выполняет свою задачу. Одна принимает корреспонденцию от локальной почтовой программы (то есть от user agent, работающего на той же машине, что и доставщик), другая отправляет письма через медленные модемные соединения по протоколу UUCP, третяя заведует коммуникациями по SMTP, четвертая кладет почту в почтовые ящики пользователей. И есть центральный распорядитель, который всем управяет. Для того, чтобы организовать перекодировку, надо модифицировать нужные нам модули. Для этого вовсе не обязательно их переписывать и перекомпилировать. Можно "обернуть" модуль в универсальный перекодировщик. Такой универсальный перекодировщик вызывается вместо оригинального модуля, принимает вместо него письма, перекодирует их и передает в обработанном виде оригинальному модулю. Аналогично можно "обернуть" и сервер POP.

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

Из какой и в какую таблицу перекодировать

Тут главное - не ошибиться. Если текст представлен в Альтернативной кодировке, а вы его конвертируете, как будто он в Windows 1251, то я вам гарантирую, что информация будет серьезно повреждена, если не уничтожена.

В случае с приходящими письмами (мы предполагаем, что они в КОИ-8, но расчитывать на это тоже нельзя!) надо знать, какую кодировку использует получатель. Пользователи Windows желают получать письма в 1251, DOS - в Альтернативной, а на UNIX вообще могут существовать все кодировки одновременно.

Это была постановка проблемы, далее идет решение. Решение называется Cyrillic Support Manager или сокращенно CSM. CSM - это комплексный кириллизатор UNIX, он имеется для всех коммерческих реализаций этой операционной системы, а также для Linux, правда, в неполном объеме. Система перекодировки почты является составной частью CSM. Давайте посмотрим, как она решает поставленную нами задачу (откуда и во что перекодировать письма).

Откуда

Как всегда, есть несколько подходов к проблеме. Вот вам несколько:

• брать информацию о кодировке из служебных полей заголовка письма;
• брать информацию из конфигурационных файлов;
• иметь выделенный виртуальный сервер для работы с каждой из кодировок;
• определять кодировку по содержимому письма.

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

Второй подход гораздо мощнее. Администратор почтовой машины один раз определяет, что клиентная машина с таким-то сетевым именем или адресом работает в кодировке, скажем, Windows 1251. И теперь вся корреспонденция, отправляемая с данной машины, считается представленной только в этой кодировке. А если у машины нет постоянного адреса? Она может перемещаться по странам и континентам, подключаясь к различным узлам Internet, но все равно обращаясь к своему почтовому серверу и почтовому ящику. Даже если пользователь соединяется с одним и тем же провайдером, он может получать на время каждой сессии другой IP-адрес. Да и в локальных сетях динамическое распределение адресов случается.

Выделенный виртуальный сервер. Давайте запустим на одной почтовой машине четыре почтовых сервера одновременно, по одному на каждую кодировку. Каждому серверу присвоим отдельное сетевое имя и отдельный IP-адрес, например, win.mail.access.ru, alt.mail.access.ru, koi.mail.access.ru, iso.mail.access.ru. Предложим пользователям Windows обращаться со своей почтой на сервер win.mail.access.ru, DOS - alt.mail.access.ru и т.д. Этот вариант не требует фиксировать IP-адрес клиента, не заставляет пользователя в каждое письмо вводить информацию о его кодировке. Пользователю достаточно при конфигурации своей почтовой программы правильно указать адрес почтовой машины. Если он с этим справится, то все ОК. А если не справится? Они такие, пользователи. Или включит в письмо, отправляемое из Windows, текст в Альтернативной кодировке? У него же на машине еще и DOS есть! Если бы у нас не было четвертого варианта, мы бы сказали, что это - проблемы пользователя. Однако у нас четвертый подход есть.

Идея автоматического определения кодировки существенно лучше смотрится, и это решение гораздо ближе к идеальному. Однако необходим хороший алгоритм распознавания, которому мы могли бы доверить свою информацию. Ведь ошибочная перекодировка приводит, как мы уже упоминали выше, к ее потере. Простая проверка байтов на потенциальную принадлежность к той или иной таблице символов не годится. Дело в том, что все четыре кодировки сильно пересекаются между собой, и нужен очень большой текст, чтобы собрать достаточно статистики. Поэтому, если мы хотим надежно определить, в какой кодировке представлен текст, мы должны попробовать его ПРОЧИТАТЬ, перебирая все варианты. Именно так бы поступил человек. Но как научить читать компьютер? К счастью, компьютеру в данном случае не надо уметь полноценно читать, достаточно научиться отличать русский язык от абракадабры. Можно было бы попытаться применить одну из программ коррекции правописания, например. Однако что делать с грамматическими ошибками? Есть такие "писатели", которые способны свести подобные программы с ума...

В общем, пришлось разработать свой алгоритм анализа текста, простой, неизбыточный (то есть не проверяющий правописания там, где это не требуется) и надежный. Теперь можно ответственно заявить, что автоматическое определение кодировки существует и работает достаточно хорошо (достаточно - это значит, что со сбоями мы не сталкиваемся уже пару лет). Однако случайно у кого-нибудь может возникнуть нужда передать по почте ту самую абракадабру. Система распознавания выдаст сообщение о том, что кодировка не определена, и письмо уйдет без перекодировки (или не уйдет вообще, если так установлено администратором). Тем не менее, отправлять по почте абракадабру - конституционное право пользователей электронной почты. И поэтому в CSM реализованы ВСЕ ЧЕТЫРЕ подхода к определению кодировки письма. Основной метод - автоматическое определение. Однако всегда есть возможность явно задать кодировку одним из способов.

Куда

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

• брать информацию о кодировке из служебных полей заголовка письма;
• брать информацию из конфигурационных файлов;
• иметь выделенный виртуальный сервер для работы с каждой из кодировок.

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

Конфигурационные файлы - вещь хорошая, но не годятся в случае с непостоянными IP-адресами (см. выше). Когда же речь идет о локальных пользователях UNIX, это наилучший выход. Рабочая кодировка пользователя или предпочитаемая им кодировка почтового ящика всегда известна из системных или персональных конфигурационных файлов CSM.

Виртуальный POP-сервер (именно по POP-протоколу получают свою корреспонденцию пользователи персоналок) не только дает нам возможность менять IP-адрес клиентской машины по своему усмотрению, но и облегчает администрирование локальной сети. Не надо описывать каждую новую машину в конфигурационном файле. А вводить имя почтовой машины в почтовую программу надо и так, и этак.

Заключение

Надеюсь, что этой статьей автор внес некоторую ясность в вопрос о том, как должна передаваться русскоязычная почта. Да, в настоящее время для организации нормальной работы почты требуются дополнительные усилия. Хорошо, если эта работа возлагается на плечи профессиональных (то есть получающих зарплату) администраторов почтовых машин. Это их работа, но мы рады, если смогли нашим программным продуктом им помочь. Хуже, если проблемой перекодировки приходится заниматься конечному пользователю. Это случается редко, в основном, за границей, но тем сложнее человеку - не с кем посоветоваться, в конце концов. Может быть, ситуация скоро изменится. Но пока это не произошло - обращайтесь, постараемся помочь. Нам очень хочется переписываться с вами по-русски, а не "po-russki".

Сергей Мелихов,
DataX/FLORIN, Inc.