9.1 第九章 字符集

Posted chxbar.cn

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了9.1 第九章 字符集相关的知识,希望对你有一定的参考价值。

9.1 -9.3 字符集概述

这里着重介绍utf-8和gbk:

  1. utf-8:

UTF-8按一定规则将一个ISO-10646或Unicode字元码转换成1至4个字节的编码,

  • 其中将ASCII码(0~0x7F)转换成单字节编码,也就是严格兼容ASCII字符集;
  • UTF-8的2字节编码,用以转换ISO-10646标准0x0080~0x07FF的UCS-4原始码;
  • UTF-8的3字节编码,用以转换ISO-10646标准 0x0800~0xFFFF的UCS-4原始码;
  • UTF-8的4字节编码,用以转换ISO-10646标准0x00010000~0001FFFF的UCS-4原始码。
  1. gbk:

GBK:全称《汉字内码扩展规范》1.0 版,发布于1995 年。GBK 在GB2312 内码系统的基础上进行了扩充,收录了GB13000.1-1993 的全部20902 个CJK 统一汉字,包括GB2312 的全部6763 个汉字。此外,它增补编码了52 个汉字,13 个汉字结构符(在ISO/IEC 10646.1: 2000中称为表意文字描述符)和一些常用部首与汉字部件。在GBK 的内码系统中,GB2312 汉字所在码位保持不便,这样,保证了GBK 对GB2312 的完全兼容。同时,GBK 内码与GB13000.1代码一一对应,为GBK 向GB13000.1 的转换提供了解决办法。有意思的是GBK 并不是一个强制性的国家标准,只是一个行业指导规范,并没有强制力,但由于得到了MicrosoftWindows 95 的支持而大为流行。

3.各字符集比较

技术分享

9.4 怎样选择合适的字符集

数据库来说,字符集更加重要,因为数据库存储的数据大部分都是各种文字,字符集对数据库的存储、处理性能,以及日后系统的移植、推广都会有影响。

mysql 5.0 目前支持几十种字符集,UTF-8 是MySQL 5.0 支持的唯一Unicode 字符集,但 
版本是3.0,不支持4 字节的扩展部分。面对众多的字符集,我们该如何选择呢?

虽然没有一定之规,但在选择数据库字符集时,可以根据应用的需求,结合上面介绍的 
一些字符集的特点来权衡,主要考虑因素包括:

(1)满足应用支持语言的需求,如果应用要处理各种各样的文字,或者将发布到使用 不同语言的国家或地区,就应该选择Unicode 字符集。对MySQL 来说,目前就是UTF-8。

(2)如果应用中涉及已有数据的导入,就要充分考虑数据库字符集对已有数据的兼容 
性。假如已有数据是GBK 文字,如果选择GB2312-80 为数据库字符集,就很可能出现某些 文字无法正确导入的问题。

(3)如果数据库只需要支持一般中文,数据量很大,性能要求也很高,那就应该选择 双字节定长编码的中文字符集,比如GBK。因为,相对于UTF-8 而言,GBK 比较“小”,每 个汉字只占2 个字节,而UTF-8 汉字编码需要3 个字节,这样可以减少磁盘I/O、数据库cache,以及网络传输的时间,从而提高性能。相反,如果应用主要处理英文字符,仅有少量汉字数 据,那么选择UTF-8更好,因为GBK、UCS-2、UTF-16 的西文字符编码都是2 个字节,会造成 很大不必要的开销。

(4)如果数据库需要做大量的字符运算,如比较、排序等,选择定长字符集可能更好, 因为定长字符集的处理速度要比变长字符集的处理速度快。

(5)如果所有客户端程序都支持相同的字符集,应该优先选择该字符集作为数据库字 符集。这样可以避免因字符集转换带来的性能开销和数据损失。




以上是关于9.1 第九章 字符集的主要内容,如果未能解决你的问题,请参考以下文章

第九章 正则

第九章 类

第九章 参数

(转载)虚幻引擎3--第九章 – UNREALSCRIPT预处理器

第九章 项目经理

第九章 文档数据库