Как windows wchar_t обрабатывает символы Unicode вне базовой многоязычной плоскости?

Я просмотрел ряд других сообщений здесь и в другом месте (см. ниже), но у меня все еще нет четкого ответа на этот вопрос: как windows wchar_t обрабатывает символы Unicode вне базовой многоязычной плоскости?

То есть:

многие программисты чувствуют, что UTF-16 вреден, потому что это код переменной длины.
wchar_t имеет ширину 16 бит в окнах, но 32-битный бит в Unix/MacOS
В API Windows используются широкоформатные символы, а не Юникод.

Итак, что делает Windows, когда вы хотите кодировать что-то вроде 𠂊 (U + 2008A) Han Character в Windows?

Ответ 1

Реализация wchar_t под Windows stdlib - это UTF-16-забывая: он знает только о 16-разрядных кодовых модулях.

Таким образом, вы можете поместить суррогатную последовательность UTF-16 в строку, и вы можете рассматривать ее как отдельный символ, используя обработку более высокого уровня. Реализация строки не будет делать ничего, чтобы помочь вам и не помешать вам; он позволит вам включить любую последовательность блоков кода в вашу строку, даже те, которые были бы недействительны при интерпретации UTF-16.

Многие из высокоуровневых функций Windows поддерживают символы, созданные из суррогатов UTF-16, поэтому вы можете вызвать файл 𐐀.txt и увидеть, как он корректно отобразится и правильно отредактирован (с помощью одного нажатия клавиши, а не два, чтобы перейти от персонажа) в программах, таких как "Проводник", которые поддерживают сложный текстовый макет (как правило, с использованием библиотеки Windows Uniscribe).

Но есть еще места, где вы можете видеть проглядывание UTF-16, например, тот факт, что вы можете создать файл с именем 𐐀.txt в той же папке, что и 𐐨.txt, где нечувствительность к регистру в противном случае запретила бы это или тот факт, что вы можете программно создать [U+DC01][U+D801].txt.

Вот как педанты могут иметь хороший длинный и в основном бессмысленный аргумент о том, поддерживает ли Windows "строки UTF-16 или только UCS-2".

Ответ 2

Windows использовала UCS-2, но приняла UTF-16 с Windows 2000. Теперь API wchar_t Windows теперь производит и потребляет UTF-16.

Не все сторонние программы обрабатывают это правильно и поэтому могут быть ошибочными с данными вне BMP.

Также обратите внимание, что UTF-16, являющийся кодировкой с переменной длиной, не соответствует требованиям C или С++ для кодировки, используемой с wchar_t. Это вызывает некоторые проблемы, такие как некоторые стандартные функции, которые принимают один wchar_t, например wctomb, не могут обрабатывать символы за пределами BMP в Windows и Windows, определяющие некоторые дополнительные функции, которые используют более широкий тип, чтобы иметь возможность обрабатывать одиночные символы вне БМП. Я забыл, какая функция была, но я столкнулся с функцией Windows, которая вернула int вместо wchar_t (и это был не тот случай, когда EOF был возможным результатом).