От редактора: эта статья первоначально была опубликована на двух сайтах - на BDSPortal и unix.ginras.ru, причем тексты по ряду причин оказались не вполне идентичными. Здесь дается версия с unix.ginras.ru, с некоторыми редакторскими комментариями и дополнениями.

Небольшое вступление

На форумах по Unix-тематике происходит много споров на тему "А нужен ли unicode Unix-системам?". Но чёткого ответа эти споры до сих пор так и не дали. Сделаем простой вывод: раз есть такая кодировка, значит она кому то нужна. Я не буду рассматривать её достоинства или недостатки, не буду склонять к тому, чтобы срочно все переходили на utf, а просто поделюсь своим опытом перехода на unicode в системе FreeBSD. Опять же сразу оговорюсь что данная мной методика не является обязательной в исполнение каждого пункта статьи, а с успехом может быть заменена другими методами решения возникших вопросов.

Если посмотреть на дистрибутивы Linux, то там уже довольно удачно unicode применяеться в качестве основной кодировки таких дистрибутивов, как Suse, Red Hat/Fedora и некоторых других. Остальные создатели дистрибутивов посматривают в эту сторону, но пока не все спешат с переходом на unicode по умолчанию в системе, хотя полная поддержка utf-локализации обеспеченна практически во всех Linux-дистрибуивах.

До сей поры unicode как-то обходил стороной BSD-системы. Но прогресс, так сказать, не стоит на месте, и в недавних релизах BSD-систем (FreeBSD, DragonFlyBSD, NetBSD) появилась в общем-то полная поддержка utf-локализации. Остановимся ее воплощении в самой популярной из этих ОС - FreeBSD (на момент создания статьи - версии 5.3). Но я думаю, то же самое может быть применено и в других BSD-системах. Поставим для себя такую цель: работать во FreeBSD так, чтоб была обеспеченна полная руссификация, причём в unicode.

Unicode в консоли и руссификация

Вот тут мы наступаем на первые грабли. Для начала, что бы не морочить голову, делаем руссификацию в точности как описанно в HandBook - не больше и не меньше.

А как же unicode? Вот тут сразу придётся огорчить читателя, что консоль FreeBSD пока не совсем готова к принятию unicode, а для нормальной работы вам придёться использовать старый добрый koi8-r (или любую другую 8-битную кодировку). Причин здесь несколько, но скажу лишь про одну из основных. Для для того чтобы реально попробовать unicode в консоли FreeBSD, нужны map-файлы (файлы кодировок ввода/вывода символов на консоль). Просто посмотрим в каталоги /usr/share/syscons/scrmaps и /usr/share/syscons/keymaps и убедимся что файлы в кодировке unicode отсутствуют, длительные поиски их в Сети, как мои, так и заинтересовавшихся товарищей, дали отрицательный результат. Да и вообще, если таковые и были бы, то сама структура syscons вызывает сомнения с точки зрения пригодности к unicode, но это требует отдельных широких исследований. А как же тогда юникод? Ответ: X Window System - вот что нам нужно.

Unicode и Иксы

По простому называемые Иксы давно готовы к принятию юникода. Собственно, с ними и будем работать. Конечно, различие кодировок в консоли и Иксах может вызывать противоречивые чувства у многих (типа локаль должна быть едина), но, как говорится, и здесь можно найти свои преимущества. Cама локаль UTF8 идёт во FreeBSD начиная с версии 5.2, но если вдруг не окажется у вас по каким либо причинам, то её можно установить из портов - /usr/ports/misc/utf8locale.

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

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

export LANG='ru_RU.UTF-8'
export LC_ALL='ru_RU.UTF-8'
exec startfluxbox 

Конечно, fluxbox может быть заменён на любой другой менеджер. Мои корреспонденты писали, что что переменную LC_ALL следует делать LC_ALL="", то есть оставить пустой. Но на поверку оказалось, что в этом случае получаем большие проблемы с вводом русских букв в иксовых терминалах, а вот при указании проблема исчезает. Ещё совет - нужно побольше установить шрифтов TTF в каталог /usr/X11R6/lib/X11/fonts/TTF. Это нужно для нормального отображения и вообще для работы в некоторых приложений (подойдут из всем ивестной сиситемы Windows). Рекомендую - после того как скопированны шрифты, сделать следущее под рутом:

