Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum






Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

Знакомство с Linux. Часть 13
Раздел: Статьи
Рубрика: ОПЕРАЦИОННЫЕ СИСТЕМЫ
Имя документа: Знакомство с Linux. Часть 13
Адрес страницы: http://www.fcenter.ru/articles.shtml?os/7018

Автор: братец кролик
05.07.2003 22:45:00
Если бы в нашем сериале о Linux принято было сопровождать каждую главу зазывными заголовками с претензией на художественность, нынешнюю, юбилейную тринадцатую, я с наслаждением поименовал бы так: "Собираем вещички". Речь ни в коем случае не пойдёт о приостановке изучения системы. Нет-нет! Просто, поработав со свежеустановленной поверх предыдущей версией Red Hat Linux 9, я пришёл к твёрдому выводу: надо мигрировать. Полноценно мигрировать на "девятку", а не ограничиваться модернизацией. Причина - в том, как реализована в новом дистрибутиве от Red Hat поддержка русского языка.

Здесь я допущу небольшое лирическое отступление. Сторонники российских (а также украинских, белорусских и т. п.) дистрибутивов Linux приводят множество аргументов в поддержку того, почему предпочитаемые ими системы хороши именно для местного пользователя. Аргументов, априори вовсе не очевидных. Ведь зачастую в качестве основы для таких продуктов берётся известный дистрибутив международного класса (тот же Red Hat), в нём решаются силами местных программистов все вплоть до мельчайших проблемы с локализацией, иногда добавляются ещё несколько пакетов - и новинка для внутреннего рынка готова. Соответственно, если в одном из пакетов исходного дистрибутива выявляется уязвимость, то полноценная "заплатка" для дочернего, локального варианта Linux появится, очевидно, с некоторым запозданием. Так что хотя с точки зрения удобства пользования местные версии Linux выигрывают у исходных англоязычных, к ним можно предъявить некоторые претензии в области надёжности и устойчивости к атакам. И лично мне этот аргумент виделся очень существенным - до самого последнего времени. До того, как я принялся модернизировать Red Hat Linux 7.3 до девятой версии. Конец лирического отступления.


Как известно, большой проблемой русского Интернета - и вообще компьютеризации Руси - была и остаётся неразбериха с кодировками кириллицы. Я не буду сейчас вспоминать, что было раньше и что стало потом, благо литературы по теме имеется масса. Сформулирую основное: в Windows-системах безраздельно царствует кодировка cp1251, Linux же и *NIX, включая всевозможные версии *BSD, до сих пор оставались вотчиной старой доброй KOI8-R. За долгие годы сторонники свободного ПО прекрасно научились справляться с этим, разработав множество удобных утилит для перекодировки - а широкая популярность веб-сервера Apache привела к тому, что множество страниц Рунета хранятся на поддерживающих сайты компьютерах именно в KOI8. Однако времена меняются: именно компания Red Hat, начиная с восьмой версии своего дистрибутива, сделала в системе стандартом универсальную кодировку UTF8.

Универсальность - это великолепно. Когда UTF8 войдёт во всеобщий обиход, проблемы со "странными значками", "закорючками", "вопросиками" и "квадратиками" в сообщениях исчезнут без следа. В одной и той же системе закодированы все алфавиты мира, включая азиатские, - имеется даже проект по внедрению в стандарт UTF египетских иероглифов, благо знакомест хватает. Но вот какая тонкость: светлые времена, о которых с восторгом повествуют поборники UTF, пока не наступили. И когда наступят - неясно. Точнее, ясно: ровно тогда, когда эту систему кодирования поднимет на щит Microsoft. А пока компания Red Hat решила, что раз будущее всё равно наступит, то незачем ждать его сложа руки. Нужно взять - и приблизить. Всё равно подавляющее большинство пользователей продукта компании англоязычны, а для них что UTF, что ASCII - по большому счёту, разницы нет.

