2.10日音讯,网页制作基础之字符编码知识全解析

　　2.10日音讯,网页制作基础之字符编码知识全解析。字符编码的知识可谓是博大精深，无论是古代还是现在，它都在人们的生活中扮演了很大的作用，更别说在网站建设中的作用了，但人们一提起编码往往是往网站上去想，的确因为网站技术的普遍发展，使之更加被人们所熟悉，今天邯郸网站建设就来给大家全面阐述一下更加全面的知识：

　　ISO/IEC小组在1984年成立后的第三年（即1987年）开始启动ISO8859标准的编写，ISO8859是一系列8位字符集的标准，主要为世界各地的不同语言（除CJK）而单独编写的字符集，一共定义了15个字符集：

　　ISO/IEC8859-1：西欧语言

　　ISO/IEC8859-2：中欧语言

　　ISO/IEC8859-3：南欧语言

　　ISO/IEC8859-4：北欧语言

　　ISO/IEC8859-5：斯拉夫语

　　ISO/IEC8859-6：阿拉伯语

　　ISO/IEC8859-7：希腊语

　　ISO/IEC8859-8：希伯来语

　　ISO/IEC8859-9：土耳其语

　　ISO/IEC8859-10：北日耳曼语

　　ISO/IEC8859-11：泰语

　　ISO/IEC8859-13：波罗的语族

　　ISO/IEC8859-14：凯尔特语族

　　ISO/IEC8859-15：西欧语言，收录芬兰语字母和大写法语重音字母，以及欧元（€）符号

　　ISO/IEC8859-16：东南欧语言，主要供罗马尼亚语使用，并加入欧元（€）符号

　　其中ISO/IEC8859-1至ISO/IEC8859-4四个项目早在1982年就已经编写出来，只不过是由ANSI与ECMA合作完成，并于1985年正式公布，ISO/IEC小组成立后，这一成果被其收录，并改名为ISO/IEC8859前四个项目。

　　大家其实发现以上15个字符集中并没有代号为“ISO/IEC8859-12”的字符集，据说-12号本来是预留给印度天城体梵文的，但后来却搁置了（阿三有了自己的编码－ISCII）。由于英语没有任何重音字母，故可使用以上十五个字符集中的任何一个来表示。

　　ISO/IEC10646/UCS

　　1993年，ISO/IEC10646标准第一次发表，ISO/IEC10646是ISO646的扩展，定义了1个31位的字符集。ISO10646标准中定义的字符集为UCS，UCS是UniversalCharacterSet的缩写，中文译作通用字符集。

　　版本：

　　ISO/IEC10646-1：第一次发表于1993年，现在的公开版本是2000年发表的ISO/IEC10646-1:2000。

　　ISO/IEC10646-2：在2001年发表。

　　包含字符：

　　最初的ISO10646-1:1993的编码标准，即Unicode1.1，收录中国大陆、台湾、日本及韩国通用字符集的汉字共计20,902个，当然每个版本的Unicode标准的字符集所包含的字符数不尽相同，UCS包含了已知语言的所有字符，除了拉丁语、希腊语、斯拉夫语、希伯来语、阿拉伯语、亚美尼亚语、格鲁吉亚语，还包括中文、日文、韩文这样的方块文字，此外还包括了大量的图形、印刷、数学、科学符号。

　　UCS给每个字符分配一个唯一的代码，并且赋予了一个正式的名字，通常在表示一个Unicode值的十六进制数的前面加上“U+”，例如“U+0041”代表字符“A”。

　　编码方案：

　　UCS仅仅是一个超大的字符集，关于UCS制定的编码方案有两种：UCS-2和UCS-4，Unicode默认以UCS-2编码。

　　顾名思义，UCS-2就是用两个字节编码，UCS-4就是用4个字节（实际上只用了31位，最高位必须为0）编码。那么UCS-2其实可以容纳的字符数为65536（2的16次方），而UCS-4可以容纳的字符数为2147483648（2的31次方）。其实对于UCS-2已经是完全够用了，基本可以包含世界所有国家的常用文字，如果需要考虑一些偏僻字，那么UCS-4则绝对可以满足了，21亿个字符哪怕是整个宇宙也够用了吧！

