WinApi когда-либо проверяет UTF-16? - PullRequest
Новая
       16

WinApi когда-либо проверяет UTF-16?

0 голосов
/ 01 сентября 2018

В документации Windows есть многократные ссылки на UNICODE и UTF-16. Я знаю, что это ложь для файловой системы (то есть она принимает любую последовательность wchar_t), а другая документация предполагает, что недействительный UTF-16 просто "неопределен. Так что я" м. сбит с толку. Могу ли я предположить, что API не файловой системы вернут действительный UTF-16? Или я должен предположить, что это не так?

Редактировать: Поскольку это вызывает некоторую путаницу, я объясню несколько терминов

UTF-16

UTF-16 определен в спецификации Unicode (pdf) . FAQ проясняет, что такое UTF-16, а что нет,:

Существуют ли 16-битные значения, которые являются недопустимыми?

Непарные суррогаты недействительны в UTF. Они включают любое значение в диапазоне от D800 16 до DBFF 16 , за которым не следует значение в диапазоне DC00 16 до DFFF 16 , или любое значение в диапазоне DC00 16 до DFFF 16 , которому не предшествует значение в диапазоне D800 16 до DBFF 16 .

А как насчет нехарактерных символов? Они недействительны?

Совсем нет. Номера символов действительны в UTF и должны быть правильно преобразованы. Для получения более подробной информации об определении и использовании нехарактерных символов, а также их правильном представлении в каждом UTF, см. FAQ нехарактерных .

Таким образом, единственное ограничение заключается в том, что за ведущим суррогатом должен следовать завершающий суррогат (он же суррогатная пара). Все остальные значения wchar_t (16 бит) должны приниматься как есть.

UCS-2

Как уже упоминалось в ответе Бена Фойгта. Это устаревшая кодировка, которая допускает любые значения wchar_t. Поскольку он не имеет тех же ограничений, что и UTF-16, подмножество строк UCS-2 является недействительным UTF-16.

1 Ответ

0 голосов
/ 01 сентября 2018

Широкие символы Windows - это произвольные 16-разрядные числа (ранее называвшиеся «UCS-2», до того как консорциум Unicode Standard удалил эту запись). Поэтому вы не можете предполагать, что это будет действительная последовательность UTF-16. (MultiByteToWideChar является заметным исключением, которое возвращает только UTF-16)

Декодирование в UTF-16 имеет смысл только в том случае, если программа, которая сгенерировала строку, использовала соглашение UTF-16, но в этом нет никакой гарантии, так же как нет гарантии, что 8-битные символы содержат UTF-8.

...