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

[Olej]

Опять у меня мельком выплыла тема локализации русскоязычных строк в программах на C.
Тема освещена в литературе крайне плохо ... потому, что народ изучает C по переводным учебникам, а тем вполне хватает ASCIIZ и типа данных char*.

Но для работы с русскоязычными строками временами не хватает представления char[].
И тогда возникает иногда необходимость применять:

1. "широкие" символы wchar_t, которые являются (в POSIX) прямым изображением UNICODE кодировки UTF-32, и, естественно, каждый символ занимает 4 байта;

2. многобайтные представления, которые хоть и загружены в char[], но в кодировке UTF-8 (т.е. тоже UNICODE, но в другой кодировке); они непригодны для непосредственной обработки строковыми функциями + функции преобразований (mbtowc(), wctomb(), mblen(), mbrtowc(), wcrtomb(), mbrlen() и т.д.), для преобразования в wchat_t[] и обратно (См.: Многобайтовые символы, mbchar(3C))

Но часто можно работать в программе С со строками char[] и не прибегая к локализованным формам.
Вот я и решил для себя освежить в памяти (последний раз писал что-то связанное с этим году в 2008-м):
- когда достаточно char[], а когда и потребуются локализованные представления;
- как работать с локализованными строками простейшим образом.

[Виктория]

Но часто можно работать в программе С со строками char[] и не прибегая к локализованным формам.
Вот я и решил для себя освежить в памяти (последний раз писал что-то связанное с этим году в 2008-м):
- когда достаточно char[], а когда и потребуются локализованные представления;
- как работать с локализованными строками простейшим образом.

Со своей женской наивностью смею предположить, что локализованные строки нужны при взаимодействии потоков разных родительских процессов. Или более формально - при передаче информации между разными уровнями эталонной модели взаимодействия открытых систем.

[Olej]

Но часто можно работать в программе С со строками char[] и не прибегая к локализованным формам.
Вот я и решил для себя освежить в памяти (последний раз писал что-то связанное с этим году в 2008-м):
- когда достаточно char[], а когда и потребуются локализованные представления;
- как работать с локализованными строками простейшим образом.

Со своей женской наивностью смею предположить, что локализованные строки нужны при взаимодействии потоков разных родительских процессов. Или более формально - при передаче информации между разными уровнями эталонной модели взаимодействия открытых систем.

Может быть и это ... нужно будет посмотреть в ту сторону.

Но локализованные строки нужны в любых операциях контекстного поиска, использования регулярных выражений и т.п. Что гораздо шире.

Мультибайтное представление строк (UTF-8) - это внешнее представление, т.к. строки приходят и уходят в процессе обмена с а). терминалом, б). GUI окошками, ... и даже в). текстовой консолью. Если для их содержимого не предполагаются какие-то трансформации, поиск, выделения и т.п. - они так и могут оставаться в памяти в формате UTF-8 (мультибайтовые char[]), и позже с успехом также использоваться для вывода.

Но если нам нужны операции с содержимым строки, то она должна быть преобразована в wchar_t[] (UTF-32), а потом над ней выполнять операции функциями вида wcs*() аналогичными str*(), например, вместо strchr() - wcschr() и т.д. А перед выводом (например в файл) полученные строки wchar_t[] обратно нужно преобразовать в char[]. Исключение здесь состоит в функции printf, которая может "проглотить" малоизвестный формат "%ls" - который и предполагает wchar_t-строки. А также, предполагаю, и fprintf(), которая сделает такое же преобразование при выводе в файловый поток.

[Olej]

Но если нам нужны операции с содержимым строки, то она должна быть преобразована в wchar_t[]

Вот некоторые, пока начальные, фокусы в этом направлении (программа в архиве):

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

bash-4.2$ ./locstr -vv
размер wchar_t = 4, размер wint_t = 4
локализация: ru_RU.utf8
строка (или @файл): ^C

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

bash-4.2$ ./locstr -v
локализация: ru_RU.utf8
строка (или @файл): строка
преобразовано: 12 байт в 6 символов
printf: строка
строка (или @файл): ещё 1-на строка
преобразовано: 26 байт в 15 символов
printf: ещё 1-на строка
строка (или @файл): new srting
преобразовано: 10 байт в 10 символов
printf: new srting
строка (или @файл): ^C

Ну и, для памятки, то, какие локализации присутствуют в Linux (например), и подсказка как их правильно записывать:

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

bash-4.2$ locale -a
...
ru_RU
ru_RU.iso88595
ru_RU.koi8r
ru_RU.utf8
russian
ru_UA
ru_UA.koi8u
ru_UA.utf8
...
uk_UA
uk_UA.koi8u
uk_UA.utf8
...
uz_UZ
uz_UZ@cyrillic
uz_UZ.iso88591
uz_UZ.utf8@cyrillic
...

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

bash-4.2$ locale -a | wc -l
777

[Olej]

Всё, что связано с локализациями, продолжается сильно обсуждаться вот здесь (чтоб не переписывать одно и то же): переносимость Lin<=>Win консольных приложений.

[Olej]