　　UTF

　　Unicode诞生，随之而来的计算机网络也发展了起来，Unicode如何在网络上传输也是一个必须考虑的问题，于是在1992年，面向网络传输的UTF标准出现了。

　　UTF是UnicodeTransformationFormat的缩写，中文译作Unicode转换格式。其实我们从现在可以把Unicode看作是一个标准或组织，而UCS就是一个字符集，那么UCS在网络中的传输标准就是UTF了。

　　前面提到了UCS的编码实现方式为UCS-2和UCS-4，即要么是每个字符为2个字节，要么是4个字节。如果一个仅包含基本7位ASCII字符的Unicode文件，每个字符都使用2字节的原Unicode编码传输，其第一字节的8位始终为0，这就造成了比较大的浪费。但是，聪明的人们发明了UTF-8，UTF-8采用可变字节编码，这样可以大大节省带宽，并增加网络传输效率。

　　UTF-8

　　使用1~4个字节为每个UCS中的字符编码：

　　128个ASCII字符只需一个字节编码（Unicode范围由U+0000至U+007F）

　　拉丁文、希腊文、西里尔字母、亚美尼亚语、希伯来文、阿拉伯文、叙利亚文及它拿字母需要二个字节编码（Unicode范围由U+0080至U+07FF）

　　大部分国家的常用字（包括中文）使用三个字节编码

　　其他极少使用的生僻字符使用四字节编码

　　UTF-16/UCS-2

　　UCS-2的父集，使用2个或4个字节来为每个UCS中的字符编码：

　　128个ASCII字符需两个字节编码

　　其他字符使用四个字节编码

　　UTF-32/UCS-4

　　等同于UCS-4，对于所有字符都使用四个字节来编码

　　GB13000

　　前面提到了Unicode的迅速发展，至1993年时，包含CJK的Unicode1.1已经发布了，天朝的ZF也意识到了需要一个更大的字符集来走向世界，于是在同一年，中国大陆制定了几乎等同于Unicode1.1的GB13000.1-93国家编码标准（简称GB13000）。是的，你没听错，中华人民共和国信息产业部把Unicode里的所有东东拿过来，然后自己重新修订发布了下，改为了国家标准GB13000。此标准等同于ISO/IEC10646.1:1993和Unicode1.1。

　　GBK

　　1995年，在GB13000诞生后不久，中国教育科研网（NCFC）与美国NCFnet直接联网，这一天是中国被国际承认为开始有网际网路的时间。此后网络正式开始在中国大陆接通，个人计算机开始在中国流行，虽然当时只是高富帅才消费得起的产品。中国是一个十几亿人口的大国，微软意识到了中国是一个巨大的市场，当时的微软也将自己的操作系统市场布局进中国，进入中国随之而来要解决的就是系统的编码兼容问题。

　　之前的国家编码标准GB2312，基本满足了汉字的计算机处理需要，它所收录的汉字已经覆盖中国大陆99.75%的使用频率。但对于人名、古汉语等方面出现的罕用字和繁体字，GB2312不能处理，因此微软利用了GB2312中未使用的编码空间，收录了GB13000中的所有字符制定了汉字内码扩展规范GBK（K为汉语拼音KuoZhan中“扩”字的首字母）。所以这一关系其实是大陆把Unicode1.1借鉴过来改名为了GB13000，而微软则利用GB2312中未使用的编码空间收录GB13000制定了GBK。所以GBK是向下完全兼容GB2312的。

　　包含字符：

　　共收录21886个字符，其中汉字21003个，字符883个

　　编码方式：

　　GBK只不过是把GB2312中未使用的空间，编码了其他字符，所以GBK同样是用两个字节为每个字符进行编码。

　　GB18030

