标签：-- logs htm style 转化 重要 pre 常用 info
转自：http://tgideas.qq.com/webplat/info/news_version3/804/808/811/m579/201307/218730.shtml
直到1837年，世界第一条电报诞生，当时美国科学家莫尔斯尝试用一些“点”和“划”来表示不同的字母、数字和标点符号，这套表示字符的方式也被称为“摩尔斯电码”：
再后来到了1946年，世界第一台计算机诞生。发明计算机的同学们用8个晶体管的“通”或“断”组合出一些状态来表示世间万物，不过当时的计算机有一间半教室那么大，六头大象重，从现在看来这简直就是个怪物，但在当时却是震惊世界与改变世界的一项重要发明：
8个晶体管的“通”或“断”即可以代表一个字节，刚开始，计算机只在美国使用，所有的信息在计算机最底层都是以二进制（“0”或“1”两种不同的状态）的方式存储，而8位的字节一共可以组合出256（2的8次方）种状态，即256个字符，这对于当时的美国已经是足够的了，他们尝试把一些终端的动作、字母、数字和符号用8位(bit)来组合：
自此，一共只用到了128种状态，即128个字符，刚好占用了一个字节中的后7位，共包括33个控制字符和95个可显示字符，这一字符集被称为ASCII（American Standard Code for Information Interchange，美国信息交换标准代码），这一套字符集在1967年被正式公布。
讲到这里，引出几个基础概念：
现在我们来看我们文章开头提到的第一条电报的诞生，莫尔斯编码中包含了大小写英文字母和数字等符号。
而电报的原理是：
“点”对应于短的电脉冲信号，“划”对应于长的电脉冲信号，这些信号传到对方，接收机把短的电脉冲信号翻译成“点”，把长的电脉冲信号转换成“划”，译码员根据这些点划组合就可以译成英文字母，从而完成了通信任务。
而对于计算机诞生之后，只不过是将摩斯电码中的“点”和“划”换成了以8位字节二进制流的方式表示，如数字1的二进制流是0011 0001，对应的十进制流是49，十六进制流是31。
虽然刚开始计算机只在美国使用，128个字符的确是足够了，但随着科技惊人的发展，欧洲国家也开始使用上计算机了。不过128个字符明显不够呀，比如法语中，字母上方有注音符号，于是，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。比如，法语的é的二进制流为1000 0010，这样一来，这些欧洲国家的编码体系，可以表示最多256个字符了。 但是，这里又出现了新的问题。不同的国家有不同的字母，因此，哪怕它们都使用256个符号的编码方式，代表的字母却不一样。比如，1000 0010在法语编码中代表了é，在希伯来语编码中却代表了字母Gimel (?)，在俄语编码中又会代表另一个符号。但是不管怎样，所有这些编码方式中，0--127表示的符号是一样的，不一样的只是128--255的这一段。 EASCII（Extended ASCII，延伸美国标准信息交换码）由此应运而生，EASCII码比ASCII码扩充出来的符号包括表格符号、计算符号、希腊字母和特殊的拉丁符号:
EASCII码对于部分欧洲国家基本够用了，但过后的不久，计算机便来到了中国，要知道汉字是世界上包含符号最多并且也是最难学的文字。 据不完全统计，汉字共包含了古文、现代文字等近10万个文字，就是我们现在日常用的汉字也有几千个，那么对于只包含256个字符的EASCII码也难以满足天朝的需求了。 于是?中国国家标准总局?（现已更名为?国家标准化管理委员会?）在1981年，正式制订了中华人民共和国国家标准简体中文字符集，全称《信息交换用汉字编码字符集·基本集》，项目代号为GB 2312 或 GB 2312-80（GB为国标汉语拼音的首字母），此套字符集于当年的5月1日起正式实施。
共包含7445个字符，6763个汉字和682个其他字符（拉丁字母、希腊字母、日文平假名及片假名字母、俄语西里尔字母）
基于EUC存储方式，每个汉字及符号以两个字节来表示，第一个字节为“高位字节”，第二个字节为“低位字节”
要知道港澳台同胞使用的是繁体字，而中国大陆制定的GB2312编码并不包含繁体字，于是信息工业策进会在1984年与台湾13家厂商签定“16位个人电脑套装软件合作开发（BIG-5）计划”，并开始编写并推出BIG5标准。 之后推出的倚天中文系统则基于BIG5码，并在台湾地区取得了巨大的成功。在BIG5诞生后，大部分的电脑软件都使用了Big5码，BIG5对于以台湾为核心的亚洲繁体汉字圈产生了久远的影响，以至于后来的window 繁体中文版系统在台湾地区也基于BIG5码进行开发。
共收录13,060个汉字及441个符号
用两个字节来为每个字符编码，第一个字节称为“高位字节”，第二个字节称为“低位字节”
在计算机进入中国大陆的相同时期，计算机也迅速发展进入了世界各个国家。 特别是对于亚洲国家而言，每个国家都有自己的文字，于是每个国家或地区都像中国大陆这样去制定了自己的编码标准，以便能在计算机上正确显示自己国家的符号。 但带来的结果就是国家之间谁也不懂别人的编码，谁也不支持别人的编码，连大陆和台湾这样只相隔了150海里，都使用了不同的编码体系。 于是，世界相关组织意识到了这个问题，并开始尝试制定统一的编码标准，以便能够收纳世界所有国家的文字符号。 在前期有两个尝试这一工作的组织：
国际标准化组织（ISO）及国际电工委员会（IEC）于1984年联合成立了ISO/IEC小组，主要用于开发统一编码项目； 而Xerox、Apple等软件制造商则于1988年组成了统一码联盟，用于开发统一码项目。 两个组织都在编写统一字符集，但后来他们发现各自在做相同的工作，同时世界上也不需要两个不兼容的字符集，于是两个组织就此合并了双方的工作成果，并为创立一个单一编码表而协同工作。
1991年，两个组织共同的工作成果Unicode 1.0正式发布，不过Unicode 1.0并不包含CJK字符（即中日韩）。
 |
