This article was previously published under Q108450
MultiByteToWideChar() maps a character string to a wide-character string.The declaration of this application programming interface (API) is asfollows:
int MultiByteToWideChar(uCodePage, dwFlags, lpMultiByteStr, cchMultiByte, lpWideCharStr, cchWideChar) UINT uCodePage; /* codepage */ DWORD dwFlags; /* character-type options */ LPCSTR lpMultiByteStr; /* address of string to map */ int cchMultiByte; /* number of characters in string */ LPWSTR lpWideCharStr; /* address of wide-character buffer */ int cchWideChar; /* size of wide-character buffer */
The first parameter, uCodePage, specifies the codepage to be used whenperforming the conversion. This discussion applies to the first parameterof WideCharToMultiByte() as well. The codepage can be any valid codepagenumber. It is a good idea to check this number with IsValidCodepage(), eventhough MultiByteToWideChar() returns an error if an invalid codepage isused. The codepage may also be one of the following values:
CP_ACP instructs the API to use the currently set default Windows ANSIcodepage. CP_OEMCP instructs the API to use the currently set default OEMcodepage.
If Win32 ANSI APIs are used to get filenames from a Windows NT system, useCP_ACP when converting the string. Windows NT retrieves the name from thephysical device and translates the OEM name into Unicode. The Unicode nameis translated into ANSI if an ANSI API is called, then it can be translatedback into Unicode with MultiByteToWideChar().
If filenames are being retrieved from a file that is OEM encoded, useCP_OEMCP instead.
When an application calls an ANSI function, the FAT/HPFS file systems willcall AnsiToOem(); however, if an ANSI character does not exist in an OEMcodepage, the filename will not be representable. In these cases,SetFileApisToOEM() should be called to prevent this problem by setting agroup of the Win32 APIs to use the OEM codepage instead of the ANSIcodepage.