WideCharToMultiByte的CP_ACP和CP_OEMCP疑问

herostarone 2010-07-19 04:52:42
DWORD dwNum = WideCharToMultiByte(CP_OEMCP,NULL,(LPWSTR)szData,-1,NULL,0,NULL,FALSE);
char *psText;
psText = new char[dwNum];
WideCharToMultiByte (CP_OEMCP,NULL,(LPWSTR)szData,-1,psText,dwNum,NULL,FALSE);


DWORD dwNum = MultiByteToWideChar (CP_ACP, 0, strKeyName.c_str(), -1, NULL, 0);
wchar_t *pwText = new wchar_t[dwNum];
MultiByteToWideChar (CP_ACP, 0, strKeyName.c_str(), (int)strKeyName.size()+1, pwText, dwNum);
CP_OEMCP与CP_ACP有什么区别啊

网上搜了点解释:
CP_ACP 指示 API 使用当前设置默认的 Windows ANSI 代码页。CP_OEMCP 指示要使用当前设置 API 默认 OEM 代码页。

当将字符串转换时,如果 Win32 ANSI api 用于从一个 Windows NT 系统中获取文件名,请使用 CP_ACP。Windows NT 检索从物理设备的名称,并将 OEM 名称转换为 Unicode。Unicode 名被转换成 ANSI 如果称为 ANSI API,再转换回 MultiByteToWideChar() 与 Unicode。

如果正在从 OEM 编码的文件中检索文件名,改用 CP_OEMCP。
但是不明白啊

WideCharToMultiByte完成后是char *psText;而MultiByteToWideChar完成后是wchar_t ;CP_ACP不是转换成ASCI吗,有点矛盾啊
...全文
1868 6 打赏 收藏 转发到动态 举报
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
ligand 2013-01-23
  • 打赏
  • 举报
回复
很简单。我编了小程序做了实验。 CP_ACP和CP_OEMCP,分别是指当前计算机操作系统的Windows代码页与OEM代码页。对于东亚的简体中文、繁体中文、日文、韩文等Win操作系统语言环境,这两种代码页是同一个,如简体中文是代码页936即GB2312字符集,繁体中文是950即大五码字符集,韩文是949、日文是932。对于西方国家的拼音文字语言设置,两个代码页不同。典型的如English_US,其Windows代码页是1252、OEM代码页是437,还有第三个代码页ISO-8859-1又称Latin-1或“西欧语言”,是针对英语法语西语德语等西欧语言的扩展ASCII字符集。这三者(1252、437、8859-1)都是针对英语但并不相同。 为什么会有Windows代码页与OEM代码页的区别呢?因为在八十年代DOS系统时期,还是“字符终端”的屏幕只能够显示的256个字符,这些字符的字形的点阵信息存储在硬件的ROM中。DOS操作系统通过系统中断调用驱动程序把这些字形读出来写入显存。这是由OEM负责字符集中有哪些字符,显示时为什么字形的时代,而且一台PC上只有这么一套字符集/字形,没得选,除非你再差一个带字库的“汉卡”。进入了微软的Windows操作系统时代之后,由于硬件的发展,操作系统有了自己的字形文件,绘制字符时不再真地去读ROM,而是用字形文件(就是字体fonts文件)来把字符的形状写入显存。可以选择用哪种字形:如有衬线的Times NewRome,还是无衬线的Sans Serif。操作系统默认使用的字符集,就由微软来定义了,如English_US使用Codepage1252;简体中文使用Codepage936(即国标2312). 至于那个OEM436,就是legacy,用于向后兼容。 综上,就这么点事。CP_ACP和CP_OEMCP,分别是UINT的0和1。在WinNls.h中的注释说明分别是“default to ANSI code page”,“default to OEM code page”。所以,在简体中文Windows,这两个宏表示的都是代码页936. 下述程序代码片段用于测试 UINT codepage=936; char str[]="我们中国"; //这个char[]必然是多字节编码字符串 DWORD len; // 得到我们要转换的MyString为UNICODE所需要的UNICODE缓冲区的长度 len = MultiByteToWideChar(codepage, 0, str, -1, 0, 0); wchar_t *buf=new wchar_t[len+10]; MultiByteToWideChar(codepage, 0, str, -1, buf, len); setlocale(LC_CTYPE,"");//把当前locale字符环境从C/C++缺省的"C"设置,改为操作系统的设置(即代码页936) wprintf(L"%s",buf); //因为这个C标准库函数的实现,是把宽字符输入又转化为多字节字符去显示,所以必须正确设置当前操作系统的多字节编码的代码页 结果: 1. 输入是char str[]="我们中国"; UINT codepage=936或者54936(这是GB18030代码页)或者CP_ACP或者CP_OEMCP,都能正确打印出结果“我们中国”。 2. 输入是char str[]="иい瓣"; UINT codepage=950; 也能正确把上述大五码字符串打印出宽字符串输出结果“我们中国”。 3. 输入是char str[]="鎴戜滑涓浗 "; UINT codepage=65001; 也能正确把上述UTF-8字符串打印出宽字符串输出结果“我们中国”。 附录: 一个在线GB/BIG5/UTF-8/UNICODE转码的网站http://www.dheart.net/bmzh/index.php
DU20120412DU 2012-08-31
  • 打赏
  • 举报
回复
确实蛮深奥的
jxcyly1985 2010-11-26
  • 打赏
  • 举报
回复
DWORD dwNum = MultiByteToWideChar (CP_ACP, 0, strKeyName.c_str(), -1, NULL, 0); 应该是说你的multibyte是cp_acp的编码 最后生成wchar_t应该是Unicode的字符字符码
xmy4660793 2010-07-19
  • 打赏
  • 举报
回复
帮顶啊,虽然看不懂,呵呵
BlueMap 2010-07-19
  • 打赏
  • 举报
回复
帮顶。。。
饭fan有引力 2010-07-19
  • 打赏
  • 举报
回复
友情帮顶

16,472

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