|
问题描述: 在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 |
简单吧?
|