　　微软到了99年前后，说GBK已经落伍了，现在流行UTF-8标准，准备全盘转换成UTF-8，但中国ZF不是吃素的，编写并强制推出了GB18030标准。GB18030的诞生还有一个原因是GBK只包含了大部分的汉字和繁体字等，我们的少数民族兄弟根本木有考虑！中国有56个民族，其中有12个民族有自己的文字，那怎么办呢？在2000年，电子工业标准化研究所起草了GB18030标准，项目代号“GB18030-2000”，全称《信息技术-信息交换用汉字编码字符集-基本集的扩充》。此标准推出后，在中国大陆之后的所售产品必须强制支持GB18030标准，不然不得卖！（这招挺狠的–-#）

　　版本：

　　GB18030-2000

　　GB18030-2005

　　包含字符：

　　GB18030收录了GBK中的所有字符，并将Unicode中其他中文字符（少数民族文字、偏僻字）也一并收录进来重新编码。其中GB18030-2000共收录27533个汉字，而GB18030-2005共包含70244个汉字。

　　编码方式：

　　采用多字节编码，每个字符由1或2或4个字节进行编码

　　前端眼中的字符编码

　　前面我们穿越回过去对字符编码做了下了解，那么这些字符编码跟我们到底有啥关系？

　　基本原理：

　　当我们打开编辑器coding时，按下ctrl+s的那一刻，其实等于是将自己的工作成果存储进了计算机，而这里最关键的是我们以什么字符编码来进行存储，我们以intellij编辑器为例：

　　我们在编写此文档时，是以UTF-8编码方式进行coding，当我们按下ctrl+s时，则此文档以utf-8编码方式存储进了计算机（右下角的UTF-8），而head区域中的的作用则是告诉浏览器此文档以utf-8编码方式编码。

　　我们此时用Hex编辑器打开这个文件，来看看他的二进制流：

　　其中红框标注出的即为“小海”两个中文字的二进制流，第一个为”111001011011000010001111″转化为十六进制则为“E5B08F”，第二个为“101101011011011100001101”转化为十六进制为“E6B5B7”，而当我们去查询UTF-8的码表时发现“E5B08F”对应的字符为“小”，“E6B5B7”对应的字符则为“海”，至此当我们用浏览器进行预览页面时，由于浏览器同样以UTF-8方式对此页面进行解码，“小海”两个字则可以被正确的显示出来。

　　乱码是个XX

　　做过前端的基本都遇到过乱码问题吧？好吧，下面就带大家来揭开这一神秘的面纱。

　　我们用notepad打开上面的文件，并重新以GBK方式编码，然后用intellij打开后：

　　乱了有木有！居然变成了“C��”，木有道理呀！我在用notepad编辑文件时采用的是gbk编码，而头部申明的也是gbk，本身notepad打开也是正常，但用intellij打开却乱了！

　　罪魁祸首：编辑器默认编码。每个编辑器都会有默认编码，如果没有为一个项目单独设置过默认编码，打开一个单独的文件，编辑器往往以自己的默认编码去解码这个文件，如上图，我们的inellij编辑器的默认是UTF-8解码，而文件是GBK编码方式，那么打开肯定就是乱的拉。

　　所以编辑器也是一个因素，DW则可以智能判断文件的编码方式，上述文件用DW打开并不会乱码，而intellij可能对中文的支持并不是很好，所以还不能智能判断中文编码，默认以UTF-8解码（当然默认编码自己是可以修改的）。

　　很多读者可能还有一个疑问，为啥乱码出来的是“C��”？

　　其实原理已在上面的基本原理中做过介绍，即编辑器ctrl+s存进计算机时是GBK，但尝试用utf-8来解析，对应的utf-8中的码表中却找到了“C��”，感兴趣的同学可以自己研究下。

　　我们现在将文件重新编辑，即编辑时采用GBK，但头部申明为UTF-8：

　　然后用浏览器打开后，就是这样了：

　　乱了有木有！这个其实和编辑器打开一个文件乱码的原理是一致的：即编辑器编码时所采用的字符编码和解码时所采用的字符编码不一致。上述栗子，我们在coding时采用的是GBK编码，但头部却告诉浏览器这个文档是UTF-8编码，那么浏览器在用UTF-8解码时就会出现了乱码。

