系统区域为非中文(比如英文)的情况下，执行MultiByteToWideChar失败

问题描述： 　　 在wince下，中文字体和环境都设置好，但是系统区域为非中文(比如英文)的情况下，执行MultiByteToWideChar失败 　　解决过程： 　　 首先是之前使用的方法： 　　UINT WChar2Char(LPCWSTR pwszSrc, LPSTR pszDst) 　　{ 　　 return WideCharToMultiByte( CP_ACP, 0, pwszSrc, -1, pszDst, MAX_PATH, NULL, NULL ); 　　} 　　UINT Char2WChar(LPCSTR pszSrc, LPWSTR pwszDst) 　　{ 　　 return MultiByteToWideChar( CP_ACP, 0, pszSrc, -1, pwszDst, MAX_PATH ); 　　} 　　在描述中的环境下执行Char2WChar并不是总是失败，内置字符转换就没有问题，比如: 　　char s[10] = "测试"; 　　TCHAR ws[10]; 　　Char2WChar(s, ws); 　　估计是因为在evc编译的时候已经将char转换为unicode，或者是由于编译的时候codepage已经为936，具体的原因需要调试，有兴趣的可以自己做实验 　　失败的情况是从数据库中读取一段字串，并进行转换，此时必定错误。由于此时从数据库中读取的是真正的ansi，所以和上面所说的情况不一样。此时 　　debug一下Char2WChar会发现转换失败。下面是用evc跟踪的结果，第一列是ansi字符串，第二列是区域为中文的正常情况下转换出的字符 　　串，第三列是英文环境下转换出的字符串，字符串是"管理员"三个字： 　　汉字ansiRPCEN 　　管b9dc7ba100b9 00dc 　　理c0ed740600c0 00ed 　　员d4b1545800d4 00b1 　　可以看到，最后一种情况下转换的结果只是做了一些简单的变换，并没有转出来，原因是什么呢，主要是WideCharToMultiByte的第一个参数 　　codepage造成的，如前面所使用的CP_ACP所表达的意思是使用系统字符集转换，但是由于此时的系统字符集为英文，在这个codepage中并没 　　有中文，所以转换出错，那么最后的答案就很简单了： 　　UINT WChar2Char(LPCWSTR pwszSrc, LPSTR pszDst) 　　{ 　　return WideCharToMultiByte(936, 0, pwszSrc, -1, pszDst, MAX_PATH, NULL, NULL); 　　} 　　UINT Char2WChar(LPCSTR pszSrc, LPWSTR pwszDst) 　　{ 　　return MultiByteToWideChar(936, 0, pszSrc, -1, pwszDst, MAX_PATH); 　　} 　　最后再看看codepage的定义： 　　 　　定义 　　描述 　　 　　874 　　Thai 　　 　　932 　　Japan 　　 　　936 　　Chinese (PRC, Singapore) 　　 　　949 　　Korean 　　 　　950 　　Chinese (Taiwan; Hong Kong SAR, PRC) 　　 　　1200 　　Unicode (BMP of ISO 10646) 　　 　　1250 　　Windows 3.1 Eastern European 　　 　　1251 　　Windows 3.1 Cyrillic 　　 　　1252 　　Windows 3.1 Latin 1 (US, Western Europe) 　　 　　1253 　　Windows 3.1 Greek 　　 　　1254 　　Windows 3.1 Turkish 　　 　　1255 　　Hebrew 　　 　　1256 　　Arabic 　　 　　1257 　　Baltic