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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

Ответ 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);

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

Ответ 4

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

Ответ 5

Основная библиотека libc на Linux, glibc только получила полную поддержку Unicode (в основном, версию без ошибок), в ее выпуске 2.3.3 и которая была в 2004 году.