字符编码的前世此生

　　今天咱们不谈编程，来聊聊历史（笑=-=）

　　同窗们请先思考一个问题：咱们只有十支手指，那么怎么用这十支手指表示超过10的数呢？好比说23！

　　...

　　在好久好久之前，在没有文字的年代，老古人结绳计数，一个结表明一个数字！

　　...

　　当年周幽王烽火戏诸侯，只是为得美人一笑，咱们就来聊一聊周幽王是怎么想的（=-=！），古时候通讯是最大的问题，打仗的时候经过烽火台传递敌情。根据敌情的不一样，有着不一样的规定。如一道烽火表明500人如下，两道表明500~1000，三道表明1000到5000.。。。依次类推。其实这就是进制的雏形，经过不一样数位表明不一样的权重，来表示更大的数据。

　　不扯这些了，回归正题，如今的计算机仍然很弱小，你觉得计算机能够存储成千上万种的语言，你觉得计算机能够储存任何文件，例如图片、视频，你觉得计算机能够作任何计算，其实不是这样的，计算机要比咱们想象中弱小的多，就算他再表现的强大，表现的更加人性化，他也只能认识0和1，只能处理二进制数据，这是咱们站在如今的角度去思考前人处理问题的方式，如今咱们站在前人的角度来想。1945年美国宾夕法尼亚大学的两位教授-莫奇利和埃克特设计和研制出了世界上第一台计算机ENIAC(电子数字积分计算机）。如今咱们有了第一台计算机，可是这个计算机只认识0和1，这就须要咱们找到一个方法让计算机“认识”其余数据，这就是编码（英语：encode），经过编码的方式将咱们须要计算机认识的数据转换为二进制，让计算机处理后，再解码（英语：decode）呈现给咱们，除了计算机设计工做人员，其余人通常不须要关心计算机是如何编码和解码的。

声明：如下关于编码的介绍转自：腾讯游戏官方设计团队

ASCII

　　8个晶体管的“通”或“断”便可以表明一个字节，刚开始，计算机只在美国使用，全部的信息在计算机最底层都是以二进制（“0”或“1”两种不一样的状态）的方式存储，而8位的字节一共能够组合出256（2的8次方）种状态，即256个字符，这对于当时的美国已是足够的了，他们尝试把一些终端的动做、字母、数字和符号用8位(bit)来组合：

• 0000 0000 ~ 0001 1111 共 33 种状态用来表示终端的特殊动做，如打印机中的响铃为 0000 0111 ，当打印机遇到 0000 0111 这样的字节传过来时，打印机就开始响铃；
• 0010 0000 ~ 0010 1111 、 0011 1010~0110 0000 和 0111 1101 ~ 0111 1110 共 33 种状态来表示英式标点符号，如 0011 1111 即表明英式问号“?”；
• 0011 0000 ~ 0011 1001 共 10 种状态来表示“0~9”10个阿拉伯数字；
• 0100 0001 ~ 0101 1010 和 0110 0001 ~ 0111 1010共 52种状态来表示大小写英文字母；

　　自此，一共只用到了128种状态，即128个字符，恰好占用了一个字节中的后7位，共包括33个控制字符和95个可显示字符，这一字符集被称为ASCII（American Standard Code for Information Interchange，美国信息交换标准代码），这一套字符集在1967年被正式公布。

讲到这里，引出几个基础概念：

• 比特（bit）：也可称为“位”，是计算机信息中的最小单位，是 binary digit（二进制数位） 的 缩写，指二进制中的一位
• 字节（Byte）：计算机中信息计量的一种单位，一个位就表明“0”或“1”，每8个位（bit）组成一个字节（Byte）
• 字符（Character）：文字与符号的总称，能够是各个国家的文字、标点符号、图形符号、数字等
• 字符集（Character Set）：是多个字符的集合
• 编码（Encoding）： 信息从一种形式或格式转换为另外一种形式的过程
• 解码（decoding）： 编码的逆过程
• 字符编码（Character Encoding）： 按照何种规则存储字符

如今咱们来看咱们文章开头提到的第一条电报的诞生，莫尔斯编码中包含了大小写英文字母和数字等符号。

• 这里的每个符号其实就是⌈字符⌋，
• 而这全部的字符的集合就叫作⌈字符集⌋，
• “点”或“划”与字符之间的对应关系便可以称为⌈字符编码⌋。

而电报的原理是：

“点”对应于短的电脉冲信号，“划”对应于长的电脉冲信号，这些信号传到对方，接收机把短的电脉冲信号翻译成“点”，把长的电脉冲信号转换成“划”，译码员根据这些点划组合就能够译成英文字母，从而完成了通讯任务。

• 这里把字符表示为“点”或“划”并对应为电脉冲信号的过程既是⌈编码⌋，
• 而译码员把接收机接收到的脉冲信号转化成点划后译成字符的过程即为⌈解码⌋。

而对于计算机诞生以后，只不过是将摩斯电码中的“点”和“划”换成了以8位字节二进制流的方式表示，如数字1的二进制流是0011 0001，对应的十进制流是49，十六进制流是31。

EASCII

　　虽然刚开始计算机只在美国使用，128个字符的确是足够了，但随着科技惊人的发展，欧洲国家也开始使用上计算机了。不过128个字符明显不够呀，好比法语中，字母上方有注音符号，因而，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。好比，法语的é的二进制流为1000 0010，这样一来，这些欧洲国家的编码体系，能够表示最多256个字符了。 可是，这里又出现了新的问题。不一样的国家有不一样的字母，所以，哪怕它们都使用256个符号的编码方式，表明的字母却不同。好比，1000 0010在法语编码中表明了é，在希伯来语编码中却表明了字母Gimel (?)，在俄语编码中又会表明另外一个符号。可是无论怎样，全部这些编码方式中，0--127表示的符号是同样的，不同的只是128--255的这一段。 EASCII（Extended ASCII，延伸美国标准信息交换码）由此应运而生，EASCII码比ASCII码扩充出来的符号包括表格符号、计算符号、希腊字母和特殊的拉丁符号:

GB2312

　　EASCII码对于部分欧洲国家基本够用了，但事后的不久，计算机便来到了中国，要知道汉字是世界上包含符号最多而且也是最难学的文字。 据不彻底统计，汉字共包含了古文、现代文字等近10万个文字，就是咱们如今平常用的汉字也有几千个，那么对于只包含256个字符的EASCII码也难以知足天朝的需求了。 因而⌈中国国家标准总局⌋（现已改名为⌈国家标准化管理委员会⌋）在1981年，正式制订了中华人民共和国国家标准简体中文字符集，全称《信息交换用汉字编码字符集·基本集》，项目代号为GB 2312 或 GB 2312-80（GB为国标汉语拼音的首字母），此套字符集于当年的5月1日起正式实施。

• 　　包含字符：共包含7445个字符，6763个汉字和682个其余字符（拉丁字母、希腊字母、日文平假名及片假名字母、俄语西里尔字母）

• 　　存储方式：基于EUC存储方式，每一个汉字及符号以两个字节来表示，第一个字节为“高位字节”，第二个字节为“低位字节”

BIG5

　　要知道港澳台同胞使用的是繁体字，而中国大陆制定的GB2312编码并不包含繁体字，因而信息工业策进会在1984年与台湾13家厂商签订“16位我的电脑套装软件合做开发（BIG-5）计划”，并开始编写并推出BIG5标准。 以后推出的倚天中文系统则基于BIG5码，并在台湾地区取得了巨大的成功。在BIG5诞生后，大部分的电脑软件都使用了Big5码，BIG5对于以台湾为核心的亚洲繁体汉字圈产生了久远的影响，以致于后来的window 繁体中文版系统在台湾地区也基于BIG5码进行开发。

　　包含字符：共收录13,060个汉字及441个符号

　　编码方式：用两个字节来为每一个字符编码，第一个字节称为“高位字节”，第二个字节称为“低位字节”

Unicode

由来：

在计算机进入中国大陆的相同时期，计算机也迅速发展进入了世界各个国家。 特别是对于亚洲国家而言，每一个国家都有本身的文字，因而每一个国家或地区都像中国大陆这样去制定了本身的编码标准，以便能在计算机上正确显示本身国家的符号。 但带来的结果就是国家之间谁也不懂别人的编码，谁也不支持别人的编码，连大陆和台湾这样只相隔了150海里，都使用了不一样的编码体系。 因而，世界相关组织意识到了这个问题，并开始尝试制定统一的编码标准，以便可以收纳世界全部国家的文字符号。 在前期有两个尝试这一工做的组织：

• 国际标准化组织（ISO）
• 统一码联盟

国际标准化组织（ISO）及国际电工委员会（IEC）于1984年联合成立了ISO/IEC小组，主要用于开发统一编码项目； 而Xerox、Apple等软件制造商则于1988年组成了统一码联盟，用于开发统一码项目。 两个组织都在编写统一字符集，但后来他们发现各自在作相同的工做，同时世界上也不须要两个不兼容的字符集，因而两个组织就此合并了双方的工做成果，并为创立一个单一编码表而协同工做。

1991年，两个组织共同的工做成果Unicode 1.0正式发布，不过Unicode 1.0并不包含CJK字符（即中日韩）。

Unicode 1.0：1991年10月 Unicode 1.0.1：1992年6月 Unicode 1.1：1993年6月 Unicode 2.0：1997年7月 Unicode 2.1：1998年5月 Unicode 2.1.2：1998年5月 Unicode 3.0：1999年9月 Unicode 3.1：2001年3月 Unicode 3.2：2002年3月 Unicode 4.0：2003年4月 Unicode 4.0.1：2004年3月 Unicode 4.1：2005年3月 Unicode 5.0：2006年7月 Unicode 5.1：2008年4月 Unicode 5.2：2009年10月 Unicode 6.0：2010年10月 Unicode 4.1：2005年3月 Unicode 6.1：2012年1月31日 Unicode 6.2：2012年9月

ISO/IEC 8859

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

• ISO/IEC 8859-1：西欧语言
• ISO/IEC 8859-2  ：中欧语言
• ISO/IEC 8859-3 ：南欧语言
• ISO/IEC 8859-4： 北欧语言
• ISO/IEC 8859-5： 斯拉夫语
• ISO/IEC 8859-6： 阿拉伯语
• ISO/IEC 8859-7：希腊语
• ISO/IEC 8859-8：希伯来语
• ISO/IEC 8859-9：土耳其语
• ISO/IEC 8859-10： 北日耳曼语
• ISO/IEC 8859-11：泰语
• ISO/IEC 8859-13： 波罗的语族
• ISO/IEC 8859-14： 凯尔特语族
• ISO/IEC 8859-15：西欧语言，收录芬兰语字母和大写法语重音字母，以及欧元（€）符号
• ISO/IEC 8859-16 ：东南欧语言，主要供罗马尼亚语使用，并加入欧元（€）符号

其中ISO/IEC 8859-1至ISO/IEC 8859-4四个项目早在1982年就已经编写出来，只不过是由ANSI与ECMA合做完成，并于1985年正式公布，ISO/IEC小组成立后，这一成果被其收录，并更名为ISO/IEC 8859 前四个项目。 你们其实发现以上15个字符集中并无代号为“ISO/IEC 8859 -12”的字符集，听说-12号原本是预留给印度天城体梵文的，但后来却搁置了（阿三有了本身的编码－ISCII）。因为英语没有任何重音字母，故可以使用以上十五个字符集中的任何一个来表示。

 ISO/IEC 10646 / UCS

1993年，ISO/IEC 10646标准第一次发表，ISO/IEC 10646是ISO 646的扩展，定义了1个31位的字符集。ISO 10646标准中定义的字符集为UCS，UCS是Universal Character Set的缩写，中文译做通用字符集。

版本：

• ISO/IEC 10646-1：第一次发表于1993年，如今的公开版本是2000年发表的ISO/IEC 10646-1:2000。
• ISO/IEC 10646-2：在2001年发表。

包含字符：

最初的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亿个字符哪怕是整个宇宙也够用了吧！

UTF

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采用可变字节编码，这样能够大大节省带宽，并增长网络传输效率。

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的Unicode 1.1已经发布了，天朝的ZF也意识到了须要一个更大的字符集来走向世界，因而在同一年，中国大陆制定了几乎等同于Unicode1.1的GB13000.1-93国家编码标准（简称GB13000）。是的，你没听错，中华人民共和国信息产业部把Unicode里的全部东东拿过来，而后本身从新修订发布了下，改成了国家标准GB13000。此标准等同于 ISO/IEC 10646.1:1993和Unicode 1.1。

GBK

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一样是用两个字节为每一个字符进行编码。

GB18030

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

版本：

• GB 18030-2000
• GB 18030-2005

包含字符：

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方式对此页面进行解码，“小海”两个字则能够被正确的显示出来。

乱码是个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时须要告诉浏览器本身的文件采用了什么字符编码，下面列出一些常见的方法：

<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是个神马

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四种编码方式。

• 其中ANSI是默认的编码方式，对于英文文件是ASCII编码，对于简体中文文件是GB2312编码（只针对Windows简体中文版，若是是繁体中文版会采用Big5码）；
• Unicode实际上是UTF-16 endian big编码方式，这个把带有BOM的小端序UTF-16称做Unicode而又不详细说明，也是微软的习惯；
• 而Unicode big endian则是带有BOM的大端序编码方式

目前UTF-16一般用于系统文件的编码，而UTF-32因为对每一个字符都采用四个字节编码，因此如今互联网中大部分都采用UTF-8来进行编码传输。

关于将来的展望

概述

（左图：中国地区ALEXA排名前20的站点所采用的编码占比）                  （右图：腾讯互娱全部业务所采用的编码占比）

左图代表GB23十二、GBK与UTF-8编码三分天下，而右图显示腾讯互娱的业务大多数采用了GB2312，零星的采用了其余编码。总的就是不一样的字符编码方案基本都存在了，而这也与各公司业务的历史缘由也有必定的关系。 当咱们在项目的最初期时采用了一种非Unicode编码方案时，随着业务的壮大，积累的页面愈来愈多，到后期想去改为Unicode编码方案，就会担忧出错的问题，因此如今大多数公司都采用了延用初期编码的方式，如淘宝，腾讯互娱等，以及四大门户。

摆在眼前的问题

但是，某一天了，咱们的网站用户港澳台用户也变多了，咱们须要支持繁体怎么办？

某一天，咱们的业务拓展到东南亚了，咱们须要咱们的网站也能支持那些国家的语言怎么办？

现在，国内大多数公司采用的方案是，为相应的环境单独作一套编码文件，如 http://big5.china.com.cn/ ，又如 http://big5.qidian.com。

再好比，哪一天了，咱们的网站须要支持少数民族的语言怎么办？

难道像某某企业这样切成图么？

嗯，这一切都只是暂时的方案，但人一旦变得懒起来，就不肯意去改变一些东西，就好比UTF-8。

拥抱国际化标准

一切就等着咱们敞开胸怀去拥抱，而不是沉浸在过去的喜悦中。最终的编码方案决定权在咱们本身手里，改变，只是时间的问题。