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

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

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

12
c unicode wchar-t

4 ответов

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

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

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

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

15

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

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

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

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

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

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

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

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

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

9

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, Так как это будет тратить много места.

1