mysql efbbbf_字符集与字符编码

什么是ANSI字符集?

这个不是固定字符集,如果在中文简体windows中,它代码字符集是gb2312,在繁体值代表是big5等等。

为什么英文字符不会出现乱码?

常见ascii码字符集是:128字符,对应编码值是:1-128

,二进制表示是:00000001-01111111。它表示了所有常见英文数字,标点符号。其它字符集都是由ascii码字符集扩展而来,扩展了最高位由10000000开始,用多字节表示新的字符,基本都保留了:0xxxxxxx

开头128个基本字符,而且对应编码与ascii码相同。

这样,常见英文字符不论在那种字符集中,对应字符编码一致,存储编码也一样。读取时候无论用什么字符集读取,它所对应字符也一直。所有基本不会出现乱码情况。

读取软件能够识别存储文件的字符集吗?

由于目前各种字符集加起来有上百种,目前除了unicode字符集,定义的存储文件头,基本其它字符集只是给出了对应的字符编号值。因此,相同编号会出现在不同的字符集中,光从文件存储的编码值,是不能确定它的字符集的。如:gb2312字符集中,D6d0对应是“中”,而同样是:D6D0在ecu-jp

字符集中,对应是“面”

什么是bom头?

bom全称是:byte order

mark,汉语意思是标记字节顺序码。只是出现在:unicode字符集中,只有unicode字符集,存储时候,要求指定编码,如果不指定,windows还会用默认的:ANSI读取。常见的bom头是:

UTF-8 ║ EF BB BF

UTF-16LE ║ FF FE (小尾)

UTF-16BE ║ FE FF (大尾)

UTF-32LE ║ FF FE 00 00

UTF-32BE ║ 00 00 FE FF

unicode与utf-8 、utf-16 utf-32是什么关系?

unicode(统一码、万国码、单一码)是一种字符集,Unicode是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。Unicode用数字0-0x10FFFF来映射这些字符,最多可以容纳1114112个字符,或者说有1114112个码位。UTF-8、UTF-16、UTF-32都是将数字转换到程序数据的编码方案。在Unicode中:汉字“字”对应的数字是23383。我们可以用:UTF-8、UTF-16、UTF-32表示这个数字,将数字23383存储在计算机中。UTF-8对应是:0xE6,

0xB1,

0x89(3个字节),UTF-16对应是:0x6c49(2个字节),UTF-32对应是:0x6c49(4个字节)。utf-8,utf-16,utf-32是unicode码一种实现形式,都是属于unicode编码。

unicode编码特点是什么?

unicode编码特点是,它定义了编码方式和存储实现方式。编码方式就是上面说的可以用,utf-8…utf-32表示,而存储实现方式,无论那种编码都知道了文件头(bom)。因此,可以通过这个特殊头来判断存储的文本文件使用那种字符集编码。

为什么utf-8编码不指定bom头(可以理解为文件头),软件任然可以正常判断出它字符集编码?

这个问题估计很多朋友都会产生疑问,为什么utf-16不指定就读乱码,而utf-8可以。我们可以从下面的例子看下: utf-8是怎么样从unicode转换而来了。

Unicode编码(16进制) ║ UTF-8 字节流(二进制)

000000 - 00007F ║ 0xxxxxxx

000080 - 0007FF ║ 110xxxxx 10xxxxxx

000800 - 00FFFF ║ 1110xxxx 10xxxxxx 10xxxxxx

010000 - 10FFFF ║ 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

从上面看,发现规律没有?第一个自己开头有几个”1”,后面就对应有几个10开头字节了。 这样我们都可以通过正则进行检测了.

[\x09\x0A\x0D\x20-\x7E] # ASCII

|[\xC2-\xDF][\x80-\xBF] # non-overlong 2-byte

|\xE0[\xA0-\xBF][\x80-\xBF] # excluding overlongs

|[\xE1-\xEC\xEE\xEF][\x80-\xBF]{2} # straight 3-byte

|\xED[\x80-\x9F][\x80-\xBF] # excluding surrogates