Но для нас - есть, и притом существенная. Что нужно для полноценной работы с компьютером, пользователь которого является носителем отличного от английского языка? Точнее - языка, где для записи информации употребляются буквы, отличные от базовых 26 английских? Такому пользователю важнее всего возможность создавать документы на родном языке, без проблем открывать и читать уже созданные такие документы, и, конечно, свободно переключаться между универсальной и местной клавиатурными раскладками. Простейшие требования, верно? В Windows никому и в голову не приходит, что тут могут возникать какие-либо сложности.


Строго говоря, до настоящего времени у меня никаких проблем с кодировками при использовании Red Hat Linux не возникало. Русификация и консоли, и графического режима (особенно в оконном менеджере KDE) была уверенно реализована, хорошо описана и тоже воспринималась как нечто само собой разумеющееся. Вот в Red Hat Linux 5.0, помнится, с этим дело обстояло не так просто... Но воды с той поры утекло немало, и всё было бы замечательно, если бы не возникшая перед нами сейчас необходимость: перейти при модернизации системы с версии 7.3, где в качестве русской кодировки по умолчанию применялась KOI8-R, на девятую версию с её прогрессивной UTF.

Загвоздка же в том, что при апгрейде многое в системе остаётся прежним. В частности, если вы активно работали с русским текстом в консольных редакторах (или сохраняли лог-файлы ICQ-клиентов вроде licq в домашней директории), прочитать записанный в KOI8-R текст теперь будет трудновато. К тому же, помимо перехода к UTF, начиная с версии 8.0, Red Hat "обкатывает" на пользователях ещё одно новшество: совмещение двух популярнейших оконных менеджеров, KDE и Gnome. Переработанный кудесниками в красных шапках графический интерфейс Bluecurve является синтезом наиболее сильных сторон обоих конкурирующих продуктов. (Поскольку оба продукта - свободно распространяемые и с открытым кодом, становится возможным, как видим, и такое непредставимое в мире бизнеса явление, как их жизнеспособная контаминация). Побочной стороной этого слияния является то, что - как в случае моей домашней системы - никуда не девшиеся прежние настройки оконного менеджера (именно в части управления раскладкой клавиатуры) начинают конфликтовать с новыми.

Суммирую: после апгрейда Red Hat Linux 7.3 до версии 9 я столкнулся с достаточно серьёзными сложностями в работе, которых - проводи я нормальную установку системы - попросту не возникло бы. Поэтому на сей раз мы рассмотрим, каким образом осуществить полноценную миграцию на новую систему. И начнём с самого начала.

С самого начала, сразу после первой перезагрузки, последовавшей за апгрейдом, в системной консоли стали наблюдаться, скажем так, некоторые несуразности. А именно: раньше при старте системы отдельные сообщения о запуске её компонент отображались с использованием кириллицы (и разумеется. В KOI). Что-то вроде

Запускается sendmail [ OK ]
Теперь же вместо каждой из букв кириллицы на экране отображалась "у-умляут" - судя по всему, вследствие того, что в наследство "модернизированной" системе с UTF достались некоторые утилиты, всё ещё пытающиеся организовать вывод в KOI. Тем не менее, с латиницей всё было в порядке, и после запуска X Window System я с облегчением увидел, что отображение кириллицы (в заголовках окон, названиях разделов и программ в меню запуска и т. п.) там работает. За исключением маленькой детали: отказало переключение с русской клавиатуры на английскую и обратно.


Нет, соответствующая опция из Центра управления KDE никуда не делась. Вот только, судя по всему, при слиянии KDE с Gnome в Red Hat получили продукт, не полностью совместимый с предшествующими "полноценными" версиями этих графических оболочек. По крайней мере - в данной конкретной области, связанной с локализациями, и в особенности с локализациями приложений. К тому же, прочесть элементарный текстовый файл, набранный когда-то в консоли кириллицей в KOI8-R, я уже не мог ни при помощи less, ни с использованием vi или cat.

