Unicode字符编码
2016-03-14 17:30
239 查看
ASCII码:
最早的字符编码,使用一个Byte的7位来表示128种字符(控制字符,控制符,小写字母,大写字母,数字,标点,运算符等)。
然而对于英语国家来说,基本够用;但对于使用非英文字符的国家来说,就不够用了。
扩展ASCII码:
为了满足需要,各国在兼容ASCII码的基础上对128-155等字节进行本国语言对应编码,或者不同系统画图元素进行编码,出现了各种不兼容的扩展ASCII码。
扩展ASCII码基本满足了表音文字的表示,但对于中文等表意文字完全不够用,中文汉字有上万个。
GB-XXXX,BIG5等:
于是表意文字国家开始使用两个字节来表示本国文字编码,也是标准繁多。
对于GB-2312,兼容了ASCII码,所有的非ASCII码都用两个高位为一的字节表示,后续又有各自标准对其补充。
由最初的计算机未普及而完全够用的ASCII码,到后来由于全球普及而产生的各国编码大乱斗,导致了很多兼容性的问题。
经常会出现本来正确的文字却显示为乱码,或者问号等。
Unicode:
为了形成大一统的局面,Unicode应声而出。Unicode对世界上已知的所有字符、文字等都进行了唯一编码,各不冲突,是一个全集。
Unicode使用两个字节进行编码,由于两个后来不太够用,又出现了分层表示(共17层),总的表示区间为:0x0000 - 0x10FFFF。
注意,其实所有的编码方式包含两部分:字符编码方式,数据转换方式。大部分两者编码相同,不进行区分,但考虑到兼容性的问题,Unicode具有不同的数据转换方式。
UTF-32:
将所有的Unicode字符编码都用四个字节数据存储,完全够用,但浪费空间,不兼容最流行的ASCII码。
UTF-16:
使用两个字节(0x0000-0xFFFF)或者四个字节(0x0001 0000-0x0010 FFFF)数据存储方式,稍微节省,也是浪费,不兼容ASCII码。
UTF-8:
使用一到四个字节存储,兼容ASCII码。由于使用变长度的方式存储,故UTF-8需要专门的识别方案。
0x00-0x7F -> 0XXXXXXX 直接存储,对应于ASCII码
0x0080 - 0x07FF -> 110XXXXX 10XXXXXX 首字节的0之前的1的个数表明使用多少个字节编码,后面的跟随字节都是10开始
0x0800 - 0xFFFF -> 1110XXXX 10XXXXXX 10XXXXXX
0x0001 0000 - 0x001F FFFF -> 11110XXX 10XXXXXX 10XXXXXXX 10XXXXXX
对于如何获知一个文件使用的编码格式,存在三种方式:
1.附带说明(在其它地方说明文件使用的编码);
2.BOM表示(在文本的前2/3个字节添加表示编码方式的字符,UTF-16BE的BOM为FEFF,UTF-16LE为FFFE,UTF-8为EFBBBF);
3.猜(呵呵,其实大部分文本文件都靠猜)。
为了保证与ASCII的兼容性,UTF-8在类Unix系统下无BOM,Windows的记事本存储时带BOM。
下面两幅图是对于同样的字母使用记事本的不同存储格式得到的不同十六进制存储内容比较,ANSI为系统默认字符编码,中文好像是GB-2312.
![](https://img-blog.csdn.net/20160314181040742?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
最早的字符编码,使用一个Byte的7位来表示128种字符(控制字符,控制符,小写字母,大写字母,数字,标点,运算符等)。
然而对于英语国家来说,基本够用;但对于使用非英文字符的国家来说,就不够用了。
扩展ASCII码:
为了满足需要,各国在兼容ASCII码的基础上对128-155等字节进行本国语言对应编码,或者不同系统画图元素进行编码,出现了各种不兼容的扩展ASCII码。
扩展ASCII码基本满足了表音文字的表示,但对于中文等表意文字完全不够用,中文汉字有上万个。
GB-XXXX,BIG5等:
于是表意文字国家开始使用两个字节来表示本国文字编码,也是标准繁多。
对于GB-2312,兼容了ASCII码,所有的非ASCII码都用两个高位为一的字节表示,后续又有各自标准对其补充。
由最初的计算机未普及而完全够用的ASCII码,到后来由于全球普及而产生的各国编码大乱斗,导致了很多兼容性的问题。
经常会出现本来正确的文字却显示为乱码,或者问号等。
Unicode:
为了形成大一统的局面,Unicode应声而出。Unicode对世界上已知的所有字符、文字等都进行了唯一编码,各不冲突,是一个全集。
Unicode使用两个字节进行编码,由于两个后来不太够用,又出现了分层表示(共17层),总的表示区间为:0x0000 - 0x10FFFF。
注意,其实所有的编码方式包含两部分:字符编码方式,数据转换方式。大部分两者编码相同,不进行区分,但考虑到兼容性的问题,Unicode具有不同的数据转换方式。
UTF-32:
将所有的Unicode字符编码都用四个字节数据存储,完全够用,但浪费空间,不兼容最流行的ASCII码。
UTF-16:
使用两个字节(0x0000-0xFFFF)或者四个字节(0x0001 0000-0x0010 FFFF)数据存储方式,稍微节省,也是浪费,不兼容ASCII码。
UTF-8:
使用一到四个字节存储,兼容ASCII码。由于使用变长度的方式存储,故UTF-8需要专门的识别方案。
0x00-0x7F -> 0XXXXXXX 直接存储,对应于ASCII码
0x0080 - 0x07FF -> 110XXXXX 10XXXXXX 首字节的0之前的1的个数表明使用多少个字节编码,后面的跟随字节都是10开始
0x0800 - 0xFFFF -> 1110XXXX 10XXXXXX 10XXXXXX
0x0001 0000 - 0x001F FFFF -> 11110XXX 10XXXXXX 10XXXXXXX 10XXXXXX
对于如何获知一个文件使用的编码格式,存在三种方式:
1.附带说明(在其它地方说明文件使用的编码);
2.BOM表示(在文本的前2/3个字节添加表示编码方式的字符,UTF-16BE的BOM为FEFF,UTF-16LE为FFFE,UTF-8为EFBBBF);
3.猜(呵呵,其实大部分文本文件都靠猜)。
为了保证与ASCII的兼容性,UTF-8在类Unix系统下无BOM,Windows的记事本存储时带BOM。
下面两幅图是对于同样的字母使用记事本的不同存储格式得到的不同十六进制存储内容比较,ANSI为系统默认字符编码,中文好像是GB-2312.
相关文章推荐
- Linux 与 Windows 对UNICODE 的处理方式
- Unicode详细分析解释
- ASP编码必备的8条原则
- Perl ASCII 字符判断
- vbs中将GB2312转Unicode的代码
- XML指南——XML编码
- C#中字符串编码处理
- ExtJS中文乱码之GBK格式编码解决方案及代码
- 将编码从GB2312转成UTF-8的方法汇总(从前台、程序、数据库)
- 程序员趣味读物 谈谈Unicode编码
- 文本文件编码方式区别
- 与ASCII码相关的C语言字符串操作函数
- C语言安全编码之数值中的sizeof操作符
- C#实现获取文本文件的编码的一个类(区分GB2312和UTF8)
- 一些关于数据存储和查询优化的想法
- 常用字符集编码详解(ASCII GB2312 GBK GB18030 unicode UTF-8)
- VC中BASE64编码和解码使用详解
- C#实现Json转Unicode的方法
- 深入理解Python字符编码 推荐
- 数据在计算机内存中的存储形式