Кириллизация в Linux

Алексей Барабанов

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

Тема кириллизации или «русификации», как иногда выражаются, с некоторых пор исчезла с первых позиций рейтингов интереса со стороны неофитов Linux. В нашей стране уже давно не внедряются новые кодировки. И хотя по их числу мы не превосходим народности с иероглифическими методами написания, но в европейском регионе явно ходим в рекордсменах. И вот теперь, когда, казалось бы, уже нет проблем, чтобы предложить пользователям Linux все разнообразие проверенных наработок и материалов по кириллизации, многие дистрибуторы начинают экономить, можно сказать, на самом святом. Им кажется, что надо уже сейчас заставить всех пользователей работать в универсальной кодировке UTF8 (алгоритм 8го представления символов UNICODE) и в локалях, сделанных на ее основе. Увы, в данном вопросе именно пользователи попадают между молотом и наковальней, между стремлением разработчиков дистрибутивов к псевдопрогрессу и консервативностью рынка прикладного программного обеспечения. Обсудим данный вопрос подробно на примере дистрибутива SuSE Linux 10.0 и в сравнении на примере ряда других ведущих дистрибуций.

Терминология и проблематика

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

Есть два способа: по содержимому самого потока данных, так называемый «in-band», и на основании внешнего предписания, или «out-band».

Первый способ зависит от формата, второй – диктует формат. Изначально использовался только второй способ. Например, в первых персональных компьютерах исключалось применение символьных данных в кодировках, отличных от кодовой страницы 437 (IBM Codepage 437). Использование данной кодовой таблицы было закреплено аппаратно, то есть внешним путем. С распространением компьютерной технологии в регионах, где приняты иные требования на представление символьных данных, была определена процедура так называемой локализации, или модификации программного обеспечения для использования региональных стандартов. Но данный путь оказался слишком трудозатратным. И тогда было произведено функциональное выделение всех национально-зависимых программных компонентов так, чтобы можно было настраивать требуемую локализацию динамически. Естественно, данная процедура всецело определялась платформой. Так, в частности, на обсуждаемой платформе GNU/Linux локализация управляется единым образом на основе так называемых «локалей» (locale) с помощью системной библиотеки glibc.

Второй способ, «in-band», подразумевает, что, получив некоторые символьные данные, программа самостоятельно сумеет определить их кодировку, пользуясь лишь информацией из входного потока. Например, кодировка может указываться в самом файле или в начале потока данных. Такой способ принят во многих внутренних форматах, поддерживаемых текстовыми редакторами, в формате HTML для этого используются специальные тэги, а в протоколе HTTP специальные опции и так далее. Но, несомненно, самым универсальным является способ использования кодировки такого размера (разрядности), чтобы она смогла содержать в себе все возможные символьные комбинации. Так возникла идея кодировки UNICODE (Unicode standard ISO 10646, или Universal Character Set, или UCS) и её более компактной версии UTF-8 [1]. Казалось бы, проблема решена, да не тут-то было! Универсальная кодировка не отправила использование локалей в прошлое, а лишь добавила проблем, поскольку увеличила их число!

Локали в Linux

Итак, в программном окружении определяется понятие локали как совокупности данных об используемых языковых и национальных особенностях среды исполнения. Именно пользуясь параметрами локали, программа «понимает» правильным образом символьные входные данные и выводит свои отчеты в правильных кодировках. Здесь, в самом определении, заложена некая условность, приводящая к неверному пониманию сущности происходящего. Бытует мнение, что из привязки локали к процессу следует легкость манипулирования её настройкой. Мол, если локаль передается процессу из окружения, то ничего нет проще, как установить любую локаль прямо перед запуском. Например, в Linux используются для этого переменные окружения LC_* и LANG. Эти переменные формируются в процессе отработки профиля пользователя и далее передаются всем порожденным процессам. Вот как все просто! Если в системе в базе локализации присутствует нужная локаль, то, указав ее в окружении, мы можем заставить работать с нею любой процесс. Увы, нет! Это со всех сторон наивный взгляд. Чтобы понять свойства локали, давайте взглянем на процесс ее образования (см. врезку «Локали и их образование»).

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

Самый простой пример такой ситуации, когда программа использует ранее накопленные данные, где тип используемой кодировки определяет информацию – это имена файлов, индексы в структурах БД, базы служебных сообщений, сохраненные из Интернета документы. Вы наблюдали на экранах компьютеров «кракозябры» в сообщениях программ, которые в 90% случаев работали вполне адекватно? Вам приходилось вместо имен файлов видеть всякую «бнопню»? Это именно те случаи, когда программа воспользовалась строковой константой, подготовленной в другой локали, или пыталась прочесть символьные данные, созданные с использованием иной локали. Даже точно «угадав» локаль исходных данных, то есть, казалось бы, сводя проблему к тривиальной перекодировке, не всегда удается достичь успеха. Пример тому – данные, упорядоченные или проиндексированные, в соответствии с алфавитным порядком для некоторой локали. Здесь перекодировка не даст успеха, а сортировка будет уже не только трудоемкой, но и даже невозможной, если используются разделяемые данные, что характерно для совместной сетевой работы.