Win32 API
Ansi- och bredkaraktärsfunktioner

Introduktion

Windows API-dokumentationen för funktioner som tar en eller flera strängar som argument kommer vanligtvis att se ut så här:

BOOL WINAPI CopyFile(
  _In_ LPCTSTR lpExistingFileName,
  _In_ LPCTSTR lpNewFileName,
  _In_ BOOL    bFailIfExists
);

Datatypen för de två strängparametrarna består av flera delar:

• LP = Lång pekare
• C = konst
• T = TCHAR
• STR = sträng

Vad betyder TCHAR ? Detta beror på vilken plattform som valts för sammanställning av program.

CopyFile sig är bara ett makro, definierat något liknande:

#ifdef UNICODE
#define CopyFile CopyFileW
#else
#define CopyFile CopyFileA
#endif

Så det finns faktiskt två CopyFile funktioner och beroende på kompilatorflaggor kommer CopyFile att lösa till det ena eller det andra.

I det här TCHAR definieras TCHAR som:

#ifdef _UNICODE
typedef wchar_t TCHAR;
#else
typedef char TCHAR;
#endif

Så igen, beroende på kompilera flaggorna, är TCHAR ett "smalt" eller "brett" (2 byte) tecken.

Så när UNICODE är definierat definieras CopyFile till CopyFileW , som kommer att använda 2-byte-teckenuppsättningar som deras parameter, som förväntas vara UTF-16-kodad.

Om Unicode inte är definierad, CopyFile definieras att vara CopyFileA som använder enkelbyteteckenuppsättningar som förväntas som skall kodas i standard ANSI kodningen av den aktuella användaren.

Det finns två liknande makron: UNICODE gör att Windows API: er förväntar sig breda strängar och _UNICODE (med en ledande understruk) som möjliggör liknande funktioner i C-runtime-biblioteket.

Dessa definierar tillåter oss att skriva kod som sammanställs i både ANSI och i Unicode-läge.

Det är viktigt att veta att ANSI-kodningen kan vara en enkel-byte-kodning (dvs latin-1), en multi-byte-kodning (dvs shift jis), även om utf-8 tyvärr inte stöds väl.

Detta innebär att varken ANSI eller variant av dessa funktioner kan antas fungera med fast breddskodning.