(управляющая поведением подсистемы )может иметь "подстановки" :
%L
The value of the LC_MESSAGES category.
%l
The language element from the LC_MESSAGES category.
%t
The territory element from the LC_MESSAGES category.
%c
The codeset element from the LC_MESSAGES category.
Таким образом, если задать LANG="ru_RU.KOI8-R", то мы получим :
%L
= "ru_RU.KOI8-R"
%l
= "ru"
%t
= "RU"
%c
= "KOI8-R"
Исходные тексты этих функций открыты и широко доступны.
Таким образом, установив LANG=ru_RU.KOI8-R
мы получим сообщения на русском языке в кодировке KOI8-R, а установив LANG=ru_RU.ISO_8859-5
- в кодировке ISO. На некоторых системах точно так же работает переменная MANPATH=.
К сожалению, поле Charset - опционально и по стандарту можно использовать сокращенную форму : LANG=ru_RU или даже LANG=ru. (См. ключ -f ). Поэтому, если ваша система это поддерживает, задавайте максимально длинное имя для LANG=
, указывая Charset. (получить список можно по ). К сожалению, само тоже может различаться.
Довольно значительное число ошибок происходит из за того, что в языке С
определен тип переменных char (хотя точнее было бы назвать его : byte). Это во-первых, жестко привязывает нас к 8-ми битным кодировкам. А во-вторых, кодировка не определена. Поэтому, если мы задаем строку (массив char), в которой употребляются символы не ASCII (с кодами >128) : char string[]="Проверка"; -- результат совершенно непредсказуем и непереносим. Еще больше проблем вызывает идея .
Также вызывает удивление существование (и синтаксическая корректность) типов signed / unsigned char (что такое "отрицательный" символ? Вот unsigned short int
-- понятно)... Если вы планируете работу вашей программы в многоязычном окружении, неплохо бы предусмотреть атрибут Сharset у любой строки символов char *. Или полностью переходить на UNICODE (wchar_t) в качестве внутренней кодировки.
Содержание ""