code

特别编码

; U+003B | 分号 | Unicode统一码符号库 ✏️
https://www.fuhaoku.net/U+003B

; U+037E | 希腊问号 | Unicode统一码符号库 ✏️
https://www.fuhaoku.net/U+037E

编码，浏览精品文章“字符编码的前世今生”即可，下面是链接

http://djt.qq.com/article/view/658?locate=comment#comment

https://tgideas.qq.com/webplat/info/news_version3/804/808/811/m579/201307/218730.shtml

链接失效的话，在当前文件夹的code-article有存档

http://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.html 字符编码笔记：ASCII，Unicode 和 UTF-8

RFC 2279 UTF-8: https://www.ietf.org/rfc/rfc2279.txt?number=2279

对于编码有正码，反码，补码操作，另外对于编码的数据，有一点很重要，那就是

字符编码 - 知识普及
https://www.52wiki.cn/Doc/Read/id/170.html

不管怎么存，只管怎么读

字符集和编码

随便说说字符集和编码

快下班时，爱问问题的小朋友Nico又问了一个问题：
"sqlserver里面有char和nchar，那个n据说是指unicode的数据，这个是什么意思。"
并不是所有简单的问题都很容易回答，就像这个问题一样。于是我答应专门写一篇BLOG来从头讲讲编码的故事。那么就让我们找个草堆坐下，先抽口烟，看看夜晚天空上的银河，然后想一想要从哪里开始讲起。嗯，也许这样开始比较好……

很久很久以前，有一群人，他们决定用8个可以开合的晶体管来组合成不同的状态，以表示世界上的万物。他们看到8个开关状态是好的，于是他们把这称为"字节"。
再后来，他们又做了一些可以处理这些字节的机器，机器开动了，可以用字节来组合出很多状态，状态开始变来变去。他们看到这样是好的，于是它们就这机器称为"计算机"。

开始计算机只在美国用。八位的字节一共可以组合出256(2的8次方)种不同的状态。
他们把其中的编号从0开始的32种状态分别规定了特殊的用途，一但终端、打印机遇上约定好的这些字节被传过来时，就要做一些约定的动作。遇上00x10, 终端就换行，遇上0x07, 终端就向人们嘟嘟叫，例好遇上0x1b, 打印机就打印反白的字，或者终端就用彩色显示字母。他们看到这样很好，于是就把这些0x20以下的字节状态称为"控制码"。
他们又把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示，一直编到了第127号，这样计算机就可以用不同字节来存储英语的文字了。大家看到这样，都感觉很好，于是大家都把这个方案叫做 ANSI 的"Ascii"编码（American Standard Code for Information Interchange，美国信息互换标准代码）。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。
后来，就像建造巴比伦塔一样，世界各地的都开始使用计算机，但是很多国家用的不是英文，他们的字母里有许多是ASCII里没有的，为了可以在计算机保存他们的文字，他们决定采用127号之后的空位来表示这些新的字母、符号，还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了最后一个状态255。从128到255这一页的字符集被称"扩展字符集"。从此之后，贪婪的人类再没有新的状态可以用了，美帝国主义可能没有想到还有第三世界国家的人们也希望可以用到计算机吧！
等中国人们得到计算机时，已经没有可以利用的字节状态来表示汉字，况且有6000多个常用汉字需要保存呢。但是这难不倒智慧的中国人民，我们不客气地把那些127号之后的奇异符号们直接取消掉, 规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的"全角"字符，而原来在127号以下的那些就叫"半角"字符了。
中国人民看到这样很不错，于是就把这种汉字方案叫做 "GB2312"。GB2312 是对 ASCII 的中文扩展。
但是中国的汉字太多了，我们很快就就发现有许多人的人名没有办法在这里打出来，特别是某些很会麻烦别人的国家领导人。于是我们不得不继续把 GB2312 没有用到的码位找出来老实不客气地用上。
后来还是不够用，于是干脆不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为 GBK 标准，GBK 包括了 GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。
后来少数民族也要用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK 扩成了 GB18030。从此之后，中华民族的文化就可以在计算机时代中传承了。
中国的程序员们看到这一系列汉字编码的标准是好的，于是通称他们叫做 "DBCS"（Double Byte Charecter Set 双字节字符集）。在DBCS系列标准里，最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里，因此他们写的程序为了支持中文处理，必须要注意字串里的每一个字节的值，如果这个值是大于127的，那么就认为一个双字节字符集里的字符出现了。那时候凡是受过加持，会编程的计算机僧侣们都要每天念下面这个咒语数百遍：
"一个汉字算两个英文字符！一个汉字算两个英文字符……"

