有多少个无法转成ANSI的UNICODE字符

kenshu 2017-01-15 04:30:19
有一个程序是按ANSIC编码来写的。如果见到UNICODE的字符,就先转为ANSIC字符来显示。

现在的问题是,遇到了无法转为 unicode的字符。

如 COPYRIGHT的符号 (圈里面有个C,这里发贴也不能用)

把它在记事本中输入,也无法保存为ansi编码的文件。

我想知道,总共有多少个类似的字符?它们的取值范围是多少?

谢谢!
...全文
993 25 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
25 条回复
切换为时间正序
请发表友善的回复…
发表回复
kenshu 2017-02-23
  • 打赏
  • 举报
回复
引用 24 楼 zhujinqiang 的回复:
楼主后来解决问题了吧
最终的方法是 a(unicode) -> b(ansi) -> c(unicode) 如果 a != c,就是出错。 这样做最保险,当然CPU时间也上去了。 因为 如23楼所述,WideCharToMultiByte 可能在出错时,返回值和参数都显示正确。
zhujinqiang 2017-02-20
  • 打赏
  • 举报
回复
楼主后来解决问题了吧
kenshu 2017-02-13
  • 打赏
  • 举报
回复
引用 18 楼 zhujinqiang 的回复:
ANSI编码表本来就很小啦 转换失败就按照 WideCharToMultiByte 的最后一个参数做异常处理就好了。
我最终用了您的方法。并且花了两个星期左右来修改并兼容程序。 但实际上还是不对。 繁体中文操作系统下, ©,会被转换为 c 并且最后一个参数返回是正确的。 (简体中文下返回错误) 看来又要花多几个星期来改了。
赵4老师 2017-01-23
  • 打赏
  • 举报
回复
//GBK汉字内码范围(不包括A1xx~A9xx的标点符号英文字母特殊符号等) //区码 ,位码 //81-A0 ,40-7E 80-FE //AA-AF ,40-7E 80-A0 //B0-D6 ,40-7E 80-FE //D7 ,40-7E 80-F9 //D8-F7 ,40-7E 80-FE //F8-FE ,40-7E 80-A0
zhujinqiang 2017-01-22
  • 打赏
  • 举报
回复
ANSI编码表本来就很小啦 转换失败就按照 WideCharToMultiByte 的最后一个参数做异常处理就好了。
zwfgdlc 2017-01-22
  • 打赏
  • 举报
回复
引用 17 楼 kenshu 的回复:
[quote=引用 15 楼 zwfgdlc 的回复:] 事实上你只要判断MultiByteToWideChar执行有没失败就行了
试了,这个方法不行,比如 Copyright: © 2001-2017 转出来返回值是成功的,但它转成 Copyright: ? 2001-2017 ---------------------------------- 所以,我现在的方案是, 1.A/*UNICODE*/ -> B/*ANSI*/ -> C/*UNICODE*/ 如果A != C ,就证明转换有问题,转其它方法。 不过运行时的计算量会大很多。因为本来转一次的东西,要转两次再比较。 2.穷举所有奇怪的字符。 不过运行时计算量也不会少到哪去。 [/quote] 上代码看看
schlafenhamster 2017-01-22
  • 打赏
  • 举报
回复
“”GBK 亦采用双字节表示,总体编码范围为 8140-FEFE,首字节在 81-FE 之间,尾字节在 40-FE 之间,剔除 xx7F 一条线。“”
kenshu 2017-01-21
  • 打赏
  • 举报
回复
引用 15 楼 zwfgdlc 的回复:
事实上你只要判断MultiByteToWideChar执行有没失败就行了
试了,这个方法不行,比如 Copyright: © 2001-2017 转出来返回值是成功的,但它转成 Copyright: ? 2001-2017 ---------------------------------- 所以,我现在的方案是, 1.A/*UNICODE*/ -> B/*ANSI*/ -> C/*UNICODE*/ 如果A != C ,就证明转换有问题,转其它方法。 不过运行时的计算量会大很多。因为本来转一次的东西,要转两次再比较。 2.穷举所有奇怪的字符。 不过运行时计算量也不会少到哪去。
kenshu 2017-01-21
  • 打赏
  • 举报
回复
引用 14 楼 schlafenhamster 的回复:
留意我的"額"字是繁体字的,不是简体字的。 当然它也是GB码,不是BIG5码的. 这个字不是后来出的,简体win98下就打得出来。
zwfgdlc 2017-01-21
  • 打赏
  • 举报