|\xF0[\x90-\xBF][\x80-\xBF]{2} # planes 1-3

|[\xF1-\xF3][\x80-\xBF]{3} # planes 4-15

|\xF4[\x80-\x8F][\x80-\xBF]{2} # plane 16

由于它独特的编码存储特点,因此目前常见文本处理软件就能够自动分析出来。(windows记事本,editplus,notepad++等)

为什么bom头会产生乱码?

有bom头的存储或者字节流,它一定是unicode字符集编码。到底属于那一种(utf-8还是utf-16或是utf-32),通过头可以判断出来。由于已经说过utf-16,utf-32不指定bom头,解析程序默认就认为是ansi编码,出现乱码。

而utf-8指定或者不指定程序都可判断知道对于的字符集编码。问题就出在这里,可能有的应用程序(ie6浏览器),它就认为如果utf-8编码,就不需要指定bom头,它可以自己判断,相反指定了bom头,它还会出现问题(因为它把头当utf-8解析出现乱码了)。这里不截图了,cnblogs里面谈这个比较多,目前ie6会出现问题。其它ie7+,firefox,chrome不会出现,会忽略掉bom头。

统一解决办法是:存为utf-8编码是,不需要加入bom头,其它utf-16,utf-32加入。

通过程序运算gb2312编码能够自动转换为utf-8编码吗?

utf-8实际是unicode字符集表现方式。如果看了这2种字符集编码表就清楚了。

它是2个独立字符集,相同汉字在2个字符集中所对应编号没有关系,而且汉字顺序也不同,gb2312先按照拼音后按照笔画排序,而unicode没有做相应规定。我们清楚知道,如果没有对应字符集映射关系表在手。通过直接程序进行运算是实现不了的。如果你手里有这2个字符集映射表。如:”字”utf-8是:0xE6,

0xB1, 0x89

,对应unicode编码是:23383,然后拿23383,在unicode字符集寻找,发现是字符“字”,接着将“字”这个字符,拿到gb2312表中查询:0xCE,0xC4

因此转换结果是:0xE6,0xB1,0x89 ---> 0xCE,0xC4。

GB2312、GBK、gb18030、Big5是什么关系?

GB2312:1980年的GB2312一共收录了7445个字符,包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7,低字节从A1-FE,占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。

GBK: 汉字国标扩展码,基本上采用了原来GB2312-80所有的汉字及码位,并涵盖了原Unicode中所有的汉字20902,总共收录了883个符号, 21003个汉字及提供了1894个造字码位。包括港、台两种汉字字库.

GB18030-2000产生,在GBK汉字标准字符集继续扩展,GB18030是GBK的超集,也就是包含的字符要比GBK多,又增加了6351个字符,其中一部分为4字节字(four-byte

encoding range)。增加了六种少数民族语言和一些四字节字。

Big5是中国台湾的,是繁体中文代表

GB18030兼容GBK兼容GB2312

,相同常用汉字在GB2312编码表中字符编号(编码)与GBK,GB18030相同。如:”字“gb2312字符编码是:0xCE,0xC4

,它在其它2个里面也是这个。因为GB2312只有7000多常用汉字,当出现繁体,古文时候就会出现问题,因此采用大集合的GB18030是个不错选择。

Big5与GB2312不能通过程序相互转换,需要有字符集映射关系表才能完成。

字符集是怎么样一个演变过程呢?

这个如果讲故事可以讲很久了。当计算机有美国人发明后,当时设计到字符输入,由于是英文字符,通过收集整理。它们形成了标准的ascii码(128)

字符集。8位,首位为0。

由于不断普及,欧洲西方国家相应使用,发现有些特殊字符它们不能表示,如:λφ等。如是出来想法,想利用ascii码后128位,增加它们的字符。这样就出现了EASCII码。这些还是不能表示所有国家,想法语,俄语等有自己特殊字符。因此制定标准将后128位进行分片制定。制定出iso-8859系列字符集。

ISO/IEC 8859-1 (Latin-1) - 西欧语言