因为当时各个国家都像中国这样搞出一套自己的编码标准，结果互相之间谁也不懂谁的编码，谁也不支持别人的编码，连大陆和台湾这样只相隔了150海里，使用着同一种语言的兄弟地区，也分别采用了不同的 DBCS 编码方案――当时的中国人想让电脑显示汉字，就必须装上一个"汉字系统"，专门用来处理汉字的显示、输入的问题，但是那个台湾的愚昧封建人士写的算命程序就必须加装另一套支持 BIG5 编码的什么"倚天汉字系统"才可以用，装错了字符系统，显示就会乱了套！这怎么办？而且世界民族之林中还有那些一时用不上电脑的穷苦人民，他们的文字又怎么办？
真是计算机的巴比伦塔命题啊！
正在这时，大天使加百列及时出现了――一个叫 ISO （国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号的编码！他们打算叫它"Universal Multiple-Octet Coded Character Set"，简称 UCS, 俗称 "UNICODE"。
UNICODE 开始制订时，计算机的存储器容量极大地发展了，空间再也不成为问题了。于是 ISO 就直接规定必须用两个字节，也就是16位来统一表示所有的字符，对于ascii里的那些“半角”字符，UNICODE 包持其原编码不变，只是将其长度由原来的8位扩展为16位，而其他文化和语言的字符则全部重新统一编码。由于"半角"英文符号只需要用到低8位，所以其高8位永远是0，因此这种大气的方案在保存英文文本时会多浪费一倍的空间。
这时候，从旧社会里走过来的程序员开始发现一个奇怪的现象：他们的strlen函数靠不住了，一个汉字不再是相当于两个字符了，而是一个！是的，从 UNICODE 开始，无论是半角的英文字母，还是全角的汉字，它们都是统一的"一个字符"！同时，也都是统一的"两个字节"，请注意"字符"和"字节"两个术语的不同，“字节”是一个8位的物理存贮单元，而“字符”则是一个文化相关的符号。在UNICODE 中，一个字符就是两个字节。一个汉字算两个英文字符的时代已经快过去了。
从前多种字符集存在时，那些做多语言软件的公司遇上过很大麻烦，他们为了在不同的国家销售同一套软件，就不得不在区域化软件时也加持那个双字节字符集咒语，不仅要处处小心不要搞错，还要把软件中的文字在不同的字符集中转来转去。UNICODE 对于他们来说是一个很好的一揽子解决方案，于是从 Windows NT 开始，MS 趁机把它们的操作系统改了一遍，把所有的核心代码都改成了用 UNICODE 方式工作的版本，从这时开始，WINDOWS 系统终于无需要加装各种本土语言系统，就可以显示全世界上所有文化的字符了。
但是，UNICODE 在制订时没有考虑与任何一种现有的编码方案保持兼容，这使得 GBK 与UNICODE 在汉字的内码编排上完全是不一样的，没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换，这种转换必须通过查表来进行。
如前所述，UNICODE 是用两个字节来表示为一个字符，他总共可以组合出65535不同的字符，这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系，ISO已经准备了UCS-4方案，说简单了就是四个字节来表示一个字符，这样我们就可以组合出21亿个不同的字符出来（最高位有其他用途），这大概可以用到银河联邦成立那一天吧！

UNICODE 来到时，一起到来的还有计算机网络的兴起，UNICODE 如何在网络上传输也是一个必须考虑的问题，于是面向传输的众多 UTF（UCS Transfer Format）标准出现了，顾名思义，UTF8就是每次8个位传输数据，而UTF16就是每次16个位，只不过为了传输时的可靠性，从UNICODE到UTF时并不是直接的对应，而是要过一些算法和规则来转换。
受到过网络编程加持的计算机僧侣们都知道，在网络里传递信息时有一个很重要的问题，就是对于数据高低位的解读方式，一些计算机是采用低位先发送的方法，例如我们PC机采用的 INTEL 架构，而另一些是采用高位先发送的方式，在网络中交换数据时，为了核对双方对于高低位的认识是否是一致的，采用了一种很简便的方法，就是在文本流的开始时向对方发送一个标志符――如果之后的文本是高位在位，那就发送"FEFF"，反之，则发送"FFFE"。不信你可以用二进制方式打开一个UTF-X格式的文件，看看开头两个字节是不是这两个字节？

讲到这里，我们再顺便说说一个很著名的奇怪现象：当你在 windows 的记事本里新建一个文件，输入"联通"两个字之后，保存，关闭，然后再次打开，你会发现这两个字已经消失了，代之的是几个乱码！呵呵，有人说这就是联通之所以拼不过移动的原因。
其实这是因为GB2312编码与UTF8编码产生了编码冲撞的原因。
从网上引来一段从UNICODE到UTF8的转换规则：

Unicode
UTF-8

0000 - 007F
0xxxxxxx

0080 - 07FF
110xxxxx 10xxxxxx

0800 - FFFF
1110xxxx 10xxxxxx 10xxxxxx

例如"汉"字的Unicode编码是6C49。6C49在0800-FFFF之间，所以要用3字节模板：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 1100 0100 1001，将这个比特流按三字节模板的分段方法分为0110 110001 001001，依次代替模板中的x，得到：1110-0110 10-110001 10-001001，即E6 B1 89，这就是其UTF8的编码。
而当你新建一个文本文件时，记事本的编码默认是ANSI, 如果你在ANSI的编码输入汉字，那么他实际就是GB系列的编码方式，在这种编码下，"联通"的内码是：
c1 1100 0001
aa 1010 1010
cd 1100 1101
a8 1010 1000
注意到了吗？第一二个字节、第三四个字节的起始部分的都是"110"和"10"，正好与UTF8规则里的两字节模板是一致的，于是再次打开记事本时，记事本就误认为这是一个UTF8编码的文件，让我们把第一个字节的110和第二个字节的10去掉，我们就得到了"00001 101010"，再把各位对齐，补上前导的0，就得到了"0000 0000 0110 1010"，不好意思，这是UNICODE的006A，也就是小写的字母"j"，而之后的两字节用UTF8解码之后是0368，这个字符什么也不是。这就是只有"联通"两个字的文件没有办法在记事本里正常显示的原因。
而如果你在"联通"之后多输入几个字，其他的字的编码不见得又恰好是110和10开始的字节，这样再次打开时，记事本就不会坚持这是一个utf8编码的文件，而会用ANSI的方式解读之，这时乱码又不出现了。