cd /usr/X11R6/lib/X11/fonts/TTF
mkfontscale
mkfontdir
fc-cache 

И проверьте, что в /etc/X11/xorg.conf (или /etc/X11/XF86Config, в зависимости от используемой реализации) указан путь к каталогу /usr/X11R6/lib/X11/fonts/TTF.

Иксовые терминалы

Не во всех терминалах ввод/ввывод русского языка при локали unicode проходит нормально, лучше для этого под рукой иметь терминалы с умолчательной поддержкой UTF-8. Нормальные терминалы, поддерживающие unicode-ввод русского с клавиатуры и вывод сообшений на экран терминала по-русски - xterm, mlterm, rxvt-unicode, gnome-terminal. К остальным нужно применять некоторые ухищрения. Например для aterm в файл ~./.Xdefault пишем:

Aterm*background: black
Aterm*foreground: #CECECE
Aterm*scrollBar: true
Aterm*loginShell: true
Aterm*saveLines: 3000
Aterm*transparent: true
Aterm*transpscrollbar: true
Aterm*tintingType: true
Aterm*tinting: #a07040
Aterm*shading: 60
Aterm*fade: 90
Aterm*title: aterm
Aterm*iconName: aterm
Aterm*font: -*-terminus-medium-*-*-*-*-*-*-*-*-iso10646-1
Aterm*boldFont: -*-terminus-medium-*-*-*-*-*-*-*-*-iso10646-1
Aterm*geometry: 80x24
Aterm*termName: aterm

Оконные менеджеры

В принципе, подойдут все сейчас популярные менеджеры. Опробованны в юникоде: KDE, XFCE, wmaker, семейство боксов - openbox, blackbox, hackedbox. Проблем в работе с unicode у меня ни в одном не возникло. Я уверен что и с Gnome будет аналогично. С установленным из портов fluxbox-0.1.14 есть проблема - никак не хотели отображаться опции из Configure и заголовки приложений. Рекомендую метод - взять и удалить эту версию fluxbox вообще, а вместо нее взять последние исходники fluxbox-0.9.12 и пересобрать так:

$ ./configure \
	--prefix=/usr/X11R6 \
	--enable-xinerama \
	--enable-shape \
	--enable-slit \
	--enable-kde \
	--enable-gnome \
	--enable-interlace \
	--enable-nls \
	--enable-timed-cache
$ gmake
$ gmake check
$ gmake install

После этого - проблем никаких.

Midnight Commander

Самый популярный файл-менеджер вызвал больше всего головной боли. Обычный устанавливаемый mc из /usr/ports/misc/mc показал изрядную неспособность работать в юникоде, даже в юникодных терминалах проявляется неотображение mc вообще или нестабильная работа - пропадание некоторых букв при вводе и тому подобное. Ясно, что тут дело в опциях компиляции. Здесь есть три пути борьбы с данной проблемой.

Путь 1 (юниксоида):

1. Распаковываем находящиеся в каталоге /usr/ports/distfiles исходники с mc-4.6.0.tar.gz в любой каталог под рутом (прежде удаляем установленный mc).
2. Берём патчи отсюда - http://www.linux.kiev.ua/%7Esimonov/files/unicode/mc-utf8.tar.gz, распаковываем в каталог с исходником по примеру:

   	$ cat ./.utf8 | patch2 -p1 -b .utf8
   

   и далее также со всеми патчами.
3. Делаем следущую перекодировку:

   	$ iconv -f iso8859-1 -t utf-8 -o mc.hint.tmp mc.hint && \
   	mv mc.hint.tmp mc.hint
   	$ iconv -f koi8-r -t utf8 -o mc.hint.ru.tmp mc.hint.ru && \
   	mv mc.hint.ru.tmp mc.hint.ru
   

4. Далее упаковываем исходник опять в формат tar.gz и кидаем его в /distfiles, идём в /usr/port/misc/mc и в Makefile добавляем для CONFIGURE_ARGS+ опцию сборки --with-screen=slang. Потом всё как обычно:

   	$ make
   	$ make install
   

   При этом сохранится целостность системы и получится юникодный mc.

