字符集基础及Oracle中的字符集.pptVIP

* 字符集基础及Oracle中的字符集 唐成—2010.03.17 目录 字符集基础 oracle数据库字符集 字符集基础 第一个编码表--ASCII码 很简单﹐英语国家的大小写字母加起来才52个字符﹐再加上数字﹐符号和一些特殊字符 (大约20几个），总共80～90个。所以用一个byte来表示一个字符(最高位置0),总共能存储128(2^8)个字符，这样足够放下了。如“A”用65表示﹐存在计算机中就65)﹐为了书写方便﹐我们一般记作0x41(16进制),97则表示小写的“a”,存在计算机中就97)﹐记作0x61。“?”用63表示,记作0x3F。 字符集基础 GB2312的产生 和英语国家不同﹐我们的汉字远远不止128个﹐所以一个byte肯定不能表示完﹐那就多加个byte,16位(65536)总可以了吧。不过这样虽解决了位数不够的问题﹐但是原来的英文文件怎么办?总不成又全部拿出来改成双字节吧。幸好﹐居然发现原来的ASCII的第一位居然是0﹐那我们把第1位改成1不就OK了吗?以后凡看到0开头的就读1个字节﹐1开头的就读2个字节。(而且128*128表示所有的简体字也足够了) 字符集基础 字符集的混乱的开始 其它国家和地区也不甘示弱﹐纷纷亮出自己的字符集,于是乎什么BIG5(中国台湾),shift_jis(日本),ks_c_5601-1987(韩国)都闪亮登场﹐一时间百鸟争鸣,百花齐放。 每个国家都想与ASCII保持兼容﹐理所当然﹐后面的字符就完全不一样了﹐因此﹐同样的0xD0A1,在GB2312中是小字﹐而在BIG5中却是苤字。你想想﹐这样不乱才怪。 字符集基础 unicode的诞生 到了这时候﹐总有人会想到﹐再这样继续下去是肯定不行的﹐于是他们就想到了如果有一个标准﹐能包括所有字符那不就OK了吗? 于是“大哥”级标准就出来了﹐这就是unicode,为了能够足够表示世界上的所有字符这样光荣而又伟大的任务﹐这家伙用了四个字节来表示(2的32次方到底是多少﹐我也懒得算了),这下好了﹐天下太平了﹐再也不会有麻烦了﹐耳根清静了。 不过unicode好是好﹐但是毕竟四个字节表示一个字符，太长了，于是人们把那些比较“强大”的国家的字符放在前面，这样实际上用两个字节就够了，这就产生了unicode-16标准。 字符集基础 unicode的诞生 虽然标准出来了﹐可是好歹ASCII也用了这么久﹐那些英语国家也在那里嚷嚷﹐这倒好﹐搞个什么破标准﹐我们又没有得到什么好处﹐反而让我们原来的程序都运行不了了(为什么呀﹐你想想﹐原来我们的程序字符都是一个字节一个字节认﹐现在倒好﹐全改成2个一起认﹐这还怎么跑呀?)﹐况且我们凭白无故了用了这么多0﹐真别扭（unicode中的后8bit位还是ASCII标准﹐只不过在前面加了8个0）﹐由于那些国家势力比较大﹐所以这个问题不容忽视. 字符集基础 UTF8的诞生(Unicode Transformation Format) 使用ASCII的国家太强大了，于是就有人想，还是让英文和常用的字符占用一个字节，其它国家的字符使用更多的字符来表示吧。 这样就产生了变长编码。把unicode进行变长编码后，就产生了UTF8编码。 uninode转换成UTF-8的模板 U- U-0000007F: 0xxxxxxx U- U-000007FF: 110xxxxx 10xxxxxx U- U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx U- U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx U- U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx U- U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 字符集基础 汉字在unicode编码中的位置 汉字的unicode编码的范围为：0x4e00-0x9fa5 对照uninode转换成UTF-8的模板可以看出，每个汉字使用UTF-8表示变成了3个字符。 U- U-0000007F: 0xxxxxxx U- U-000007FF: 110xxxxx 10xxxxxx U- U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx U- U-001FFFFF: 11110xxx 10xxxxxx 10