好了，终于可以回答NICO的问题了，在数据库里，有n前缀的字串类型就是UNICODE类型，这种类型中，固定用两个字节来表示一个字符，无论这个字符是汉字还是英文字母，或是别的什么。
如果你要测试"abc汉字"这个串的长度，在没有n前缀的数据类型里，这个字串是7个字符的长度，因为一个汉字相当于两个字符。而在有n前缀的数据类型里，同样的测试串长度的函数将会告诉你是5个字符，因为一个汉字就是一个字符。

字符编码的前世今生

文章链接：

http://djt.qq.com/article/view/658?locate=comment#comment

https://tgideas.qq.com/webplat/info/news_version3/804/808/811/m579/201307/218730.shtml

由于“字符编码”这个话题牵涉到的历史久远、机构众多、专业术语较多，所以本篇文章可能会略长，为了避免内容过于枯燥，我会尽量用一种通俗易懂的语言来写这篇文章。
其中本文的第一篇章会对历史中的主要字符编码进行介绍，由于篇幅较长，如果读者对此已很了解，可直接跳过进行第二章的阅读。
完成本篇文章的过程中参考和阅读了大量的文章和文献，写本篇文章的目的一是让自己对“字符编码”能够做一个较深的理解，二是希望给曾经徘徊或正在徘徊在编码困惑中的前端们一个很好的参考，搞清楚字符编码问题是前端万事之基石。
由于本人才疏学浅，好多信息也是从网络和书籍中参考而来，错误之处难免，请大家指正。
------------------题记

跟随历史的足迹看字符编码

古代的通信方式

很久很久以前，人们之间的长途通讯主要是用信鸽、骑马送报、烽烟等方式进行：

世界第一条电报

直到1837年，世界第一条电报诞生，当时美国科学家莫尔斯尝试用一些“点”和“划”来表示不同的字母、数字和标点符号，这套表示字符的方式也被称为“摩尔斯电码”：

世界第一台计算机

再后来到了1946年，世界第一台计算机诞生。发明计算机的同学们用8个晶体管的“通”或“断”组合出一些状态来表示世间万物，不过当时的计算机有一间半教室那么大，六头大象重，从现在看来这简直就是个怪物，但在当时却是震惊世界与改变世界的一项重要发明：

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区域中的的作用则是告诉浏览器此文档以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 Little endian 编码方式，这个把带有BOM的小端序UTF-16称作Unicode而又不详细说明，也是微软的习惯；
而Unicode big endian则是带有BOM的大端序编码方式

目前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。

拥抱国际化标准

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

参考资源及文献列表：

UNICODE编码UTF-16 中的Endian（FE FF）和 Little Endian（FF FE）

https://www.cnblogs.com/yzl050819/p/6667702.html

从网上找到的两篇不错的文章，由于被网上多处转载，所以不知道源处，未能注明出处，希望作者见谅，如有意见请发信给我，谢谢！

第一篇很清晰。

介绍Unicode之前，首先要讲解一些基础知识。虽然跟Unicode没有直接的关系，但想弄明白Unicode，没这些还真不行。

字节和字符的区别

咦，字节和字符能有什么区别啊？不都是一样的吗？完全正确，但只是在古老的DOS时代。当Unicode出现后，字节和字符就不一样了。

字节（octet）是一个八位的存储单元，取值范围一定是0～255。而字符（character，或者word）为语言意义上的符号，范围就不一定了。例如在UCS-2中定义的字符范围为0～65535，它的一个字符占用两个字节。

Big Endian和Little Endian

上面提到了一个字符可能占用多个字节，那么这多个字节在计算机中如何存储呢？比如字符0xabcd，它的存储格式到底是 AB CD，还是 CD AB 呢？

实际上两者都有可能，并分别有不同的名字。如果存储为 AB CD，则称为Big Endian；如果存储为 CD AB，则称为Little Endian。

具体来说，以下这种存储格式为Big Endian，因为值(0xabcd)的高位(0xab)存储在前面：

地址	值
0x00000000	AB
0x00000001	CD

相反，以下这种存储格式为Little Endian：

地址	值
0x00000000	CD
0x00000001	AB

UCS-2和UCS-4

Unicode是为整合全世界的所有语言文字而诞生的。任何文字在Unicode中都对应一个值，这个值称为代码点（code point）。代码点的值通常写成 U+ABCD 的格式。而文字和代码点之间的对应关系就是UCS-2（Universal Character Set coded in 2 octets）。顾名思义，UCS-2是用两个字节来表示代码点，其取值范围为 U+0000～U+FFFF。

为了能表示更多的文字，人们又提出了UCS-4，即用四个字节表示代码点。它的范围为 U+00000000～U+7FFFFFFF，其中 U+00000000～U+0000FFFF和UCS-2是一样的。

要注意，UCS-2和UCS-4只规定了代码点和文字之间的对应关系，并没有规定代码点在计算机中如何存储。规定存储方式的称为UTF（Unicode Transformation Format），其中应用较多的就是UTF-16和UTF-8了。