ISO/IEC 8859-2 (Latin-2) - 中欧语言

ISO/IEC 8859-3 (Latin-3) - 南欧语言。世界语也可用此字符集显示。

ISO/IEC 8859-4 (Latin-4) - 北欧语言

ISO/IEC 8859-5 (Cyrillic) - 斯拉夫语言

ISO/IEC 8859-6 (Arabic) - 阿拉伯语

ISO/IEC 8859-7 (Greek) - 希腊语

ISO/IEC 8859-8 (Hebrew) - 希伯来语(视觉顺序)

ISO 8859-8-I - 希伯来语(逻辑顺序)

ISO/IEC 8859-9(Latin-5 或 Turkish)-

它把Latin-1的冰岛语字母换走,加入土耳其语字母。

ISO/IEC 8859-10(Latin-6 或 Nordic)- 北日耳曼语支,用来代替Latin-4。

ISO/IEC 8859-11 (Thai) - 泰语,从泰国的 TIS620 标准字集演化而来。

ISO/IEC 8859-13(Latin-7 或 Baltic Rim)- 波罗的语族

ISO/IEC 8859-14(Latin-8 或 Celtic)- 凯尔特语族

ISO/IEC 8859-15 (Latin-9) -

西欧语言,加入Latin-1欠缺的芬兰语字母和大写法语重音字母,以及欧元(€)符号。

ISO/IEC 8859-16 (Latin-10) - 东南欧语言。主要供罗马尼亚语使用,并加入欧元符号。

这些在一段时间,可以解决西方国家常见字符。当后来电脑在中日韩等国家普及时候,象中国常见汉字有7000多个,扩展128个空位,完全不够。因此,需要用多个字节表示。后来就定,第一个字节,第一位如果是1,后面还有一个字节与之一起表示一个字符。如果是0,就对应ascii码。

这样就形成了国内的gb2312,后来还是不够表示繁体中文,加入了:gbk,最后是gb18030,但是,这样全世界各个国家还是用它们自己字符集进行表示。没有一个统一的大字符集,能够表示全球所有字符。直到unicode出现,它的设计最多可以表示100多万个字符。全球所有字符都可以收纳在其中。

写出的程序,不用经常进行各种编码转换。就可以让世界上所有国家可以阅读对应字符文字。

什么是代码页,它与字符集有什么关系?

大家在指定网页程序语言生活,还记得cp936表示中文代码页(code

page)。那么它与我们说的gbk字符集有什么关系呢?代码页是字符集编码的别名,也有人称"内码表"。早期,代码页是IBM称呼电脑BIOS本身支持的字符集编码的名称。

常见字符集与代码页直接映射是:

cp charset

932 — 日文

936 — 简体中文(GBK)

949 — 韩文

950 — 繁体中文(大五码)

1200 — UCS-2LE Unicode 小端序

1201 — UCS-2BE Unicode 大端序

65001 — UTF-8 Unicode

936就是我们的gbk字符编码集。

CJK字符集是什么?

cjk代号意思是:汉语(Chinese)、日语(Japanese)、韩语(Korean)。也就是包含这3国语言的字符集。包含这3个国家常见的汉字,一共有2万多个。

所有软件都会默认是:ANSI字符集吗?

不同程序默认读取字符集不同,上面举例是记事本默认是这样的。在php里面会以:iso-8859-1读取。

jsp程序,java默认字符集也是:iso-8859-1。

为什么很多软件程序编译过程使用是:iso-8859-1字符集?

由于我们通过应用程序书写的软件是用各种字符集编码保存在磁盘中。如果中文默认是用gbk。保存于磁盘中,默认以字节码保存,是否有无中文,每个字码值在:1-256。这些刚好可以用iso-8859-1扩展单字节字符集。因为,它是存储最小单元。在程序语言里面,不会用中文作变量,函数等名称。那些对应都是常见ascii码。而中文用字注释,或者一些常量中。在编译时候不会影响到语法问题。它会以原来字节码保持原样。在读取时候,只需要用对应的字符集编码读出,就能得到对应中文字符。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值