Ответ 1
Правильны ли они выше?
Да, если вы не предполагаете существование символов, не закодированных в Юникоде (для большинства практических приложений это предположение в порядке).
Используют ли функции Windows "A" (например, SetWindowTextA) строки ASCII? Или "многобайтовые строки" (подробнее об этом ниже)?
Они берут байтовые строки (т.е. строки, чей код является байтом, который всегда является октетом в Windows), закодированным в текущей кодировке ANSI/MBCS/legacy. "ANSI" - это исторический термин для этих кодировок, но не правильный. Для западных систем Windows эта кодировка обычно является Windows-1252.
Используют ли функции Windows "W" строки UTF-16 или строки UCS-2? Я думал, что они принимают в UCS-2, но имена путают меня.
Начиная с Windows 2000, большинство из них поддерживают UTF-16. Название "широкая" и остальная терминология Microsoft (например, "Юникод", означающее "UTF-16" или "UCS" ), были выбраны до того, как современный стандарт Unicode объединит терминологию.
В WideCharToMultiByte Microsoft использует слово "широкосимвольная строка" для обозначения UTF-16. В этом контексте то, что считается "многобайтовой строкой"? UTF-8?
Каждая другая кодировка, поддерживаемая WideCharToMultiByte, представляет собой "многобайтовую кодировку" в этом контексте, включая Windows-1251 и UTF-8.
Является ли LPWSTR "широкосимвольной строкой"? Я бы сказал, что это так, но тогда это не означает, что это UTF-16? И разве это не означает, что его можно использовать для отображения, скажем, четырехбайтовых символов? Если нет, то... отображает 4-байтовые символы невозможным? (У Windows, похоже, нет API-интерфейсов для них.)
LPWSTR является указателем на wchar_t, который всегда является 16-разрядным целым без знака в Windows. Какие символы могут отображаться, не связаны с кодировкой, если эта кодировка может кодировать все символы Юникода. 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 по-прежнему имеет свое странное, главным образом - undefined поведение, нечувствительное к регистру, которое вызывает много проблем, поскольку имена файлов, которые обрабатываются эквивалентными, не обязательно равны. Это нарушает многие инварианты; например, в Linux без помех от других потоков, если вы успешно создадите два файла A и A в каком-то каталоге, вы получите два разных файла, в то время как в Windows вы получите только один файл (и вообще, непредсказуемое количество файлов).
Что такое кодировка "ANSI"? Это даже правильный термин? И как это связано с ASCII?
ANSI - американская организация стандартизации. Использование этого слова при обращении к кодировкам является неправильным, но частым, поэтому вы должны знать об этом. Я предпочитаю термин 8-битное кодирование, потому что я думаю, что это, по сути, то, что это такое: кодировка, отличная от Юникода, которая поддерживается только для совместимости с устаревшими (Windows 9x) приложениями. В западных системах это обычно Windows-1252, который является надлежащим надмножеством ASCII.