UTF-16和UTF-32

UTF-16

UTF-16由RFC2781规定，它使用两个字节来表示一个代码点。

不难猜到，UTF-16是完全对应于UCS-2的，即把UCS-2规定的代码点通过Big Endian或Little Endian方式直接保存下来。UTF-16包括三种：UTF-16，UTF-16BE（Big Endian），UTF-16LE（Little Endian）。

UTF-16BE和UTF-16LE不难理解，而UTF-16就需要通过在文件开头以名为BOM（Byte Order Mark）的字符来表明文件是Big Endian还是Little Endian。BOM为U+FEFF这个字符。

其实BOM是个小聪明的想法。由于UCS-2没有定义U+FFFE，因此只要出现 FF FE 或者 FE FF 这样的字节序列，就可以认为它是U+FEFF，并且可以判断出是Big Endian还是Little Endian。

举个例子。“ABC”这三个字符用各种方式编码后的结果如下：

UTF-16BE	00 41 00 42 00 43
UTF-16LE	41 00 42 00 43 00
UTF-16(Big Endian)	FE FF 00 41 00 42 00 43
UTF-16(Little Endian)	FF FE 41 00 42 00 43 00
UTF-16(不带BOM)	00 41 00 42 00 43

Windows平台下默认的Unicode编码为Little Endian的UTF-16（即上述的 FF FE 41 00 42 00 43 00）。你可以打开记事本，写上ABC，然后保存，再用二进制编辑器看看它的编码结果。

另外，UTF-16还能表示一部分的UCS-4代码点——U+10000～U+10FFFF。表示算法比较复杂，简单说明如下：

从代码点U中减去0x10000，得到U'。这样U+10000～U+10FFFF就变成了 0x00000～0xFFFFF。
用20位二进制数表示U'。 U'=yyyyyyyyyyxxxxxxxxxx
将前10位和后10位用W1和W2表示，W1=110110yyyyyyyyyy，W2=110111xxxxxxxxxx，则 W1 = D800～DBFF，W2 = DC00～DFFF。

例如，U+12345表示为 D8 08 DF 45（UTF-16BE），或者08 D8 45 DF（UTF-16LE）。

但是由于这种算法的存在，造成UCS-2中的 U+D800～U+DFFF 变成了无定义的字符。

UTF-32

UTF-32用四个字节表示代码点，这样就可以完全表示UCS-4的所有代码点，而无需像UTF-16那样使用复杂的算法。与UTF-16类似，UTF-32也包括UTF-32、UTF-32BE、UTF-32LE三种编码，UTF-32也同样需要BOM字符。仅用'ABC'举例：

UTF-32BE	00 00 00 41 00 00 00 42 00 00 00 43
UTF-32LE	41 00 00 00 42 00 00 00 43 00 00 00
UTF-32(Big Endian)	00 00 FE FF 00 00 00 41 00 00 00 42 00 00 00 43
UTF-32(Little Endian)	FF FE 00 00 41 00 00 00 42 00 00 00 43 00 00 00
UTF-32(不带BOM)	00 00 00 41 00 00 00 42 00 00 00 43

UTF-8

UTF-16和UTF-32的一个缺点就是它们固定使用两个或四个字节，这样在表示纯ASCII文件时会有很多00字节，造成浪费。而RFC3629定义的UTF-8则解决了这个问题。

UTF-8用1～4个字节来表示代码点。表示方式如下：

UCS-2 (UCS-4)	位序列	第一字节	第二字节	第三字节	第四字节
U+0000 .. U+007F	00000000-0xxxxxxx	0xxxxxxx
U+0080 .. U+07FF	00000xxx-xxyyyyyy	110xxxxx	10yyyyyy
U+0800 .. U+FFFF	xxxxyyyy-yyzzzzzz	1110xxxx	10yyyyyy	10zzzzzz
U+10000..U+1FFFFF	00000000-000wwwxx- xxxxyyyy-yyzzzzzzz	11110www	10xxxxxx	10yyyyyy	10zzzzzz

可见，ASCII字符（U+0000～U+007F）部分完全使用一个字节，避免了存储空间的浪费。而且UTF-8不再需要BOM字节。

另外，从上表中可以看出，单字节编码的第一字节为[00-7F]，双字节编码的第一字节为[C2-DF]，三字节编码的第一字节为[E0-EF]。这样只要看到第一个字节的范围就可以知道编码的字节数。这样也可以大大简化算法。

第二篇写得通俗易懂：