回复
事实上你只要判断MultiByteToWideChar执行有没失败就行了
schlafenhamster 2017-01-21
  • 打赏
  • 举报
回复
kenshu 2017-01-21
  • 打赏
  • 举报
回复
当时,汉字的这个问题,我也是没办法,穷举所有例外的情况来单独处理。
kenshu 2017-01-21
  • 打赏
  • 举报
回复
引用 11 楼 schlafenhamster 的回复:
"那个©的符号就是ASCII码的(0xA900)" 不是吧?ASCII码 从 00 到 FF,单字节。 汉字必须 》0x80,0x80 而 0xA900 不会是汉字
我问的是,“有多少个无法转成ANSI的UNICODE字符”,他说,“除了ascii码表的所有字符”,但实际上那个字的ASCII编码是 "A9",UNICODE 是"a900". 另外,您说的“汉字必须 0x80,0x80”,很久以前我也这样认为,我们都是从书里看到的。 写那本书的人不负责任(或也许是后来改进了)。 所以很久以前,我想当然地按这样的组合来判断汉字。 但其实不对。 "額"是0xEE7E (还有另外几个汉字也是这样) 汉字编码这个问题,也花了我可能有一个星期来处理。
schlafenhamster 2017-01-21
  • 打赏
  • 举报
回复
"那个©的符号就是ASCII码的(0xA900)" 不是吧?ASCII码 从 00 到 FF,单字节。 汉字必须 》0x80,0x80 而 0xA900 不会是汉字
kenshu 2017-01-21
  • 打赏
  • 举报
回复
引用 4 楼 VisualEleven 的回复:
Unicode编码的字符很多啊~比如中文汉字,日文。。。
引用 5 楼 zzz3265 的回复:
你的问题缺条件, UNICODE包括世界很多语言, multi-byte 一般是单一的一种语言, 其他语言肯定是没法转换过来的 转换失败是可以检测到的 WideCharToMultiByte 的最后一个参数, 你可以自己写个循环代码去测试有多少转换失败的 另外就算转换成功, 如果字体不支持也会导致无法显示
引用 7 楼 oyljerry 的回复:
主要是需要知道字符的编码格式,然后才好对应的进行编码解码
上面三个一起回复。 实际上,这个程序,在不同的语言下,比如简体,繁体,日文,阿拉伯文等下面长期运行是没有问题的。 需要处理的文本,按当前操作系统默认页来转换。 因为日文下,它需要处理的也都是日文。所以正常的文本,不存在上面两楼说的问题。 因为历史原因,(这个程序是2001年开始写的),当时的需求还不需要考虑到UNICODE,而且经验上不够,没有前瞻性,所以就没有考虑UNICODE的问题。 后来加了UNICODE的转换,也都没有问题。 可是整个程序的架构是ANSI编码的,而且已经太大了,没办法整个程序重新转换也UNICODE的结构。 这个工作量太大,而且没办法控制BUG的规模。
引用 6 楼 shiyanzi 的回复:
转换失败做标识
这个我们正在考虑有没有办法做。
引用 8 楼 akirya 的回复:
写个程序挨个转换一下 ™©®
我当时想最简单的办法,应该就是这样。 所以我才需要穷举出各种可能,就像您列出来的这样。不过您这三个应该是不够的。
引用 9 楼 an_bachelor 的回复:
除了ascii码表的所有字符
不是这样的,那个©的符号就是ASCII码的(0xA900)
an_bachelor 2017-01-21
  • 打赏
  • 举报
回复
除了ascii码表的所有字符
  • 打赏
  • 举报
回复
转换失败做标识
Yofoo 2017-01-17
  • 打赏
  • 举报
回复
你的问题缺条件, UNICODE包括世界很多语言, multi-byte 一般是单一的一种语言, 其他语言肯定是没法转换过来的 转换失败是可以检测到的 WideCharToMultiByte 的最后一个参数, 你可以自己写个循环代码去测试有多少转换失败的 另外就算转换成功, 如果字体不支持也会导致无法显示
Eleven 2017-01-17
  • 打赏
  • 举报
回复
Unicode编码的字符很多啊~比如中文汉字,日文。。。
加载更多回复(5)

16,548

社区成员

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

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

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