Путь 2 (наменьшего сопротивления):

Установить вместо обычного mc из портов его форк - /usr/ports/misc/mc-light. Данное ответвление mc развивается нашим российским разработчиком. Что мы теряем при этом: руссифицированное меню, взаимодействие с иксами. Но это при работе в терминале не суть важно. Зато приобретаем: полную поддержку unicode, множество кодировок (особенно это видно при просмотре по F3 файлов с разными кодировками и при перекодирование "на лету" по CTRL+T ), и некоторые дополнительные фичи, одна из которых - прямая запись на CD через обыкновенное копирование по F5, не говоря уж о красивом разноцветном интерфейсе.

Путь 3 (радикальный):

Перебороть в себе тягу к mc и использовать графические файл-менеджеры, поддерживающие unicode - krusader, gnome-commander,gentoo, и т.д. Скажу, что я себя не себя перебороть:-). Я выбрал путь 2, чем чрезвычайно доволен, но, как говориться, каждому своё.

Работа с консольными приложениями в икс-терминалах

Те приложения, которые нормально поддерживают по умолчанию unicode, работают более-менее сносно в вышеуказанных юникодных терминалах. Например такое приложение как centericq, кроме utf-8, уже умеет поддерживать utf-16, и работает без проблем, только после небольшой правки опций. Например, из редакторов с успехом работают в юникоде - nano, pico, vi. Из консольных почтовых клиентов хорошо отработал cone. Но и для нормальной работы с приложениями, unicode не поддерживающими, есть выход. Например, чтобы нормально работать с jed, нужно в ~/.bash_profile прописать:

alias jed='LANG=ru_RU.KOI8-R; jed'

ну и далее в том же духе для нужного вам приложения.

Работа с иксовыми приложениями

C простыми иксовыми и QT-приложениями проблем не замечено. Но вот в GTK - в некоторых приложениях могут вместо букв быть квадратики или кракозябры (например, в меню xmms). Лечиться так: создаём в домашнем каталоге файл ~/.gtkrc и прописываем там следушее:

style "gtk-default" {
fontset = "-*-Nimbus Sans L-medium-r-normal--14-*-*-*-p-*-iso10646-1,\
-*-clearlyu-medium-r-normal--17-*-*-*-p-*-iso10646-1,\
-*-r-*-iso10646-1,*"
}
class "GtkWidget" style "gtk-default"

И всё - вместо квадратиков русские буквы, с размером шрифта можно поиграть.

Вот вроде и всё. Я остался работать в unicode под FreeBSD , пока проблем не наблюдаю.

Дополнение редактора: как резонно заметил Валерий, им описан лишь один из возможных путей unicode-локализации FreeBSD. Мной был опробован другой способ - через переопределение класса пользователя, который я вкратце и опишу. Правда, я делал это в DragonFlyBSD - но в данном аспекте разницы между этими системами нет ни малейшей.

Для начала редактируем файл /etc/login.conf, а именно: вносим в него (например, после описания класса russian) строки

# Russian Users Accounts with UTF-8.
#
rus-utf|Russian Users Accounts:\
        :charset=UTF-8:\
        :lang=ru_RU.UTF-8:\
        :lc_all=ru_RU.UTF-8:\
        :tc=default:

Теперь причисляем пользователя к новообразованному классу:

% pw usermod юзер_имя_рек -L rus-utf

И... и, собственно, все: радуемся utf'ной локали. Единственно, при этом мы утратили возможность работы с кириллицей в консоли - не будем забывать, что дело не только в отсуствии screenmap'ов доя unicode, но и всего остального. А главное - в 8-битном внутреннем представлении символов, свойственном syscons.

А что мы приобрели? Да я и сам путем не знаю, что. Потому что работать с текстами в UTF-8, скажем, в KDE, можно было и так, вне зависимости от системной локали. Работать с unicode, как уже было сказано, все равно не получается. Прочие приложения - честно говоря, не увидел смысла с ними разбираться. И потому быстро вернулся на локаль родную, бомжовскую,,,

Так что тема unicode в BSD-системах остается открытой. Если есть что сказать по этому вопросу - с удовольствием опубликуем.