Если на UNIX машине (с POSIX:1996) средства locale правильно установлены и программы правильно написаны, то локализация включается путем задания строки окружения LANG :
$ export LANG={язык}
Если такой строки окружения нет, то работает значение локализации по умолчанию : LANG="C" или LANG="POSIX" (что то же самое) - минимальный набор параметров, необходимый для функцонирования программ на ANSI C (ISO 9899:1990), в кодировке US-ASCII (7 bit) (Portable Character Set).
Если ваша система имеет полный набор утилит POSIX.2, то узнать установленные в системе и допустимые значения для LANG= можно командой locale :
$ locale -a
По новому стандарту (POSIX.2 приложение E (?)) значения локализации записываются в форме:
language_TERRITORY.Codeset
или формально:
language[_TERRITORY[.Codeset[@modyfier]]]
Стандарт ISO 639 описывает "language names", ISO 3166 - "territory names". Территории _SU более не существует (вернее теперь она означает Судан), однако для совместимости некоторые системы продолжают ее поддерживать как alias : ru_SU --> ru _RU.
К сожалению, стандарта на названия Codeset-ов формально нет (см. Charset и его имя), но в основном принято пользоваться названиями, зарегистрированными для MIME в IANA или в RFC-1700.
Для русского языка LANG={язык} устанавливается как правило равным LANG="ru_RU.KOI8-R" или LANG="ru_RU.ISO_8859-5" . То есть :
$ export LANG="ru_RU.KOI8-R"
Согласно стандарту допустимы также короткие именования значений locale, которые часто оформляются как aliases (псевдонимы) полного наименования. Hапример "C" --> "POSIX".
$ export LANG=ru $ export LANG=ru_RU $ export LANG=ru_RU.KOI8-R
Однако, если вы указываете короткое имя, может оказаться что Codeset вовсе не KOI8-R (см. например RedHat troubles). Лучше не пользоваться умолчаниями, а указывать точное длинное имя.
Во FreeBSD 2.x так и есть. Для Linux - зависит от дистрибутива. В коммерческих реализациях (Solaris, SCO, AIX e.t.c.) как правило используется значение LANG="ru_RU", или укороченное LANG="ru" (и как правило Codeset ISO8859-5 по умолчанию).
Hекоторые могут пожелать сделать себе локализацию в другом наборе символов : ru_RU.X-CP-866 ( ru_RU.IBM866 ), ru_RU.x-mac-cyrillic, ru_RU.ISO_8859-5 или даже ru_RU.CP1251 - на это нет никаких ограничений. :) Все эти кодировки совершенно равноправны и зарегистрированы (кроме x-mac-cyrillic) в IANA . Только не забудте, что локализация, ввод-вывод и отображение национальных символов на терминале - это совершенно разные вещи.
Для США LANG={язык} устанавливается LANG=en_US.US-ASCII (что полностью совпадает с LANG=C) или LANG=en_US.ISO646-IRV (ISO646-IRV - это тот же US-ASCII, но опубликованный ISO). А вот для Великобритании необходимо устанавливать LANG=en_GB.ISO8859-1 поскольку в наборе символов US-ASCII не содержится символа "фунт стерлингов".
Переменная окружения LANG впервые была введена в HP-UX Multi Language Subsystem и формально относится к подсистеме NLS, и поэтому имеет множество "побочных" эффектов : изменяет пути поиска и язык message-catalog-ов (NLSPATH), пути поиска и язык страничек man (MANPATH), влияет на систему X-Windows, MOTIF e.t.c.
Если система локализована не полностью и использовать полное переключение на другой язык (с помощью export LANG={язык}) нельзя, можно включить locale только для функций locale API библиотеки libc, задав значение категорий локализации. Можно также присваивать разные значения разным категориям, задавая их имена в строках окружения :
$ unset LANG
или
$ export LANG="C" $ export LC_CTYPE="ru_RU.KOI8-R" $ export LC_COLLATE="ru_RU.KOI8-R" $ export LC_TIME="C"
- (если Вас раздражают русские даты, сообщения и man-ы, но нужно обрабатывать русские буквы ;-) и т.д.
По возможности сдедует использовать как можно более полное имя для задания локализации, например :
$ export LANG="ru_RU.KOI8-R" $ export LANG="ru_RU" $ export LANG="ru"
- первый вариант наиболее предпочтителен, поскольку точно задает язык, страну и кодировку.
Не рекомендуется использовать строку окружения :
$ export LC_ALL={язык}
поскольку формально такой категории локализации нет, она "виртуальная" и обозначает "одновременно все категории" (* - wildcard). Из за этого во многих реализациях locale API возникают проблемы после вызова функции setlocale(LC_ALL,"") поскольку LC_ALL оказывается "сильнее" чем конкретная категория, например LC_TIME.
Проблемы могут возникнуть также с программами, работающими с PostScript : в категории LC_NUMERIC локализации ru_RU в соответствии со стандартом ГОСТ в качестве десятичного разделителя используется символ 'запятая' : "," в то время, как в стандарте языка PostScript : точка "." А категория LC_NUMERIC оказывает влияние на printf("%f",float); . Используйте значение C (POSIX) для LC_NUMERIC, если вы работаете с PostScript :
$ export LC_NUMERIC="POSIX"
Посмотреть текущие значения категорий локализации можно все той же утилитой locale (без параметров).
$ locale
После включения, работу средств локализации можно проверить.
* ПРИМЕЧАHИЕ: Хотя MIME и POSIX locale используют одни и те же концепции charset и codeset, взаимоотношение между MIME и locale далеко не однозначно. Так что правильная настройка locale вовсе не гарантирует правильную работу почтовой системы (в области работы с национальными символами).
* ПРИМЕЧАНИЕ: В некоторых современных системах начинает появляться локализация в UNICODE. Включается она заданием строки окружения LANG="en_US.UTF-8" для США или соответственно LANG="ru_RU.UTF-8" для России, LANG="ja_JP.UTF-8" для Японии и т.д. См: UTF-8 FAQ.
Содержание "Locale AS IT IS"