|
ISO/IEC小组在1984年成立后的第三年（即1987年）开始启动ISO 8859标准的编写，ISO 8859是一系列8位字符集的标准，主要为世界各地的不同语言（除CJK）而单独编写的字符集，一共定义了15个字符集：
其中ISO/IEC 8859-1至ISO/IEC 8859-4四个项目早在1982年就已经编写出来，只不过是由ANSI与ECMA合作完成，并于1985年正式公布，ISO/IEC小组成立后，这一成果被其收录，并改名为ISO/IEC 8859 前四个项目。 大家其实发现以上15个字符集中并没有代号为“ISO/IEC 8859 -12”的字符集，据说-12号本来是预留给印度天城体梵文的，但后来却搁置了（阿三有了自己的编码－ISCII）。由于英语没有任何重音字母，故可使用以上十五个字符集中的任何一个来表示。
1993年，ISO/IEC 10646标准第一次发表，ISO/IEC 10646是ISO 646的扩展，定义了1个31位的字符集。ISO 10646标准中定义的字符集为UCS，UCS是Universal Character Set的缩写，中文译作通用字符集。
最初的ISO 10646-1:1993的编码标准，即Unicode 1.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亿个字符哪怕是整个宇宙也够用了吧！
Unicode 诞生，随之而来的计算机网络也发展了起来，Unicode 如何在网络上传输也是一个必须考虑的问题，于是在1992年，面向网络传输的UTF标准出现了。 UTF是Unicode Transformation Format的缩写，中文译作Unicode转换格式。其实我们从现在可以把Unicode看作是一个标准或组织，而UCS就是一个字符集，那么UCS在网络中的传输标准就是UTF了。 前面提到了UCS的编码实现方式为UCS-2和UCS-4，即要么是每个字符为2个字节，要么是4个字节。如果一个仅包含基本7位ASCII字符的Unicode文件，每个字符都使用2字节的原Unicode编码传输，其第一字节的8位始终为0，这就造成了比较大的浪费。但是，聪明的人们发明了UTF-8，UTF-8采用可变字节编码，这样可以大大节省带宽，并增加网络传输效率。
使用1~4个字节为每个UCS中的字符编码：
UCS-2的父集，使用2个或4个字节来为每个UCS中的字符编码：
等同于UCS-4，对于所有字符都使用四个字节来编码
前面提到了Unicode的迅速发展，至1993年时，包含CJK的Unicode 1.1已经发布了，天朝的ZF也意识到了需要一个更大的字符集来走向世界，于是在同一年，中国大陆制定了几乎等同于Unicode1.1的GB13000.1-93国家编码标准（简称GB13000）。是的，你没听错，中华人民共和国信息产业部把Unicode里的所有东东拿过来，然后自己重新修订发布了下，改为了国家标准GB13000。此标准等同于 ISO/IEC 10646.1:1993和Unicode 1.1。
1995年，在GB13000诞生后不久，中国教育科研网（NCFC）与美国NCFnet直接联网，这一天是中国被国际承认为开始有网际网路的时间。此后网络正式开始在中国大陆接通，个人计算机开始在中国流行，虽然当时只是高富帅才消费得起的产品。中国是一个十几亿人口的大国，微软意识到了中国是一个巨大的市场，当时的微软也将自己的操作系统市场布局进中国，进入中国随之而来要解决的就是系统的编码兼容问题。 之前的国家编码标准GB 2312，基本满足了汉字的计算机处理需要，它所收录的汉字已经覆盖中国大陆99.75%的使用频率。但对于人名、古汉语等方面出现的罕用字和繁体字，GB 2312不能处理，因此微软利用了GB2312中未使用的编码空间，收录了GB13000中的所有字符制定了汉字内码扩展规范GBK（K为汉语拼音 Kuo Zhan中“扩”字的首字母）。所以这一关系其实是大陆把Unicode1.1借鉴过来改名为了GB13000，而微软则利用GB2312中未使用的编码空间收录GB13000制定了GBK。所以GBK是向下完全兼容GB2312的。
共收录21886个字符， 其中汉字21003个， 字符883个
GBK只不过是把GB2312中未使用的空间，编码了其他字符，所以GBK同样是用两个字节为每个字符进行编码。
微软到了99年前后，说GBK已经落伍了，现在流行UTF-8标准，准备全盘转换成UTF-8，但中国ZF不是吃素的，编写并强制推出了GB18030标准。GB18030的诞生还有一个原因是GBK只包含了大部分的汉字和繁体字等，我们的少数民族兄弟根本木有考虑！中国有56个民族，其中有12个民族有自己的文字，那怎么办呢？在2000年，电子工业标准化研究所起草了GB18030标准，项目代号“GB 18030-2000”，全称《信息技术-信息交换用汉字编码字符集-基本集的扩充》。此标准推出后，在中国大陆之后的所售产品必须强制支持GB18030标准，不然不得卖！（这招挺狠的 - -#）
GB18030收录了GBK中的所有字符，并将Unicode中其他中文字符（少数民族文字、偏僻字）也一并收录进来重新编码。其中GB 18030-2000共收录27533个汉字，而GB 18030-2005共包含70244个汉字。
采用多字节编码，每个字符由1或2或4个字节进行编码
前面我们穿越回过去对字符编码做了下了解，那么这些字符编码跟我们到底有啥关系？
当我们打开编辑器coding时，按下ctrl+s的那一刻，其实等于是将自己的工作成果存储进了计算机，而这里最关键的是我们以什么字符编码来进行存储，我们以intellij编辑器为例：
我们在编写此文档时，是以UTF-8编码方式进行coding，当我们按下ctrl+s时，则此文档以utf-8编码方式存储进了计算机（右下角的UTF-8），而head区域中的<meat charset="utf-8">的作用则是告诉浏览器此文档以utf-8编码方式编码。 我们此时用Hex编辑器打开这个文件，来看看他的二进制流：
其中红框标注出的即为“小海”两个中文字的二进制流，第一个为"11100101 10110000 10001111"转化为十六进制则为“E5B08F”，第二个为“10110101 10110111 00001101”转化为十六进制为“E6B5B7”，而当我们去查询UTF-8的码表时发现“E5B08F”对应的字符为“小”，“E6B5B7”对应的字符则为“海”，至此当我们用浏览器进行预览页面时，由于浏览器同样以UTF-8方式对此页面进行解码，“小海”两个字则可以被正确的显示出来。
做过前端的基本都遇到过乱码问题吧？好吧，下面就带大家来揭开这一神秘的面纱。
乱了有木有！居然变成了“C??”，木有道理呀！我在用notepad编辑文件时采用的是gbk编码，而头部申明的也是gbk，本身notepad打开也是正常，但用intellij打开却乱了！
罪魁祸首：编辑器默认编码。每个编辑器都会有默认编码，如果没有为一个项目单独设置过默认编码，打开一个单独的文件，编辑器往往以自己的默认编码去解码这个文件，如上图，我们的inellij编辑器的默认是UTF-8解码，而文件是GBK编码方式，那么打开肯定就是乱的拉。
所以编辑器也是一个因素，DW则可以智能判断文件的编码方式，上述文件用DW打开并不会乱码，而intellij可能对中文的支持并不是很好，所以还不能智能判断中文编码，默认以UTF-8解码（当然默认编码自己是可以修改的）。
很多读者可能还有一个疑问，为啥乱码出来的是“C??”？ 其实原理已在上面的基本原理中做过介绍，即编辑器ctrl+s存进计算机时是GBK，但尝试用utf-8来解析，对应的utf-8中的码表中却找到了“C??”，感兴趣的同学可以自己研究下。
然后用浏览器打开后，就是这样了：
乱了有木有！这个其实和编辑器打开一个文件乱码的原理是一致的：即编辑器编码时所采用的字符编码和解码时所采用的字符编码不一致。上述栗子，我们在coding时采用的是GBK编码，但头部却告诉浏览器这个文档是UTF-8编码，那么浏览器在用UTF-8解码时就会出现了乱码。
我们在coding时需要告诉浏览器自己的文件采用了什么字符编码，下面列出一些常见的方法：
<meta charset="gb2312"> //html5
<meta http-equiv="Content-Type" content="text/html; charset=gb2312"> //html4 xhtml
<script src="http://ossweb-img.qq.com/images/js/foot.js" charset="gb2312"></script>
<link href="http://gameweb-img.qq.com/css/common.css" rel="stylesheet" charset="gb2312" >
我们可以在head区域的meta元素中为整个页面申明编码方式，也可以为单独的外链文件申明编码方式（link/script等元素）。问题是如果页面头部和外链文件中只有部分申明或者全部申明，那么对应的到底是以什么方式解码呢？这里就有一个优先级的问题，具体的判定关系如下：
通过上述判定，我们其实可以发现，一个页面中优先级最高的其实是服务端的编码设置，如果一旦服务端设置了编码A，那么页面即以A来解析。 目前Google采用的是这一做法，这样的传输效率会更高，不需要在头部额外再单独申明编码，但这样其实也有一定的风险，除了需要有一个严谨的编码规范，还需要确保服务器上的页面都保持同一编码，一旦不一致就会造成乱码，所以目前这一方案在国内用的并不多。 其他的，如果外链资源设置了编码C，那么即以C来解析，无论服务端和头部是否申明编码。 但必须要提醒大家的是：申明的编码只是告诉浏览器相关的内容是以什么方案去解码，并不是这一部分内容就采用了这个编码。所以大家在coding时的编码一定要确保和你申明的保持统一，不然就会出现乱码的问题。
BOM是byte-order mark的缩写，为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中是不存在的字符，也叫做“ZERO WIDTH NO-BREAK SPACE”，那么就表明这个文件的字节流是Big-Endian（高字节在前）的；如果收到“FFFE”，就表明字节流是Little-Endian（低字节在前）。
在UTF-8文件中放置BOM主要是微软的习惯，BOM其实是为UTF-16和UTF-32准备的，微软在UTF-8使用BOM是因为这样可以把UTF-8和ASCII等编码明确区分开，但这样的文件在Window以外的其他操作系统里会带来问题。
我们以Window下的文本文件为例：
在保存时可以选择ANSI、Unicode、Unicode big endian和UTF-8四种编码方式。
目前UTF-16通常用于系统文件的编码，而UTF-32由于对每个字符都采用四个字节编码，所以现在互联网中大部分都采用UTF-8来进行编码传输。
（左图：中国地区ALEXA排名前20的站点所采用的编码占比） （右图：腾讯互娱所有业务所采用的编码占比）
左图表明GB2312、GBK与UTF-8编码三分天下，而右图显示腾讯互娱的业务大多数采用了GB2312，零星的采用了其他编码。总的就是不同的字符编码方案基本都存在了，而这也与各公司业务的历史原因也有一定的关系。 当我们在项目的最初期时采用了一种非Unicode编码方案时，随着业务的壮大，积累的页面越来越多，到后期想去改成Unicode编码方案，就会担心出错的问题，所以现在大多数公司都采用了延用初期编码的方式，如淘宝，腾讯互娱等，以及四大门户。
可是，某一天了，我们的网站用户港澳台用户也变多了，我们需要支持繁体怎么办？
某一天，我们的业务拓展到东南亚了，我们需要我们的网站也能支持那些国家的语言怎么办？
如今，国内大多数公司采用的方案是，为相应的环境单独做一套编码文件，如 http://big5.china.com.cn/ ，又如 http://big5.qidian.com。
再比如，哪一天了，我们的网站需要支持少数民族的语言怎么办？
难道像某某企业这样切成图么？
嗯，这一切都只是暂时的方案，但人一旦变得懒起来，就不愿意去改变一些东西，就比如UTF-8。
一切就等着我们敞开胸怀去拥抱，而不是沉浸在过去的喜悦中。最终的编码方案决定权在我们自己手里，改变，只是时间的问题。
参考资源及文献列表：
http://zh.wikipedia.org/wiki/ISO_10646
http://zh.wikipedia.org/wiki/%E4%BD%8D%E5%85%83%E7%B5%84%E9%A0%86%E5%BA%8F%E8%A8%98%E8%99%9F
http://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.htmlhttp://www.imkevinyang.com/2010/06/%E5%85%B3%E4%BA%8E%E5%AD%97%E7%AC%A6%E7%BC%96%E7%A0%81%EF%BC%8C%E4%BD%A0%E6%89%80%E9%9C%80%E8%A6%81%E7%9F%A5%E9%81%93%E7%9A%84.htmlhttp://zh.wikipedia.org/wiki/Gb2312 http://zh.wikipedia.org/wiki/GBK http://zh.wikipedia.org/wiki/GB18030
http://www.cnblogs.com/skynet/archive/2011/05/03/2035105.html
字符编码的前世今生（Unicode，UTF, GB2312）
标签：-- logs htm style 转化 重要 pre 常用 info
原文地址：http://www.cnblogs.com/javazs/p/7738607.html
