|
问题描述：
在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字符串，第二列是区域为中文的正常情况下转换出的字符
串，第三列是英文环境下转换出的字符串，字符串是"管理员"三个字：
汉字 ansi RPC EN
管 b9dc 7ba1 00b9 00dc
理 c0ed 7406 00c0 00ed
员 d4b1 5458 00d4 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 |
简单吧？
|
本类阅读TOP10