• 正在加载中...
  • dbcs

    DBCS,最初的128个代码是ASCII,较高的128个代码中的某些总是跟随著第二个位元组。这两个位元组一起(称作首位元组和跟随位元组)定义一个字元,通常是一个复杂的象形文字。

    编辑摘要

    目录

    简介/dbcs 编辑

      DBCS:double-byte character set

      最初的128个代码是ASCII,较高的128个代码中的某些总是跟随著第二个位元组。这两个位元组一起(称作首位元组和跟随位元组)定义一个字元,通常是一个复杂的象形文字。

      虽然中文、日文和韩文共用一些相同的象形文字,但显然这三种语言是不同的,而且经常是同一个象形文字在三种不同的语言中代表三件不同的事。Windows支援四个不同的双位元组字元集:内码表932(日文)、936(简体中文)、949(韩语)和950(繁体汉字)。只有为这些国家(地区)生产的Windows版本才支持DBCS。明白Unicode和DBCS之间的区别很重要。Unicode使用(特别在C程式设计语言环境里)宽字元集。Unicode中的每个字元都是16位元宽而不是8位元宽。在Unicode中,没有单单使用8位元数值的意义存在。相比之下,在双位元组字元集中我们仍然处理8位元数值。有些位元组自身定义字元,而某些位元组则显示需要和另一个位元组共同定义一个字元。

     产生的问题/dbcs 编辑

        当计算机传到亚洲等国家时,ASCII编码也还是不够用了,像我们中国,常用的汉子估计也得3000+吧。所以老美在设计像我们国家的操作系统时就加入了DBCS编码,取2个字节代表一个字符,共计65535个字符,这样对我们国家也就够用了。
        不过DBCS编码有一个问题:汉字是两个字节,而英文仍旧是一个字节。这样问题就来,按正常情况,程序是如A我是程序员的编码是途中的第二行和第三行,但如果程序出错等原因,最后读取的编码就变成了第四行了,这样就会产生乱码了,这也是我们使用的系统动不动就有乱码的真正原因了。因为每当涉及到DBCS字符串的处理时,总是要判断当中的一个字节到底表示的是一个字符还是半个字符,如果是半个字符,那是前一半还是后一半?由此可见DBCS并不是一种非常好的解决方案。

    处理方法/dbcs 编辑

      处理DBCS字串非常杂乱,但是处理Unicode文字则像处理有秩序的文字。您也许会高兴地知道前128个Unicode字元(16位元代码从0x0000到0x007F)就是ASCII字元,而接下来的128个Unicode字元(代码从0x0080到0x00FF)是ISO 8859-1对ASCII的扩展。Unicode中不同部分的字元都同样基於现有的标准。这是为了便於转换。希腊字母表使用从0x0370到0x03FF的代码,斯拉夫语使用从0x0400到0x04FF的代码,美国使用从0x0530到0x058F的代码,希伯来语使用从0x0590到0x05FF的代码。中国、日本和韩国的象形文字(总称为CJK)占用了从0x3000到0x9FFF的代码。

    添加视频 | 添加图册相关影像

    互动百科的词条(含所附图片)系由网友上传,如果涉嫌侵权,请与客服联系,我们将按照法律之相关规定及时进行处理。未经许可,禁止商业网站等复制、抓取本站内容;合理使用者,请注明来源于www.baike.com。

    登录后使用互动百科的服务,将会得到个性化的提示和帮助,还有机会和专业认证智愿者沟通。

    互动百科用户登录注册
    此词条还可添加  信息模块
    编辑摘要

    WIKI热度

    1. 编辑次数:6次 历史版本
    2. 参与编辑人数:6
    3. 最近更新时间:2014-12-16 21:06:48

    相关词条

    分类热词

    互动百科

    扫码下载APP