windows中UTF编码与ANSI编码以及MultiByteToWideChar的使用

ANSI编码： 不同国家和地区代表不同的编码标准，在中文简体环境下表示 GBK，对应的代码页为_CHINESE_SIMP_CP（936）.，日文操作系统中ANSI代表Shift_JIS编码。

使用::MultiByteToWideChar（CodePage, dwFlags, src, nSrcLen, dst, nDstLen）时，注意， src的编码格式必须与codePage所表示的含义一致。
如：中文简体系统下，将char*（所指内容为ANSI编码）转为 wchar时，CodePage的值需为：_CHINESE_SIMP_CP，或者CP_ACP（系统默认值，此时表示的就为_CHINESE_SIMP_CP）
若 char* 所指的内容为utf-8编码，使用MultiByteToWideChar时，CodePage的值需为 CP_UTF8，若还设置为CP_ACP或者936，将会产生乱码。
一般情况下，ANSI编码的char*无法直接转为utf-8编码的char*，原因在于ANSI和utf-8本身都为mulitbyte的，windows中没有multibyteTomultibyte的接口。通常会使用宽字符wchar作为中间纽带，即：

ANSI---->WCHAR--->utf-8

utf--->WCHAR----->ANSI

使用参数CP_ACP的时候一定需要明白当前系统缺省的转换页码时多少。windows最新的win10系统中有如下一个设置，若勾选此选项，系统默认的codepage为CP_UTF8，此时使用MultiByteToWideChar时需要额外注意了，若申请了ANSI的char*，则需要明确使用936，而不是CP_ACP，有一些crt函数的使用也需要注意，如strftime(char*
const string, size_t const max_size, char* const* const format, tm const* const timeptr)，第三个参数format必须是UTF-8格式编码的，因为此函数中会调用了MultiByteToWideChar，且第一个参数为0，可以理解为CP_ACP，若还是直接传入ANSI，则会导致得不到想要的结果。
这可能是新版windows系统和原有进程中crt的一个兼容问题。
不过对于静态加载CRT的进程来说，可以通过setlocale()函数来设置当前进程中crt中所使用的代码页，一定程度上可以避免这个问题。