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

Question

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

То есть:

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

Так, что делает Windows, когда вы хотите закодировать что-то вроде символа ? (U + 2008A) Han в Windows?

Answer 1

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

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

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

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

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

Answer 2

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

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

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