Но часто можно работать в программе С со строками char[] и не прибегая к локализованным формам.
Вот я и решил для себя освежить в памяти (последний раз писал что-то связанное с этим году в 2008-м):
- когда достаточно char[], а когда и потребуются локализованные представления;
- как работать с локализованными строками простейшим образом.

Со своей женской наивностью смею предположить, что локализованные строки нужны при взаимодействии потоков разных родительских процессов. Или более формально - при передаче информации между разными уровнями эталонной модели взаимодействия открытых систем.

Мельком возвращаясь к этому вопросу (локализация строк) ... навеяно это разборками с языком Python и с тем, насколько там лучше всё это сделано.

Локализация строк "вылазит" как только вы начинаете перемещать программы или данные межу различными системами:
- операционными: Linux - Windows - Solaris - MINIX и т.д.
- аппаратными: x86 - ARM - MIPS - PPC и т.д.
- сетевыми хостами: big-endian - litle-endian, ... да и HTML-контекст в разных кодировках ...

До тех пор, пока вы "замкнуты" в окружении одной системы - вам локализация не грозит. До тех пор, пока "вся страна сидела в винде" (года до 88-89) никто и не заикался о локализациях.
P.S. Правда был казус на заре MS-DOS, когда разные локализаторы понаделали различных таблиц ASCII (2-х половин, 128-255), а под них понаделали соответствующих клавиатурных руссификаторов ... но это только потому, что все "спешили впереди паровоза". Откуда и CP-1251, и KOI-8r, и всякая другая дрянь...

По поводу ваших замечаний...

локализованные строки нужны при взаимодействии потоков разных родительских процессов.

Здесь мне непонятно почему... или я не понял что имеется в виду.

Или более формально - при передаче информации между разными уровнями эталонной модели взаимодействия открытых систем.

А здесь, в принципе, "да". Это и есть тот случай, что я назвал "сетевыми хостами".
Решать эту задачу назначен был "представительский" уровень 7-ми уровневой модели ANSI.
Вот только с самой 7-ми уровневой моделью взаимодействия открытых систем случился казус :
- доминирующими с IT-индустрии стали протоколы TCP/IP (со всеми своими прибамбасами, и описанный в 200 и более книгах RFC)...
- а TCP/IP - более раннее творение, чем 7-ми уровневая модель...
- и TCP/IP не вписывается в 7-ми уровневую модель со своим собственным делением уровней: L1, L2, L3

[Виктория]

Мельком возвращаясь к этому вопросу (локализация строк) ... навеяно это разборками с языком Python и с тем, насколько там лучше всё это сделано.

Локализация строк "вылазит" как только вы начинаете перемещать программы или данные межу различными системами:
- операционными: Linux - Windows - Solaris - MINIX и т.д.
- аппаратными: x86 - ARM - MIPS - PPC и т.д.
- сетевыми хостами: big-endian - litle-endian, ... да и HTML-контекст в разных кодировках ...

До тех пор, пока вы "замкнуты" в окружении одной системы - вам локализация не грозит. До тех пор, пока "вся страна сидела в винде" (года до 88-89) никто и не заикался о локализациях.

Или более формально - при передаче информации между разными уровнями эталонной модели взаимодействия открытых систем.

А здесь, в принципе, "да". Это и есть тот случай, что я назвал "сетевыми хостами".
Решать эту задачу назначен был "представительский" уровень 7-ми уровневой модели ANSI.
Вот только с самой 7-ми уровневой моделью взаимодействия открытых систем случился казус :
- доминирующими с IT-индустрии стали протоколы TCP/IP (со всеми своими прибамбасами, и описанный в 200 и более книгах RFC)...
- а TCP/IP - более раннее творение, чем 7-ми уровневая модель...
- и TCP/IP не вписывается в 7-ми уровневую модель со своим собственным делением уровней: L1, L2, L3

локализованные строки нужны при взаимодействии потоков разных родительских процессов.

Если быть честной, то я не помню, что я хотела кратко зафиксировать. Я думаю, что всем следует проигнорировать это замечание.

"Представительский" уровень в TCP/IP тоже присутствует?

[Виктория]

Olej, можно ещё один вопрос:
Когда я сохраняю Ваши файлы на свой компьютер с Windows, например с примерами по Python, не могут возникнуть проблем с локализацией (Вы, вот, для копирования примеров между Linux и Windows используете FTP)?

[Olej]

Когда я сохраняю Ваши файлы на свой компьютер с Windows, например с примерами по Python, не могут возникнуть проблем с локализацией (Вы, вот, для копирования примеров между Linux и Windows используете FTP)?

У меня не наблюдается нарушений с локализацией, поэтому я не могу проверить ... но я видел ваши цитаты с нарушенной локализацией.
Давайте проверять и искать причину где-то в конкретной теме (по Python) на конкретных примерах.
Проблемы могут быть, предполагаю, связанные с различными версиями Windows или локализациями этих инсталляций Windows.

Копирую я файлы в Windows по FTP, ... но я выкладывал архивы, *.tgz - вы именно архивы брали для проверки?
Архив или разархивируется, или нет, если он скачан с ошибками (побит).

Или вы копировали тексты программ с экрана копи-паст? Тогда нарушения, конечно, будут - на этапе именно паст

[Виктория]

В качестве примеров я брала файлы с расширением py