这篇就比较易懂了。
很久很久以前，有一群人，他们决定用8个可以开合的晶体管来组合成不同的状态，以表示世界上的万物。他们看到8个开关状态是好的，于是他们把这称为"字节"。
再后来，他们又做了一些可以处理这些字节的机器，机器开动了，可以用字节来组合出很多状态，状态开始变来变去。他们看到这样是好的，于是它们就这机器称为"计算机"。
开始计算机只在美国用。八位的字节一共可以组合出256(2的8次方)种不同的状态。
他们把其中的编号从0开始的32种状态分别规定了特殊的用途，一但终端、打印机遇上约定好的这些字节被传过来时，就要做一些约定的动作。遇上00x10, 终端就换行，遇上0x07, 终端就向人们嘟嘟叫，例好遇上0x1b, 打印机就打印反白的字，或者终端就用彩色显示字母。他们看到这样很好，于是就把这些0x20以下的字节状态称为"控制码"。
他们又把所有的空格、标点符号、数字、大小写字母分别用连续的字节状态表示，一直编到了第127号，这样计算机就可以用不同字节来存储英语的文字了。大家看到这样，都感觉很好，于是大家都把这个方案叫做 ANSI 的"Ascii"编码（American Standard Code for Information Interchange，美国信息互换标准代码）。当时世界上所有的计算机都用同样的ASCII方案来保存英文文字。
后来，就像建造巴比伦塔一样，世界各地的都开始使用计算机，但是很多国家用的不是英文，他们的字母里有许多是ASCII里没有的，为了可以在计算机保存他们的文字，他们决定采用 127号之后的空位来表示这些新的字母、符号，还加入了很多画表格时需要用下到的横线、竖线、交叉等形状，一直把序号编到了最后一个状态255。从128 到255这一页的字符集被称"扩展字符集"。从此之后，贪婪的人类再没有新的状态可以用了，美帝国主义可能没有想到还有第三世界国家的人们也希望可以用到计算机吧！
等中国人们得到计算机时，已经没有可以利用的字节状态来表示汉字，况且有6000多个常用汉字需要保存呢。但是这难不倒智慧的中国人民，我们不客气地把那些127号之后的奇异符号们直接取消掉, 规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到 0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的"全角"字符，而原来在127号以下的那些就叫"半角"字符了。
中国人民看到这样很不错，于是就把这种汉字方案叫做 "GB2312"。GB2312 是对 ASCII 的中文扩展。
但是中国的汉字太多了，我们很快就就发现有许多人的人名没有办法在这里打出来，特别是某些很会麻烦别人的国家领导人。于是我们不得不继续把 GB2312 没有用到的码位找出来老实不客气地用上。
后来还是不够用，于是干脆不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为 GBK 标准，GBK 包括了 GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。
后来少数民族也要用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK 扩成了 GB18030。从此之后，中华民族的文化就可以在计算机时代中传承了。
中国的程序员们看到这一系列汉字编码的标准是好的，于是通称他们叫做 "DBCS"（Double Byte Charecter Set 双字节字符集）。在DBCS系列标准里，最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里，因此他们写的程序为了支持中文处理，必须要注意字串里的每一个字节的值，如果这个值是大于127的，那么就认为一个双字节字符集里的字符出现了。那时候凡是受过加持，会编程的计算机僧侣们都要每天念下面这个咒语数百遍：
"一个汉字算两个英文字符！一个汉字算两个英文字符……"
因为当时各个国家都像中国这样搞出一套自己的编码标准，结果互相之间谁也不懂谁的编码，谁也不支持别人的编码，连大陆和台湾这样只相隔了150海里，使用着同一种语言的兄弟地区，也分别采用了不同的 DBCS 编码方案——当时的中国人想让电脑显示汉字，就必须装上一个"汉字系统"，专门用来处理汉字的显示、输入的问题，但是那个台湾的愚昧封建人士写的算命程序就必须加装另一套支持 BIG5 编码的什么"倚天汉字系统"才可以用，装错了字符系统，显示就会乱了套！这怎么办？而且世界民族之林中还有那些一时用不上电脑的穷苦人民，他们的文字又怎么办？
真是计算机的巴比伦塔命题啊！
正在这时，大天使加百列及时出现了——一个叫 ISO （国际标谁化组织）的国际组织决定着手解决这个问题。他们采用的方法很简单：废了所有的地区性编码方案，重新搞一个包括了地球上所有文化、所有字母和符号的编码！他们打算叫它"Universal Multiple-Octet Coded Character Set"，简称 UCS, 俗称 "UNICODE"。
UNICODE 开始制订时，计算机的存储器容量极大地发展了，空间再也不成为问题了。于是 ISO 就直接规定必须用两个字节，也就是16位来统一表示所有的字符，对于ascii里的那些“半角”字符，UNICODE 包持其原编码不变，只是将其长度由原来的8位扩展为16位，而其他文化和语言的字符则全部重新统一编码。由于"半角"英文符号只需要用到低8位，所以其高 8位永远是0，因此这种大气的方案在保存英文文本时会多浪费一倍的空间。
这时候，从旧社会里走过来的程序员开始发现一个奇怪的现象：他们的 strlen函数靠不住了，一个汉字不再是相当于两个字符了，而是一个！是的，从 UNICODE 开始，无论是半角的英文字母，还是全角的汉字，它们都是统一的"一个字符"！同时，也都是统一的"两个字节"，请注意"字符"和"字节"两个术语的不同， “字节”是一个8位的物理存贮单元，而“字符”则是一个文化相关的符号。在UNICODE 中，一个字符就是两个字节。一个汉字算两个英文字符的时代已经快过去了。
从前多种字符集存在时，那些做多语言软件的公司遇上过很大麻烦，他们为了在不同的国家销售同一套软件，就不得不在区域化软件时也加持那个双字节字符集咒语，不仅要处处小心不要搞错，还要把软件中的文字在不同的字符集中转来转去。UNICODE 对于他们来说是一个很好的一揽子解决方案，于是从 Windows NT 开始，MS 趁机把它们的操作系统改了一遍，把所有的核心代码都改成了用 UNICODE 方式工作的版本，从这时开始，WINDOWS 系统终于无需要加装各种本土语言系统，就可以显示全世界上所有文化的字符了。
但是，UNICODE 在制订时没有考虑与任何一种现有的编码方案保持兼容，这使得 GBK 与UNICODE 在汉字的内码编排上完全是不一样的，没有一种简单的算术方法可以把文本内容从UNICODE编码和另一种编码进行转换，这种转换必须通过查表来进行。
如前所述，UNICODE 是用两个字节来表示为一个字符，他总共可以组合出65535不同的字符，这大概已经可以覆盖世界上所有文化的符号。如果还不够也没有关系，ISO已经准备了UCS-4方案，说简单了就是四个字节来表示一个字符，这样我们就可以组合出21亿个不同的字符出来（最高位有其他用途），这大概可以用到银河联邦成立那一天吧！
UNICODE 来到时，一起到来的还有计算机网络的兴起，UNICODE 如何在网络上传输也是一个必须考虑的问题，于是面向传输的众多 UTF（UCS Transfer format）标准出现了，顾名思义，UTF8就是每次8个位传输数据，而UTF16就是每次16个位，只不过为了传输时的可靠性，从UNICODE到 UTF时并不是直接的对应，而是要过一些算法和规则来转换。
受到过网络编程加持的计算机僧侣们都知道，在网络里传递信息时有一个很重要的问题，就是对于数据高低位的解读方式，一些计算机是采用低位先发送的方法，例如我们PC机采用的 INTEL 架构，而另一些是采用高位先发送的方式，在网络中交换数据时，为了核对双方对于高低位的认识是否是一致的，采用了一种很简便的方法，就是在文本流的开始时向对方发送一个标志符——如果之后的文本是高位在位，那就发送"FEFF"，反之，则发送"FFFE"。不信你可以用二进制方式打开一个UTF-X格式的文件，看看开头两个字节是不是这两个字节？
讲到这里，我们再顺便说说一个很著名的奇怪现象：当你在 windows 的记事本里新建一个文件，输入"联通"两个字之后，保存，关闭，然后再次打开，你会发现这两个字已经消失了，代之的是几个乱码！呵呵，有人说这就是联通之所以拼不过移动的原因。
其实这是因为GB2312编码与UTF8编码产生了编码冲撞的原因。
从网上引来一段从UNICODE到UTF8的转换规则：
Unicode
UTF-8
0000 - 007F
0xxxxxxx
0080 - 07FF
110xxxxx 10xxxxxx
0800 - FFFF
1110xxxx 10xxxxxx 10xxxxxx

