Следствием описанной нами в предыдущей статье путаницы стал совершенно фантастический бардак, который одно время царил в области передачи русскоязычных текстов по электронной почте. Началось все с непонятно чем аргументированного желания отечественных провайдеров доставлять письма пользователям в одной и той же кодировке. Зачем это потребовалось - есть тайна, покрытая мраком. Программу-перекодировщик может написать любой начинающий программист, и тем более производителям софта ничего не стоит включить таковую в состав мейлера, устанавливаемого непосредственно на компьютере пользователя. При этом можно даже переключать кодировку автоматически в соответствии с той, что указана в заголовке письма (как, собственно, сейчас и сделано во всех распространенных почтовых программах). Но умники рассудили по-своему. Потому получалось так: если в заголовке письма кодовая страница была указана правильно (charset=windows1251 и при этом письмо действительно в windows1251), то преобразование проходило нормально (конечно, если еще и программа у провайдера "не забывала" заменить значение поля charset в заголовке). Но вот если мейлер отправителя ошибался, то письмо, написанное в "правильной" КОИ-8, еще раз перекодировалось и получатель имел перед глазами нечто вроде "Дмюом нмтчймачпщ" вместо "Добро пожаловать" (или хотя бы вместо "дПВТП РПЦБМПЧБФШ", что получается при простой ошибке в заголовке). А уж если таких "интеллектуальных" серверов по дороге встречалось несколько... Если бы ошибка в заголовке проходила без наличия промежуточных "умных" инстанций, то мне, как получателю, достаточно было бы вручную перебрать пару-тройку возможных вариантов кодировки и все встало бы на свои места. (Что и сейчас довольно часто приходится делать - например, русскоязычные письма, посланные через веб-почту yahoo.com из Америки, приходят с указанием в заголовке charset=us-ascii, но сам текст в нормальной win1251.) Дошло до того, что проще было posilat pisma na translite, чем возиться с перекодировками. Положение несколько выправилось, когда почти все поголовно перешли на Outlook. Но и сейчас приходится сталкиваться с письмами, в которых содержится что-нибудь вроде "Sb`f`el{e cnqond`! Ndmnbpelemmn on Mnbnphfqjnls m`op`bkemh~" или вообще "???? ?????! ????? ? ???? ??"...

Вторая проблема, истоки которой надо искать в устройстве первых почтовых серверов - пересылка вложений. Казалось бы, в чем проблема - передавай себе байты по Сети, и все тут. Но изначально почта была заточена исключительно под обмен английскими алфавитными символами, т.е кодами 32-127. Коды в таблице ASCII, меньшие чем 32, как мы знаем, представляют команды, то есть вообще не должны отображаться на экране, а коды, большие 127, могли обрезаться семибитными серверами (или подвергаться перекодировке в российских пенатах). Поэтому вложения, в которых по определению могут содержаться байты с любым значением, передают довольно сложным путем: коды преобразовываются так, чтобы они содержали только байты со значением из интервала 33-127. Так устроены распространенные системы конвертации, например, base64. Все, наверное, замечали, что письмо с вложением объемом, скажем, 150КВ, может занимать при передаче более 200 КВ - это плата за такую конвертацию.

Но все это далеко еще не вечер... Программисты - это люди, которые всегда знают, как надо сделать еще лучше, чтобы вам жизнь медом не казалась. Ежу понятно, что если кодировать символы не одним, а двумя байтами, то в получающиеся 65536 комбинаций можно всадить вообще практически все символы любого мирового языка, включая китайский, японский, корейский и другие, даже самые экзотические. Так родилась захватывающая дух идея Unicode, которую по истовости приверженцев можно сравнить разве что с возникновением христианства. Внедрение этой кодировки упрямо проталкивается всеми софтверными фирмами - от MS до Apple, что объяснимо - софтверные гиганты хватаются за любую возможность запутать пользователя как можно больше, чтобы он был вынужден покупать новые версии ихних продуктов. Частично поддержка Unicode была реализована еще в Win95. Между тем, Unicode, в общем, мало кому нужна, кроме этих самых разработчиков ПО, получивших новые заказы. Не верите?

Ладно, пусть я не совсем прав - Unicode, если соответствующий шрифт действительно многоязычен, может быть очень удобен для создания и обмена документами, в которых надо одновременно представлять тексты на разных языках без смены шрифта - скажем, при выкладке документов в Сети, когда на компьютере пользователя, скорее всего, многие национальные шрифты вовсе не установлены. Или, например, исчезла бы проблема представления спецсимволов (всяких фигурных кавычек, многоточий и длинных тире, которые Роману Лейбову, редактору рубрики "Net-культура", очевидно, пришлось очередной раз с ненавистью вычищать из этого текста, так как я сам все время забываю это делать). Ограниченное пространство статьи не позволяет подробно разбирать эти проблемы, и здесь я хочу заметить только, что, во-первых, Unicode позволит решить проблему национальных алфавитов в Сети только частично (т.е. в рамках одного-двух универсальных для всех языков начертаний), а во-вторых, ее, как и "проблему кавычек", можно решить и иными способами, о чем ниже. Но что же мешает нам всем стройными рядами перейти на двухбайтовые кодировки?

