локализация строк в C-коде

[Olej]

К счастью, в Linux (UTF-8) не приходится решать такие проблемы.

Разбираясь плотно с примерами кода относительно локализации, а ещё больше с регулярные выражения в C/C++, задаюсь несколькими вопросами (их много, и я их выделяю знаком ):

- таблицы Unicode предполагают взаимно-однозначное отображение 4-х байтного кода (UTF-32) в символ, 4 байта содержат и номер кодовой страницы (язык) и смещение кода символа в странице...
- кодирование UTF-8 предусматривает взаимно-однозначное кодирование от 1-го до 6-ти байт (мультибайтная последовательность) каждого 4-х байтного кода Unicode (символа).
- зачем тогда в коде C/C++, который хочет работать с широкими символами (wchar_t, wstring), выводом (вводом) в (из) поток wcout / wcin, или взаимными преобразованиями мультибайтных (UTF-8) и широких (UTF-32) символов (mb*() и т.п.), нужно обязательно установить локаль вызовами типа :

Код: Выделить всё

setlocale( LC_CTYPE, "ru_RU.utf8" ); // язык C

Код: Выделить всё

std::locale( "ru_RU.utf8" ); // язык C++

- почему установив локаль как en_US.utf8, получим вот такой результат :

Код: Выделить всё

void test14( void ) {
   printf( "locale: %s\n", setlocale( LC_ALL, NULL ) );
   setlocale( LC_CTYPE, "en_US.utf8" );
   printf( "%ls : %s\n", L"русская строка в локали", setlocale( LC_CTYPE, NULL ) );
}

Код: Выделить всё

$ a.out
locale: C
русская строка в локали : en_US.utf8

- т.е. от языка в локали ничего не зависит ... только лишь бы UTF-8
- зачем тогда вообще установка локали
- и почему она не нужна библиотекам сопоставления с регулярными выражениями

[Olej]

- т.е. от языка в локали ничего не зависит ... только лишь бы UTF-8
- зачем тогда вообще установка локали
- и почему она не нужна библиотекам сопоставления с регулярными выражениями

Установим корейскую языковую локаль:

Код: Выделить всё

[olej@dell Соль]$ export LANG=ko_KR.utf8

[olej@dell Соль]$ locale | head -n2
LANG=ko_KR.utf8
LC_CTYPE="ko_KR.utf8"

И вот:

Код: Выделить всё

[olej@dell regex]$ echo "русский текст на корейский манер"
русский текст на корейский манер
[olej@dell regex]$ echo вашшче | egrep "ш{2,}"
вашшче

А вот мои собственные программы (C), которые не изменяют вообще локаль! :

Код: Выделить всё

[olej@dell regex]$ ./regex3 "(аш)+"
шабаш
'шабаш' ->
6/10 : аш
6/10 : аш
^C

[olej@dell regex]$ ./regex2 арт
аппарат апартамент аплодисмент
'аппарат апартамент аплодисмент' ->
19/25 : арт
^C

[Olej]

- зачем тогда в коде C/C++, который хочет работать с широкими символами (wchar_t, wstring), выводом (вводом) в (из) поток wcout / wcin, или взаимными преобразованиями мультибайтных (UTF-8) и широких (UTF-32) символов (mb*() и т.п.), нужно обязательно установить локаль вызовами типа :
...
- зачем тогда вообще установка локали

И, насколько я понимаю на сейчас, дело в том, что традиционно программа C/C++ сама и по умолчанию устанавливает локаль "C" или "POSIX" - так говорит стандарт POSIX:

...
The strings "C" and "POSIX" are reserved as identifiers for the POSIX locale (see POSIX Locale).
...
7.2 POSIX Locale
Conforming systems shall provide a POSIX locale, also known as the C locale.
...
The POSIX locale can be specified by assigning to the appropriate environment variables the values "C" or "POSIX".

Это установилось много-много лет назад, и в такой локали не может быть никаких многобайтных символов UTF-8, в ней отображаются только 7-бит ASCII символы (так было ещё на компьютерах PDP, на которых первоначально отрабатывались и язык C и операционная система UNIX). В любой UTF-8 локали, независимо от языковой локализации, все преобразования с любыми языками будут выполняться корректно.

И никакие такие фокусы будут непотребны когда в самих языках их стандартами предусматривается, что символьное кодирование в них будет всегда производиться в UTF-8, как, к примеру, в Python ver.3 (как мне помнится), или в Go.

[Olej]

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

Поэтому по ситуации набросал 3 очень маленьких заметки о ... начальном введении в вопросы локализации.