希望这篇文章是NICO想要的.

UTF-8编码规则（转）

UTF-8是Unicode的一种实现方式，也就是它的字节结构有特殊要求，所以我们说一个汉字的范围是0X4E00到0x9FA5，是指unicode值，至于放在utf-8的编码里去就是由三个字节来组织，所以可以看出unicode是给出一个字符的范围，定义了这个字是码值是多少，至于具体的实现方式可以有多种多样来实现。

UTF-8是一种变长字节编码方式。对于某一个字符的UTF-8编码，如果只有一个字节则其最高二进制位为0；如果是多字节，其第一个字节从最高位开始，连续的二进制位值为1的个数决定了其编码的位数，其余各字节均以10开头。UTF-8最多可用到6个字节。
如表：
1字节 0xxxxxxx
2字节 110xxxxx 10xxxxxx
3字节 1110xxxx 10xxxxxx 10xxxxxx
4字节 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
5字节 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
6字节 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
因此UTF-8中可以用来表示字符编码的实际位数最多有31位，即上表中x所表示的位。除去那些控制位（每字节开头的10等），这些x表示的位与UNICODE编码是一一对应的，位高低顺序也相同。
实际将UNICODE转换为UTF-8编码时应先去除高位0，然后根据所剩编码的位数决定所需最小的UTF-8编码位数。
因此那些基本ASCII字符集中的字符（UNICODE兼容ASCII）只需要一个字节的UTF-8编码（7个二进制位）便可以表示。

对于上面的问题，代码中给出的两个字节是
十六进制：C0 B1
二进制：11000000 10110001
对比两个字节编码的表示方式：
110xxxxx 10xxxxxx
提取出对应的UNICODE编码：
00000 110001
可以看出此编码并非“标准”的UTF-8编码，因为其第一个字节的“有效编码”全为0，去除高位0后的编码仅有6位。由前面所述，此字符仅用一个字节的UTF-8编码表示就够了。
JAVA在把字符还原为UTF-8编码时，是按照“标准”的方式处理的，因此我们得到的是仅有1个字节的编码。

大家可以试试运行这段代码：

`public` `class` `TestUTF8 { ``public` `static` `void` `main(String[] args) ``throws` `Exception { ``byte``[][] bytes = { ``// 00110001 ``{(``byte``)``0x31``}, ``// 11000000 10110001 ``{(``byte``)``0xC0``,(``byte``)``0xB1``}, ``// 11100000 10000000 10110001 ``{(``byte``)``0xE0``,(``byte``)``0x80``,(``byte``)``0xB1``}, ``// 11110000 10000000 10000000 10110001 ``{(``byte``)``0xF0``,(``byte``)``0x80``,(``byte``)``0x80``,(``byte``)``0xB1``}, ``// 11111000 10000000 10000000 10000000 10110001 ``{(``byte``)``0xF8``,(``byte``)``0x80``,(``byte``)``0x80``,(``byte``)``0x80``,(``byte``)``0xB1``}, ``// 11111100 10000000 10000000 10000000 10000000 10110001 ``{(``byte``)``0xFC``,(``byte``)``0x80``,(``byte``)``0x80``,(``byte``)``0x80``,(``byte``)``0x80``,(``byte``)``0xB1``}, ``}; ``for` `(``int` `i = ``0``; i < ``6``; i++) { ``String str = ``new` `String(bytes[i], ``"UTF-8"``); ``System.out.println(``"原数组长度："` `+ bytes[i].length + ``"/t转换为字符串："` `+ str + ``"/t转回后数组长度："` `+ str.getBytes(``"UTF-8"``).length); ``} ``} ``} `

