LINUX.ORG.RU

История изменений

Исправление saahriktu, (текущая версия) :

без таблицы кодирования и функций композиции / декомпозиции

Где такое вообще есть?

wchar разный на разных платформах

Тем не менее, проблемы с кроссплатформенностью у wchar_t возникают только на винде при работе с текстом в UTF-32.

а стандартом де-факто является utf8, не utf32

Ну так а я о чём. Из за того, что в UTF-8 у разных символов разный вес в байтах, при работе со строками в UTF-8 есть только 2 варианта:
0) прочитать не в «char *», а в «wchar_t/char16_t/char32_t *». При этом, условно говоря, оно автоматически переконвертируется в условные UTF-16/UTF-32, что облегчит дальнейший разбор строк функциями из wchar.h и т.д., но и выжрет больше памяти.
1) прочитать в «char *», а дальше парсить сложными парсерами на основе функций для однобайтных кодировок.

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

Впрочем, именно поэтому такой софт сохраняет совместимость с однобайтными кодировками на всех уровнях.

Исходная версия saahriktu, :

без таблицы кодирования и функций композиции / декомпозиции

Где такое вообще есть?

wchar разный на разных платформах

Тем не менее, проблемы с кроссплатформенностью у wchar_t возникают только на винде при работе с текстом в UTF-32.

а стандартом де-факто является utf8, не utf32

Ну так а я о чём. Из за того, что в UTF-8 у разных символов разный вес в байтах, при работе со строками в UTF-8 есть только 2 варианта:
0) прочитать не в «char *», а в «wchar_t/char16_t/char32_t *». При этом, условно говоря, оно автоматически переконвертируется в условные UTF-16/UTF-32, что облегчит дальнейший разбор строк функциями из wchar.h и т.д., но и выжрет больше памяти.
1) прочитать в «char *», а дальше парсить сложными парсерами на основе функций для однобайтных кодировок.

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

Впрочем, именно поэтому такой софт сохраняет совместимость с однобайтными кодировками.