Во-первых (и даже не в главных), на совершенно пустом месте возникает проблема совместимости шрифтов, причем не только с однобайтовыми TTF, хотя до сих пор глюки, возникающие при открытии файлов Word 6.0 в Word 97, снятся в ночных кошмарах секретаршам с пятилетним и более стажем¹. Но и современное ПО от таких известных фирм, как Адобе часто несовместимо с Unicode-ttf-шрифтами, причем от версии к версии проблема иногда только усугубляется, как, к примеру, в Illustrator-9 по сравнению с Illustrator-8 (подробности см., например, здесь). Проблемы имеются в Adobe Photoshop, Indesign и при выводе файлов PDF из Pagemaker и Framemaker - а ведь это все популярнейшие продукты, ставшие своего рода корпоративным стандартом. Другой известнейший продукт, спотыкающийся на Unicode - Delphi.

Большинство подобных проблем возникает от того, что механизмы переключения с языка на язык в однобайтовых кодировках и в Unicode принципиально различаются. Для обычных шрифтов достаточно поменять сам шрифт, а в Unicode надо переключать язык (то есть объявлять сдвиг требуемой таблицы символов относительно начала файла). Причем если для обычных редакторов переключение вида отображаемых на экране символов и смена раскладки на клавиатуре есть, вообще говоря, совершенно различные функции, то для Unicode все смешивается. Для того, чтобы один раз в год вписать в русскоязычный текст слово на иврите или на древнегреческом, в Word▓e-6.0 было достаточно на всякий случай иметь нужный шрифт, и все в порядке. А в Unicode-версиях вы малой кровью не обойдетесь - простое объявление фрагмента текста написанным на иврите скажется разве что на проверке правописания. Здесь для этого надо, как минимум, установить нужную раскладку клавиатуры, чтобы после этого обнаружить, что в имеющемся шрифте страница иврита отсутствует... С другой стороны, ошибочно указанная или вовсе не указанная языковая страница часто приводит именно к тому, что наблюдали упомянутые секретарши при попытке открыть не-Unicode файл в Unicode-редакторе. Но все ли в мире работают в MS Word▓e?

Пользователю текстового редактора удобнее, когда каждый шрифт располагается в отдельном файле и имеет специфическое название - так вы точно знаете, какими, к примеру, русскоязычными шрифтами вы располагаете. Да и для разработчиков ПО жизнь несравненно облегчается. А по файлу Unicode ничего понять нельзя - очень возможно, в данном шрифте вовсе нет кириллической страницы. Вот мы и перешли к главному: ведь по идее каждый (каждый!) файл шрифта в формате Unicode обязан иметь все без исключения возможные кодовые таблицы. Но кто же этим будет заниматься?! Какое дело разработчикам из "Параграфа" до вьетнамского или тайского языка - да они, скорее всего, не смогли бы создать приличный шрифт необходимого начертания, если бы даже и захотели. Точно так же японцам, да и самим американцам нет дела до кириллицы. А если в файле Unicode нет какой-то страницы, то вся затея полностью обессмысливается - намного проще и для разработчиков и для пользователей иметь русский или вьетнамский шрифт отдельно и тем самым решить массу проблем одним махом. Потому сама затея с Unicode мне несколько напоминает тех самых провайдеров, которые взялись унифицировать кодировку почты - задумано хорошо, но зачем все это? Можно попробовать придумать пару методов, которые окажутся ничуть не хуже Unicode, но без необходимости иметь столь громоздко устроенный языковый механизм - с использованием каких-нибудь shift- или даже escape-переключателей (ну, назовите их "тегами"), например.

Между тем, консорциум Unicode приготовил для нас еще более великолепный подарок, которого мы все ждали, конечно, пуская слюни от нетерпения. В новом стандарте ISO/IEC 10646 предусмотрены шрифты с... 21-битной кодировкой. Там даже можно создавать свои собственные частные кодовые страницы. Никак для новых докторов Заменхоффов заготовили.

---

¹) А представим на секунду, что у нас за ПО, как в Америке, действительно приходилось бы платить те деньги, которые запрашивает MS - сколько тогда старых Office-95 и Word▓oв-7.0 было бы еще в ходу? Впрочем, они и так в ходу, на что указал читатель Владимир Георгиев: "в России работает на удивление много старых машин". И не только в России, добавим. Наблюдать секретаршу, работающую в "MS Word for DOS 6.0" в конторе какого-нибудь американского юриста - вовсе не исключительный случай. (назад к тексту)