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

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

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

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

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

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

wchar_t статье Wikipedia wchar_t кратко затрагивается это.

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

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

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

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

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

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

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

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

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

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, но как часто вы это делаете?

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