　　申明编码的方式

　　我们在coding时需要告诉浏览器自己的文件采用了什么字符编码，下面列出一些常见的方法：

　　//html5

　　//html4xhtml

　　

　　

　　我们可以在head区域的meta元素中为整个页面申明编码方式

　　，也可以为单独的外链文件申明编码方式（link/script等元素）。问题是如果页面头部和外链文件中只有部分申明或者全部申明，那么对应的到底是以什么方式解码呢？这里就有一个优先级的问题，具体的判定关系如下：

　　通过上述判定，我们其实可以发现，一个页面中优先级最高的其实是服务端的编码设置，如果一旦服务端设置了编码A，那么页面即以A来解析。

　　目前Google采用的是这一做法，这样的传输效率会更高，不需要在头部额外再单独申明编码，但这样其实也有一定的风险，除了需要有一个严谨的编码规范，还需要确保服务器上的页面都保持同一编码，一旦不一致就会造成乱码，所以目前这一方案在国内用的并不多。

　　其他的，如果外链资源设置了编码C，那么即以C来解析，无论服务端和头部是否申明编码。

　　但必须要提醒大家的是：申明的编码只是告诉浏览器相关的内容是以什么方案去解码，并不是这一部分内容就采用了这个编码。所以大家在coding时的编码一定要确保和你申明的保持统一，不然就会出现乱码的问题。

　　BOM是个神马

　　BOM是byte-ordermark的缩写，为Unicode标准为了用来区分一个文件是UTF-8还是UTF-16或UTF-32编码方式的记号，又称字节序。

　　UTF-8以单字节为编码单元，并没有字节序的问题，而UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”，那么这是“奎”还是“乙”？这是UTF-16文件开头的BOM就有作用了。

　　采用Unicode编码方式的文件如果开头出现了“FEFF”，“FEFF”在UCS中是不存在的字符，也叫做“ZEROWIDTHNO-BREAKSPACE”，那么就表明这个文件的字节流是Big-Endian（高字节在前）的；如果收到“FFFE”，就表明字节流是Little-Endian（低字节在前）。

　　在UTF-8文件中放置BOM主要是微软的习惯，BOM其实是为UTF-16和UTF-32准备的，微软在UTF-8使用BOM是因为这样可以把UTF-8和ASCII等编码明确区分开，但这样的文件在Window以外的其他操作系统里会带来问题。

　　我们以Window下的文本文件为例：

　　在保存时可以选择ANSI、Unicode、Unicodebigendian和UTF-8四种编码方式。

　　其中ANSI是默认的编码方式，对于英文文件是ASCII编码，对于简体中文文件是GB2312编码（只针对Windows简体中文版，如果是繁体中文版会采用Big5码）；

　　Unicode其实是UTF-16endianbig编码方式，这个把带有BOM的小端序UTF-16称作Unicode而又不详细说明，也是微软的习惯；

　　而Unicodebigendian则是带有BOM的大端序编码方式

　　目前UTF-16通常用于系统文件的编码，而UTF-32由于对每个字符都采用四个字节编码，所以现在互联网中大部分都采用UTF-8来进行编码传输。

　　关于未来的展望

　　概述

　　（图：中国地区ALEXA排名前20的站点所采用的编码占比）

　　（图：腾讯互娱所有业务所采用的编码占比）

　　左图表明GB2312、GBK与UTF-8编码三分天下，而右图显示腾讯互娱的业务大多数采用了GB2312，零星的采用了其他编码。总的就是不同的字符编码方案基本都存在了，而这也与各公司业务的历史原因也有一定的关系。

　　当我们在项目的最初期时采用了一种非Unicode编码方案时，随着业务的壮大，积累的页面越来越多，到后期想去改成Unicode编码方案，就会担心出错的问题，所以现在大多数公司都采用了延用初期编码的方式，如淘宝，腾讯互娱等，以及四大门户。