Правильно ли это прежде всего?
Да, если вы не предполагаете существование символов, не закодированных в Unicode (для большинства практических приложений это предположение подойдет).
Функции Windows "A" (например, SetWindowTextA) принимают в строках ASCII?Или "многобайтовые строки" (дополнительные вопросы по этому вопросу приведены ниже)?
Они принимают байтовые строки (т. Е. Строки, кодовая единица которых является байтом, который всегда является октетом в Windows), закодированные втекущая кодировка "ANSI" / MBCS / legacy.«ANSI» - это исторические термины для этих кодировок, но не правильные.Для западных систем Windows это обычно кодировка Windows-1252.
Функции "W" Windows принимают строки UTF-16 или UCS-2?Я думал, что они используют UCS-2, но имена меня смущают.
Начиная с Windows 2000, большинство из них поддерживают UTF-16.Название «широкий» и остальная часть терминологии Microsoft (например, «Unicode», означающий «UTF-16» или «UCS») были выбраны до того, как современный стандарт Unicode унифицировал терминологию.
ВWideCharToMultiByte, Microsoft использует слово «строка широких символов» для обозначения UTF-16.В таком контексте, что тогда считается «многобайтовой строкой»?UTF-8?
Любая другая кодировка, поддерживаемая WideCharToMultiByte, в этом контексте является «многобайтовой кодировкой», включая Windows-1251 и UTF-8.
Является ли LPWSTR "строкой широких символов"?Я бы сказал, что это так, но не значит ли это, что это UTF-16?И не значит ли это, что его можно использовать для отображения, скажем, 4-байтовых символов?Если нет, то ... отображение 4-байтовых символов невозможно?(Похоже, в Windows нет API для них.)
LPWSTR - это указатель на wchar_t, который всегда является 16-разрядным целым числом без знака в Windows.Какие символы могут отображаться, не связано с кодировкой, если эта кодировка может кодировать все символы Unicode.Windows обычно может отображать символы, отличные от BMP, но не везде (например, консоль не может).
Является ли функциональность WideCharToMultiByte надмножеством функций wcstombs, и оба они работают натакой же тип строки?Или один, скажем, работает на UTF-16, в то время как другой работает на UCS-2?
Не знаю, но я не думаю, что они сильно отличаются.Я полагаю, вы просто пытаетесь преобразовать не-BMP символ в UTF-8 и посмотрите, верен ли результат.
Являются ли пути к файлам в UTF-16 или UCS-2?Я знаю, что Windows рассматривает его как «непрозрачный массив символов» из документации Microsoft, но согласно стандарту C для таких функций, как fwprintf, существует ли какая-либо стандартизированная кодировка?
Пути к файлам действительно являются непрозрачными массивами UTF-16 символов, что означает, что Windows не выполняет никакого перевода при сохранении или чтении имен файлов (например, Linux и в отличие от Mac OS X).Но Windows по-прежнему имеет свое странное, в основном неопределенное, нечувствительное к регистру поведение, которое вызывает много проблем, потому что имена файлов, которые рассматриваются как эквивалентные, не обязательно равны.Это ломает много инвариантов;например, в Linux без вмешательства других потоков, если вы успешно создадите два файла A и a в некотором каталоге, вы получите два отдельных файла, в то время как в Windows вы получите только один файл (и вообще, непредсказуемое количество файлов).
Что такое кодировка "ANSI"?Это даже правильный термин?И как это связано с ASCII?
ANSI - американская организация по стандартизации.Использование этого слова при обращении к кодировкам является неправильным, но часто встречающимся, поэтому вы должны знать об этом.Я предпочитаю термин устаревшая 8-битная кодировка , потому что я думаю, что это, по сути, то, что это такое: кодировка не-Unicode, которая сохраняется только для совместимости с устаревшими (Windows 9x) приложениями.В западных системах это обычно Windows-1252, который является надлежащим расширенным набором ASCII.