　　运行结果为：

原数组长度：1 转换为字符串：1 转回后数组长度：1
原数组长度：2 转换为字符串：1 转回后数组长度：1
原数组长度：3 转换为字符串：1 转回后数组长度：1
原数组长度：4 转换为字符串：1 转回后数组长度：1
原数组长度：5 转换为字符串：1 转回后数组长度：1
原数组长度：6 转换为字符串：1 转回后数组长度：1

另转：

字符编码笔记：ASCII，Unicode和UTF-8

今天中午，我突然想搞清楚Unicode和UTF-8之间的关系，于是就开始在网上查资料。

结果，这个问题比我想象的复杂，从午饭后一直看到晚上9点，才算初步搞清楚。

下面就是我的笔记，主要用来整理自己的思路。但是，我尽量试图写得通俗易懂，希望能对其他朋友有用。毕竟，字符编码是计算机技术的基石，想要熟练使用计算机，就必须懂得一点字符编码的知识。

\1. ASCII码

我们知道，在计算机内部，所有的信息最终都表示为一个二进制的字符串。每一个二进制位（bit）有0和1两种状态，因此八个二进制位就可以组合出256种状态，这被称为一个字节（byte）。也就是说，一个字节一共可以用来表示256种不同的状态，每一个状态对应一个符号，就是256个符号，从0000000到11111111。

上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，做了统一规定。这被称为ASCII码，一直沿用至今。

ASCII码一共规定了128个字符的编码，比如空格“SPACE”是32（二进制00100000），大写的字母A是65（二进制01000001）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的1位统一规定为0。

2、非ASCII编码

英语用128个符号编码就够了，但是用来表示其他语言，128个符号是不够的。比如，在法语中，字母上方有注音符号，它就无法用ASCII码表示。于是，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。比如，法语中的é的编码为130（二进制10000010）。这样一来，这些欧洲国家使用的编码体系，可以表示最多256个符号。

但是，这里又出现了新的问题。不同的国家有不同的字母，因此，哪怕它们都使用256个符号的编码方式，代表的字母却不一样。比如，130在法语编码中代表了é，在希伯来语编码中却代表了字母Gimel (ג)，在俄语编码中又会代表另一个符号。但是不管怎样，所有这些编码方式中，0—127表示的符号是一样的，不一样的只是128—255的这一段。

至于亚洲国家的文字，使用的符号就更多了，汉字就多达10万左右。一个字节只能表示256种符号，肯定是不够的，就必须使用多个字节表达一个符号。比如，简体中文常见的编码方式是GB2312，使用两个字节表示一个汉字，所以理论上最多可以表示256x256=65536个符号。

中文编码的问题需要专文讨论，这篇笔记不涉及。这里只指出，虽然都是用多个字节表示一个符号，但是GB类的汉字编码与后文的Unicode和UTF-8是毫无关系的。

3.Unicode

正如上一节所说，世界上存在着多种编码方式，同一个二进制数字可以被解释成不同的符号。因此，要想打开一个文本文件，就必须知道它的编码方式，否则用错误的编码方式解读，就会出现乱码。为什么电子邮件常常出现乱码？就是因为发信人和收信人使用的编码方式不一样。

可以想象，如果有一种编码，将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码，那么乱码问题就会消失。这就是Unicode，就像它的名字都表示的，这是一种所有符号的编码。

Unicode当然是一个很大的集合，现在的规模可以容纳100多万个符号。每个符号的编码都不一样，比如，U+0639表示阿拉伯字母Ain，U+0041表示英语的大写字母A，U+4E25表示汉字“严”。具体的符号对应表，可以查询unicode.org，或者专门的汉字对应表。

\4. Unicode的问题

需要注意的是，Unicode只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。

比如，汉字“严”的unicode是十六进制数4E25，转换成二进制数足足有15位（100111000100101），也就是说这个符号的表示至少需要2个字节。表示其他更大的符号，可能需要3个字节或者4个字节，甚至更多。

这里就有两个严重的问题，第一个问题是，如何才能区别unicode和ascii？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？第二个问题是，我们已经知道，英文字母只用一个字节表示就够了，如果unicode统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是0，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的。

它们造成的结果是：1）出现了unicode的多种存储方式，也就是说有许多种不同的二进制格式，可以用来表示unicode。2）unicode在很长一段时间内无法推广，直到互联网的出现。

5.UTF-8

互联网的普及，强烈要求出现一种统一的编码方式。UTF-8就是在互联网上使用最广的一种unicode的实现方式。其他实现方式还包括UTF-16和UTF-32，不过在互联网上基本不用。重复一遍，这里的关系是，UTF-8是Unicode的实现方式之一。

UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。

UTF-8的编码规则很简单，只有二条：

1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。

2）对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。

下表总结了编码规则，字母x表示可用编码的位。

Unicode符号范围 | UTF-8编码方式
(十六进制) | （二进制）
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

下面，还是以汉字“严”为例，演示如何实现UTF-8编码。

已知“严”的unicode是4E25（100111000100101），根据上表，可以发现4E25处在第三行的范围内（0000 0800-0000 FFFF），因此“严”的UTF-8编码需要三个字节，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，从“严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，“严”的UTF-8编码是“11100100 10111000 10100101”，转换成十六进制就是E4B8A5。

\6. Unicode与UTF-8之间的转换

通过上一节的例子，可以看到“严”的Unicode码是4E25，UTF-8编码是E4B8A5，两者是不一样的。它们之间的转换可以通过程序实现。

在Windows平台下，有一个最简单的转化方法，就是使用内置的记事本小程序Notepad.exe。打开文件后，点击“文件”菜单中的“另存为”命令，会跳出一个对话框，在最底部有一个“编码”的下拉条。

里面有四个选项：ANSI，Unicode，Unicode big endian 和 UTF-8。

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

2）Unicode编码指的是UCS-2编码方式，即直接用两个字节存入字符的Unicode码。这个选项用的little endian格式。

3）Unicode big endian编码与上一个选项相对应。我在下一节会解释little endian和big endian的涵义。

4）UTF-8编码，也就是上一节谈到的编码方法。

选择完”编码方式“后，点击”保存“按钮，文件的编码方式就立刻转换好了。

\7. Little endian和Big endian

上一节已经提到，Unicode码可以采用UCS-2格式直接存储。以汉字”严“为例，Unicode码是4E25，需要用两个字节存储，一个字节是4E，另一个字节是25。存储的时候，4E在前，25在后，就是Big endian方式；25在前，4E在后，就是Little endian方式。

这两个古怪的名称来自英国作家斯威夫特的《格列佛游记》。在该书中，小人国里爆发了内战，战争起因是人们争论，吃鸡蛋时究竟是从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开。为了这件事情，前后爆发了六次战争，一个皇帝送了命，另一个皇帝丢了王位。

因此，第一个字节在前，就是”大头方式“（Big endian），第二个字节在前就是”小头方式“（Little endian）。

那么很自然的，就会出现一个问题：计算机怎么知道某一个文件到底采用哪一种方式编码？

Unicode规范中定义，每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做”零宽度非换行空格“（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。这正好是两个字节，而且FF比FE大1。

如果一个文本文件的头两个字节是FE FF，就表示该文件采用大头方式；如果头两个字节是FF FE，就表示该文件采用小头方式。

\8. 实例

下面，举一个实例。

打开”记事本“程序Notepad.exe，新建一个文本文件，内容就是一个”严“字，依次采用ANSI，Unicode，Unicode big endian 和 UTF-8编码方式保存。

然后，用文本编辑软件UltraEdit中的”十六进制功能“，观察该文件的内部编码方式。

1）ANSI：文件的编码就是两个字节“D1 CF”，这正是“严”的GB2312编码，这也暗示GB2312是采用大头方式存储的。

2）Unicode：编码是四个字节“FF FE 25 4E”，其中“FF FE”表明是小头方式存储，真正的编码是4E25。

3）Unicode big endian：编码是四个字节“FE FF 4E 25”，其中“FE FF”表明是大头方式存储。

4）UTF-8：编码是六个字节“EF BB BF E4 B8 A5”，前三个字节“EF BB BF”表示这是UTF-8编码，后三个“E4B8A5”就是“严”的具体编码，它的存储顺序与编码顺序是一致的。

延伸阅读

* The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets（关于字符集的最基本知识）

* 谈谈Unicode编码

* RFC3629：UTF-8, a transformation format of ISO 10646（如果实现UTF-8的规定）

（完）

http://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.html

帅哥美女如果觉得有帮助，打赏一下呀，不多，就 1 块~~~

code

code

特别编码

相关文章

字符集和编码

字符编码的前世今生

跟随历史的足迹看字符编码

古代的通信方式

世界第一条电报

世界第一台计算机

ASCII

EASCII

GB2312

包含字符：

存储方式：

BIG5

包含字符：

编码方式：

Unicode

由来：

ISO/IEC 8859

ISO/IEC 10646 / UCS

版本：

包含字符：

编码方案：

UTF

UTF-8

UTF-16/UCS-2

UTF-32/UCS-4

GB13000

GBK

包含字符：

编码方式：

GB18030

版本：

包含字符：

编码方式：

前端眼中的字符编码

基本原理：

乱码是个XX

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

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

申明编码的方式

BOM是个神马

关于未来的展望

概述

摆在眼前的问题

拥抱国际化标准

UNICODE编码UTF-16 中的Endian（FE FF） 和 Little Endian（FF FE）

字节和字符的区别

Big Endian和Little Endian

UCS-2和UCS-4

UTF-16和UTF-32

UTF-16

UTF-32

UTF-8

UTF-8编码规则（转）

字符编码笔记：ASCII，Unicode和UTF-8

相关文章

发表评论

个人资料

时间倒计时

日历

最新文章

分类

友情链接

UNICODE编码UTF-16 中的Endian（FE FF）和 Little Endian（FF FE）