Win32 API
Funkcje Ansi i Szeroki znak
Szukaj…
Wprowadzenie
Dokumentacja interfejsu API systemu Windows dla funkcji pobierających jeden lub więcej ciągów jako argument zwykle będzie wyglądać następująco:
BOOL WINAPI CopyFile(
_In_ LPCTSTR lpExistingFileName,
_In_ LPCTSTR lpNewFileName,
_In_ BOOL bFailIfExists
);
Typ danych dla dwóch parametrów ciągu składa się z kilku części:
- LP = Długi wskaźnik
- C = const
- T = TCHAR
- STR = ciąg
Co teraz oznacza TCHAR
? Zależy to od platformy wybranej do kompilacji programu.
Sam CopyFile
jest tylko makrem, zdefiniowanym mniej więcej tak:
#ifdef UNICODE
#define CopyFile CopyFileW
#else
#define CopyFile CopyFileA
#endif
Tak więc w rzeczywistości istnieją dwie funkcje CopyFile
i w zależności od flag kompilatora makro CopyFile
rozpoznaje jedno lub drugie.
Istnieje token podstawowy, TCHAR
jest zdefiniowany jako:
#ifdef _UNICODE
typedef wchar_t TCHAR;
#else
typedef char TCHAR;
#endif
Zatem ponownie, w zależności od flag kompilacji, TCHAR jest znakiem „wąskim” lub „szerokim” (2 bajty).
Tak więc, gdy zdefiniowany jest UNICODE, CopyFile
jest zdefiniowany jako CopyFileW
, który użyje 2-bajtowych tablic znaków jako parametru, które mają być zakodowane w UTF-16.
Jeśli UNICODE nie jest zdefiniowany, CopyFile
jest zdefiniowany jako CopyFileA
który wykorzystuje jednobajtowe tablice znaków, które powinny być zakodowane w domyślnym kodowaniu ANSI bieżącego użytkownika.
Istnieją dwa podobne makra: UNICODE
sprawia, że interfejsy API systemu Windows oczekują szerokich ciągów znaków i _UNICODE
(z wiodącym podkreśleniem), który umożliwia podobne funkcje w bibliotece wykonawczej C.
Te definicje pozwalają nam pisać kod, który kompiluje się zarówno w trybie ANSI, jak i w trybie Unicode.
Ważne jest, aby wiedzieć, że kodowanie ANSI może być kodowaniem jednobajtowym (tj. Latin-1) kodowaniem wielobajtowym (tj. Shift jis), chociaż utf-8 nie jest niestety dobrze obsługiwany.
Oznacza to, że ani ANSI, ani wariant tych funkcji o szerokich znakach nie mogą działać z kodowaniem o stałej szerokości.