搜索
❏ 站外平台:

对于Windows,GB18030是不可用的

| 2013-04-20 17:46   收藏: 1    

实验分析到这里,结论已经很明显了:在目前正式发行的Windows操作系统,包括微软声称能支持GB18030的Win2k、WinXP和Win2003中,即使安装了GB18030-2000扩展支持包,也不能真正使这些系统支持GB18030编 码标准。

因为道理再简单不过了,程序员根本就没有办法编写出能在这些系统下显示和编辑GB18030-2000四字节编码文本的ANSI文本处理程序。不 是很清楚这些系统是怎么通过GB18030-2000的标准符合性测试的。因为这些产品并不完全符合其中的"体系正确性:产品必须能够正确识别和处理按照 国家标准GB 18030进行编码的文本文件。"这项要求。

而微软提供的GB18030支持包充其量只是提供了一个字体和几个修改过的字符编码转换API函数,以及一个无法使用的CP54936,最后用一个其实跟系统支不支持GB18030标准并没有关系的内码转换小程序就蒙混过关了。

为什么GB18030制定出来已经6年了,却一直没有得到有效的应用?为什么我们大部分的应用程序还只能停留在处理GBK字符集的阶段?为什么当我们很多公民在电脑中录入自己包含生僻字的姓名 时仍然只能用×来代替?

其实这并不怪GB18030-2000的编码技术框架不好,而是相关部门在推广应用该标准上虎头蛇尾的态度造成的。单以编码框架而 言,虽然一直被很多人视为Unicode/ISO10646的中国版(实际上也是)。但技术上还是有它自己独到之处的,即使它的四字节编码框架跟传统的单/双字节ANSI编码相比显得不是那么的标准,但还不至于另类到无法处理的地步。

个人认为它的四字节编码格式跟UTF-16编码格式的代理对机制在处理思想上很有些相似之处,从应用层来说,单独某款软件要识别和处理这种单、双、四字节混合编码并不困难。

但要把这些技术融入到整个操作系统之中,并不是简单地修改几个API就能完成的,单是把Win32 API里面所有有关Ansi字符串处理的函数列出来就够吓人一跳的了。因为微软不可能单为了一个GB18030放弃其他的ANSI编码标准,加入对GB18030的 支持必须是确保兼容原有的代码页机制的前提下才能实施的。而要保证这一点,就必须对几乎所有的字符串处理API进行一定的修改。

总之以当年的情形,微软是 很难在短时间之内拿出完整的解决方案的。政府压得急,微软草草地拿出了个换汤不换药的支持包应付了事,没想到还真通过了。也不知道政府是不是真的不清楚这 个支持包的底细,反正自从这场"GB18030-2000标准之争"以微软推出扩展支持包这个皆大欢喜的体面方式收场之后,双方好像就没把推广应用这回事 放心上了。

几年中就一直任由应用层面上这种不尴不尬的局面持续下来,把一班满心期待迎接GB18030时代却又不明就里的中国应用开发人员撩在了一边。这些人在经过了几次徒劳的尝试之后,终于还是放弃了支持GB18030标准的念头,要么退回到GBK的小窝,要么踏上了Unicode未知的前程。总之在大家看来结论都是一样的:对于Windows,GB18030是不可用的。

最近听说新版的GB18030-2005已经于去年年底制定出来了,虽然尚未有幸一睹标准原文真容,但希望它不会步GB18030-2000的后尘。落 个不尴不尬的局面吧,因然从长远来说主流肯定是Unicode,但短期内仍然还是ANSI和Unicode并存的局面。像GB18030这种本地化版本的Unicode还是需要的。希望它的应用价值不要被再度埋没了。虽然这不是我这种小人物的努力就可以决定的。

via http://blog.csdn.net/jaminwm/article/details/8033805


返回顶部

分享到微信

打开微信,点击顶部的“╋”,
使用“扫一扫”将网页分享至微信。