WinAPI Unicode и ANSI функции

Question

Большинство WinAPI вызовов имеют Unicode и ANSI вызов функции

Для examble:

function MessageBoxA(hWnd: HWND; lpText, lpCaption: LPCSTR; uType: UINT): Integer; stdcall;external user32; 

function MessageBoxW(hWnd: HWND; lpText, lpCaption: LPCWSTR; uType: UINT): Integer; stdcall; external user32; 

Когда я должен использовать функцию ANSI вместо вызова функции Unicode?

Answer 1

Проще всего следовать этому. Используйте только варианты ANSI для систем, не имеющих варианта Unicode. Это в Windows 95, 98 и ME, которые являются версиями Windows, которые реализуют Win32 и не поддерживают Unicode.

В настоящее время крайне маловероятно, что вы будете ориентироваться на такие версии, и поэтому, по всей вероятности, вы всегда должны использовать варианты Unicode.

Answer 2

Подобно тому, как (редкие) исключения посланных комментариев/ответы ...

Можно выбрать использовать ANSI звонков в тех случаях, когда UTF-8, как ожидается, и поддерживается. Например, WriteConsoleA'ing строки UTF-8 в консоли, установленной для использования шрифта TT и работающего под chcp 65001.

Еще одним исключением является функция, которая в основном реализована как ANSI, где вариант Unicode «W» просто преобразуется в узкую строку в активной кодовой странице и вызывает аналог «A». Для такой функции, и когда доступна узкая строка, вызов варианта «А» напрямую сохраняет избыточное двойное преобразование. Дело в том, что это OutputDebugString, который попал в эту категорию до Windows 10 (я только заметил https://msdn.microsoft.com/en-us/library/windows/desktop/aa363362.aspx, в котором упоминается, что вызов WaitForDebugEventEx - доступный только с Windows 10 - включает в себя истинный выход Unicode для OutputDebugStringW).

Тогда есть API, которые, хотя и имеют дело со строками, являются ANSI. Например, GetProcAddress существует только в варианте ANSI, который принимает аргумент LPCSTR, поскольку имена в таблицах экспорта являются узкими строками.

Это говорит о том, что большинство API-интерфейсов, основанных на строках, являются в основном Unicode, и рекомендуется использовать варианты «W». Не все новые API даже имеют вариант «А» больше (например, CommandLineToArgvW). Из уст лошадей https://msdn.microsoft.com/en-us/library/windows/desktop/ff381407.aspx:

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

[...] Когда Microsoft была введена поддержка Unicode в Windows, она облегчила переход, предоставляя два параллельных набор API-интерфейсов, один для строк ANSI, а другие для строк Unicode.

[...] Внутренне версия ANSI переводит строку в Unicode. Заголовки Windows также определяют макрос, который разрешает версию Unicode, когда обозначен символ препроцессора UNICODE или версия ANSI.

[...] Большинство новых API, в Windows, есть только версии Unicode, без соответствующего ANSI-версии.

[Примечание]  Сообщение было отредактировано, чтобы добавить два последних абзаца.