Почему wchar_t широко не используется в коде для Linux / связанных платформ?

Question

Это меня заинтриговало, поэтому я собираюсь спросить - по какой причине wchar_t не так широко используется в Linux / Linux-подобных системах, как в Windows? В частности, Windows API использует wchar_t для внутреннего использования, тогда как я считаю, что Linux нет, и это отражено в ряде пакетов с открытым исходным кодом, использующих типы char.

Насколько я понимаю, данный символ c, для представления которого требуется несколько байтов, затем в char[] форме c разделяется на несколько частей char*, тогда как в wchar_t[] он образует единое целое. , Не проще ли использовать wchar_t всегда? Я пропустил техническую причину, которая сводит на нет эту разницу? Или это просто проблема усыновления?

Answer 1

wchar_t - это широкий символ с шириной, определенной платформой, которая не очень помогает.

Символы UTF-8 занимают 1-4 байта на символ.UCS-2, который занимает ровно 2 байта на символ, теперь устарел и не может представлять полный набор символов Unicode.

Приложения Linux, поддерживающие Unicode, обычно делают это правильно, над уровнем побайтного хранения,Приложения Windows склонны делать это глупое предположение, что подойдут только два байта.

wchar_t Статья в Википедии кратко затрагивает эту тему.

Answer 2

Первые люди, использовавшие UTF-8 на платформе Unix объяснил :

Стандарт Unicode [тогда в версии 1.1] определяет адекватный набор символов, но необоснованное представление [UCS-2]. Говорится что все символы имеют ширину 16 бит [больше не соответствует действительности] и передаются и хранятся в 16-битных единицах. Это также резервирует пару символов (шестнадцатеричный FFFE и FEFF) для определения порядка байтов в передаваемый текст, требующий состояния в поток байтов. (Юникод Консорциум думал о файлах, а не трубы.) Чтобы принять эту кодировку, мы пришлось бы конвертировать весь текст вход в и из плана 9 между ASCII и Unicode, которые не могут быть сделанный. В рамках одной программы, в команда всего его ввода и вывода, можно определить символы как 16-битные величины; в контексте сетевая система с сотнями приложения на различных машинах разные производители [курсив мой], это невозможно.

Часть, выделенная курсивом, в меньшей степени относится к системам Windows, которые предпочитают монолитные приложения (Microsoft Office), разнородные машины (все это x86 и, следовательно, little-endian) и одного поставщика ОС.

А философия Unix, заключающаяся в том, чтобы иметь маленькие, специализированные программы, означает, что меньшее количество из них нуждается в серьезных манипуляциях с персонажами.

Источник для наших инструментов и приложения уже были преобразован для работы с латиницей-1, так что был «8-битным сейфом», но преобразование стандарту Юникод и UTF [-8] более вовлечен. Некоторые программы не нужны изменить вообще: cat, например, интерпретирует свои аргументные строки, доставлено в UTF [-8], как имена файлов что он проходит без толкования open системный вызов, а затем просто копирует байты от его входа до его выхода; Это никогда не принимает решения на основе значения байтов ... Большинство программ, однако, необходимы скромные изменения.

... На самом деле мало инструментов для работы на рунах [кодовые точки Unicode] внутри; как правило, они нуждаются только искать последний слеш в Имя файла и аналогичные тривиальные задачи. Из исходных программ 170 C ... только 23 теперь содержит слово Rune.

Программы, которые хранят руны внутренне в основном те, чьи смысл существования персонажа манипулирование: sam (текстовый редактор), sed, sort, tr, troff, 8½ (окно эмулятор системы и терминала) и так на. Чтобы решить, следует ли вычислять, используя руны или байтовые строки в кодировке UTF требует балансировки стоимости преобразование данных при чтении и написано против стоимости конвертации соответствующий текст по запросу. Для программ такие как редакторы, которые работают долго с относительно постоянным набором данных, руны - лучший выбор ...

UTF-32, с непосредственно доступными кодовыми точками, действительно более удобен, если вам нужны такие свойства символов, как категории и сопоставления регистров.

Но Widechars неудобно использовать в Linux по той же причине, что UTF-8 неудобно использовать в Windows. GNU libc не имеет функции _wfopen или _wstat.

Answer 3

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

Зачастую программы не заботятся (и фактически не должны заботиться) о том, что ввод, пока не существует \ 0, который может завершить строки.См .:

char buf[whatever];
printf("Your favorite pizza topping is which?\n");
fgets(buf, sizeof(buf), stdin); /* Jalapeños */
printf("%s it shall be.\n", buf);

Единственный раз, когда я обнаружил, что мне нужна поддержка Юникода, это когда мне нужно было иметь многобайтовый символ в качестве единой единицы (wchar_t);например, когда нужно посчитать количество символов в строке, а не байтов.iconv от utf-8 до wchar_t быстро это сделает.Для более крупных проблем, таких как пробелы нулевой ширины и комбинирование диакритических знаков, требуется что-то более тяжелое, например, icu, но как часто вы все равно это делаете?

Answer 4

wchar_t не одинаковый размер на всех платформах. В Windows это кодовая единица UTF-16, которая использует два байта. На других платформах обычно используется 4 байта (для UCS-4 / UTF-32). Поэтому маловероятно, что эти платформы будут стандартизированы при использовании wchar_t, так как это будет тратить много места.