Строго говоря, ничего удивительного: при инсталляции система вовсе не обязана каждую имеющуюся на винчестере запись в KOI (будь то рабочий текстовый файл или стандартное сообщение в локализованной ранее программе) переводить в UTF. Хотя... Быть может, вариант безболезненного апгрейда будет осуществлён в одном из наших местных дистрибутивов, берущих за основу продукты Red Hat? А может, он уже осуществлён, просто мне об этом ничего не известно? Знаю пока только, что очень хочу добиться нормального обращения с кириллицей именно в Red Hat Linux 9, и сейчас вместе с вами этого таки добьюсь. По крайней мере, в пределах, необходимых для дальнейшей полноценной и безболезненной миграции на полный UTF.

Разумеется, я не первым столкнулся с подобной проблемой: переход на UTF Red Hat произвела ещё в полугодичной примерно давности версии 8.0. И в качестве одного из возможных рецептов действий в такой ситуации гуру предлагают отказ от перехода как такового - иными словами, возвращение к использованию KOI. "Даунгрейд" одной из компонент системы, если можно так выразиться. Дабы избежать, в частности, неприятных последствий "выборочной" замены KOI на UTF.


И всё-таки я предпочту другой путь, что, кстати, имеет смысл и для всех начинающих: осуществить грамотную миграцию на UTF и работать отныне уже с ней. Потому что за универсальной кодировкой всё-таки будущее. Но чтобы к этому будущему приблизиться, сперва нужно хоть как-то привести в порядок текущий вид отображения символов в консоли. Многие операции, связанные с сохранением данных, предпочтительнее производить под непосредственным личным контролем - "ручками", как говорят всё те же гуру. Для пущей уверенности, что всё сделано правильно.

Итак, прежде всего справимся с пренеприятнейшими "умляутами", заполонившими вместо русских букв нашу консоль. За то, какой именно набор символов используется при выводе консольных сообщений, ответственны несколько переменных окружения, задающихся в файле /etc/sysconfig/i18n. Название файла, кстати, - весьма остроумное сокращение от слова "internationalization": 18 - это число букв между начальной i и конечной n.


Параметр LANG определяет так называемую локаль (locale) - режим, в котором работает выводящий символы на экран драйвер консоли. Здесь, как и можно ожидать после апгрейда системы, установлено значение "ru_RU.UTF-8". Тем не менее, среди поддерживаемых (SUPPORTED) кодировок наличествует и ru_RU.koi8r. Однако, как можно убедиться, в случае системных сообщений "по-русски" это не помогает. Можно предположить, что корректно будет обрабатываться вывод символов в том случае, если их кодировка чётко указана - средствами производящего вывод приложения, скажем (текстового редактора или ещё какого-либо). А со стороны системных приложений, русификация которых не была обновлена по сравнению с предыдущей версией, такого сюрприза консоль явно не ожидает. Дело ещё и в том, что переменная SYSFONT указывает не на бывший ранее привычным консольный русифицированный фонт (скажем, Cyr_a8x16), а на новомодную UTF-новинку latarcyrheb-sun16.

Как можно судить по наименованию данного системного шрифта, ему по силам отображать одновременно символы латинского, арабского, кириллическего и еврейского алфавитов. (Тут, правда, возникает закономерный вопрос - будет ли автоматически меняться направление письма при переходе с кириллицы на арабский, скажем, но пока это нас интересует чисто академически). Однако при попытке отобразить средствами данного шрифта закодированный в KOI текст ничего путного на экране видно не будет. Дополнительную путаницу вносит установка таблицы перекодировки символов (Application Character Map, ACM) для перевода входного потока символов во внутреннюю кодировку ядра - Unicode: SYSFONTACM="utf8". В общем, первое, что я сделал, это избавился от пережитков прошлого в виде упоминания о кодировке KOI, упорядочил задание переменной SUPPORTED и убрал сомнительный параметр SYSFONTACM. В итоге на консоль вернулись русские буквы там, где их выводили системные приложения.


Правда, с несистемными приложениями - а именно, банальными текстовыми файлами в кодировке KOI - всё было не так просто. Ни элементарная команда cat, ни less, more или vi не в состоянии были отобразить на консоли в сколько-нибудь пригодном для чтения виде их содержимое.



Больше того - при попытке просмотреть содержимое подмонтированных vfat-разделов вместо русских букв в названиях файлов снова запестрели вопросительные знаки. Однако с этой напастью справиться было несколько проще. Я ведь знал, что изначально для их отображения применялась кодировка KOI!

Файл /etc/fstab я незамедлительно подправил - учитывая, что выводить символы на экран мне теперь надо в UTF.


Затем потребовалось (чтобы не перезагружаться лишний раз) отмонтировать Windows-разделы, после чего снова присоединить их с использованием нового /etc/fstab. Делается это серией команд

umount /mnt/c
umount /mnt/d
mount -a
Обратите, кстати говоря, внимание: опции для монтирования внешних носителей (CD и DVD) также включают у меня указание на то, что записанные там с применением кириллицы имена файлов следует воспринимать как набранные изначально в Windows-кодировке. Сделано это потому, что под Linux я никогда не использую кириллицу в наименованиях файлов и каталогов, а Windows-диски, напротив, читаю часто (взять хотя бы цифровые приложения к компьютерным журналам). Так что опасности ошибиться нет. Но в принципе, с этой опцией надо обращаться осторожно - и уж во всяком случае постоянно помнить, что она включена и работает.

Следующим шагом, который я совершил по пути тотального перехода на универсальную кодировку, стал перевод текстовых кириллических файлов в UTF. У вас, если ваше знакомство с Linux ещё не вошло в стадию активного увлечения, наверняка не так уж много ценной информации содержится в таком виде. А для меня очень важно было сохранить свои ICQ-логи. Которые программа licq, входящая с некоторых пор в стандартный комплект поставки дистрибутивов от Red Hat, хранит в виде как раз простых текстовых файлов в базовой системной кодировке. Стало быть, они мне после апгрейда оказались недоступны.

Напомню, что в случае Linux хранить чувствительную информацию в виде открытого текста не столь опрометчиво, как под Windows: системные установки по умолчанию блокируют доступ к содержимому вашей домашней директории кого бы то ни было (за исключением суперпользователя, конечно). И поскольку текст хранится в KOI, в данном случае мне нужно было всего лишь перекодировать его из исходного вида в UTF. Что я и сделал посредством утилиты с незамысловатым наименованием recode. Подробности, как водится, доступны по команде man recode.


Лог-файлы ICQ-клиента licq хранятся в подкаталоге .licq/history/ , и все они - я это знал точно - кодированы именно в KOI. Поэтому для того, чтобы архив сделался снова доступным, достаточно было команды

recode koi8-r..utf-8 .licq/history/*
Точно таким же способом я вернул себе возможность читать ещё несколько файлов с кириллическим текстом. Между прочим, как выяснилось при изучении соответствующей документации, в комплект поставки Red Hat Linux 9 входит-таки просмотрщик текста, позволяющий хоть как-то отображать не читаемую иными способами кодировку KOI. Эта программа называется lv, и если теперь вернуть наш тестовый файл в исходное состояние командой

recode utf-8..koi8-r test.txt
то ни less, ни more прочесть его содержимое по-прежнему не позволят, а вот lv вместо кириллицы отобразит для каждой русской буквы определённое латинское соответствие.


Когда-то давным-давно именно так выглядели в Linux-консоли почтового сервера, не поддерживавшей кириллицы в принципе, приходившие в KOI письма... Ах, молодость, молодость...

Однако не время предаваться приятным воспоминаниям. Время заняться полезным делом: приготовить личные данные из домашней директории, а также файлы системных настроек - плоды усердных наших трудов - к сохранению в свете предстоящей полноценной переустановки системы. Строго говоря, форматировать раздел /home я не собираюсь, но бережёного бог бережёт - это во-первых, а во-вторых - с методической точки зрения действия, в которых мы будем вскоре практиковаться, без сомнения окажутся полезными при работе с системой в дальнейшем.

К следующей статье
К оглавлению
Компания "Ф-центр"c, 2003.
При перепечатке и цитировании ссылка обязательна.


Эта статья еще не оценивалась
Вы сможете оценить статью и оставить комментарий, если войдете или зарегистрируетесь.
Только зарегистрированные пользователи могут оценивать и комментировать статьи.

Комментарии отсутствуют