一直觉得：一个合格的程序员必须要了解清楚编码。
程序员的工作中很频繁的一个场景是：啊啊，又(中文)乱码了，怎么弄， 然后搜索引擎搜了后总是一顿乱试，可能当时解决了，下次遇到问题，又不知道怎么办，一直没有深入理解其原理。
先思考以下几个问题：
- 为什么要用十六进制 (0x7f) 来标识字节？
- 计算机怎么读取（文本/二进制）数据并解码并显示？
- 经常遇到中文乱码是怎么造成的？
- Unicode 与 UTF-8 是什么关系？分别解决了什么问题？
- 经常看到 （不）带 BOM 的 UTF-8, 其中 BOM 是什么？
从本文下面的一些分析来一一解答。
序言
计算机里面存储的都是二进制序列 0101010，思考怎么把它通过一套规则与现实世界的字符对应起来，就出现了各种字符集，字符编码规范。
为什么要用十六进制？
很简单，为了简洁，方便。二进制 0101 列起来太多，且浪费存储空间。
1byte = 8bit = 2hex 一个字节 需要8位二进制标识，而只需要2个十六进制即可。
我们经常能看到的16进制通常以 0x \x 开头为标识。两个十六进制为一个字节。下文的很多表示都用的十六进制。
已编码字符集（CCS）
从抽象字符清单到非负整数(范围不必连续)的映射。该整数称为抽象字符被赋予的码点(code point，或称码位code position)，该字符则称为已编码字符。注意，码点并非比特或字节，因此与计算机表示无关。码点的取值范围由编码标准限定，该范围称为编码空间(code space)。在一个标准中，已编码字符集也称为字符编码、已编码字符清单、字符集定义或码页(code page)。
单字节编码方案
ASCII
最开始 ASCII （American Standard Code for Information Interchange）美国信息交换标准代码，是基于拉丁字母 的一套电脑编码系统。它主要用于显示现代英语。
ASCII 使用一个字节 8 bit (实际上是7 bit) 定义了 2^7 = 128 个字符，如下
二进制：0000 0000 - 0111 1111
十进制： 0 - 127
十六进制：0x00 - 0x7F
ISO-8859-1
ISO-8859-1 (又称Latin-1或“西欧语言”) 扩展了 ASCII 因为理论上 8 bit 可以表示 2^8-1 = 255 个字符。
它以ASCII为基础，在空置的 0xA0-0xFF 的范围内，加入96个字母及符号。
可以看到 0x7F、0x80-0x9F 在此字符集中未有定义。例如欧元符号（0x80 （gbk-cp936））
然后伟大的汉字没有对应的编码，后来国家自己搞了一套编码扩展了 ASCII 。 例如 GB2312 到后来的 GBK 等。
多字节编码
由于单字节能表示的字符太少，且同时也需要与 ASCII 编码保持兼容，所以不同国家和地区纷纷在 ASCII 基础上制定自己的字符集。这些字符集使用大于0x80的编码作为一个前导字节，前导字节与紧跟其后的第二(甚至第三)个字节一起作为单个字符的实际编码；
多字节编码的解析
单字节编码解析很简单，一个字节一个字节的读即可。但是多字节编码涉及到字节解析问题。例如 GBK 使用两个字节编码，在遇到大于 0x80 的读取双字节，小于 0x80 开头的即为 ASCII 单字节。（类似于用前缀进行区分）
GBK
GBK 兼容了 ASCII，汉字采用双字节编码。总体上说第一字节的范围是81–FE（也就是不含80和FF），第二字节的一部分领域在40–7E，其他领域在80–FE。
单字节 （0xxx xxxxx）
双字节 （1xxxx xxxx xxxx xxxx）
需要注意的是：GBK 编码不支持欧元符号"€"，Windows CP936 码页使用 0x80 表示欧元，GB18030 编码则使用0xA2E3表示欧元。
Unicode 与 UTF-8
Unicode 是一套国际统一标准的字符集（规范），世界上每一个可见字符都在 Unicode 里面有一一映射关系。
每个字符对应 Unicode 里面的一个码点。
Unicode 使用四个字节，定义了每个字符的码点。然而存储数据如果全部使用 Unicode 会造成很大的浪费。所以出现了 UTF-8 之类的编码格式。UTF （Unicode Translation Format, UTF ）翻译下就是 Unicode 转换格式。定义了如果将 Unicode 与字节(二进制序列）一一映射。
UTF-8
UTF-8 是一种针对 Unicode 的可变宽度字符编码，可表示 Unicode 标准中的任何字符。UTF-8已逐渐成为电子邮件、网页及其他存储或传输文字的应用中，优先采用的编码。互联网工程工作小组(IETF)要求所有互联网协议都必须支持 UTF-8 编码。
UTF-8 使用1-4个字节为每个字符编码，其规则如下(x表示可用编码的比特位)：
UTF-8 是定义了 Unicode 映射的字符在计算机上如何存储。
| Unicode码点(Hex) | UTF-8序列(Bin) | 字节数 |
|---|---|---|
| 0000 - 007F | 0xxxxxxx | 1 |
| 0080 - 07FF | 110xxxxx 10xxxxxx | 2 |
| 0800 - FFFF | 1110xxxx 10xxxxxx 10xxxxxx | 3 |
| 10000～10FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx | 4 |
BOM 是什么？
UTF-8 以字节为编码单元，没有字节序的问题。UTF-16 以两个字节为编码单元，在解释一个 UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如“奎”的Unicode编码是594E， “乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”，那么这是“奎” 还 是“乙”？ Unicode 规范中推荐的标记字节顺序的方法是 BOM， Unicode 将几个特定的码点 例如 U+FEFF 的字符定义为字节顺序标记(Byte Order Mark, BOM）
不同的编码方案对零宽不换行字符的解析如下：
| 编码方案 | 大字节序(Hex) | 小字节序(Hex) |
|---|---|---|
| UTF-8 | EF BB BF | EF BB BF |
| UTF-16 | Fe FF | FF Fe |
| UTF-32 | 00 00 Fe FF | FF Fe 00 00 |
UTF-16 和 UTF-32 编码默认为大字节序。UTF-8 以字节为编码单元，没有字节序问题，BOM 只用于表明其编码格式(signature)*。
Unicode标准并未要求或建议UTF-8编码使用BOM，但确实允许BOM出现在文件开头。带有BOM的Unicode文件有时会带来一些问题：
- Linux/UNIX系统未使用BOM，因为它会破坏现有ASCII文件的语法约定。
- 某些编辑器不会添加BOM，或者可以选择是否添加BOM。
- 某些语法分析器可以处理字符串常量或注释中的UTF-8，但无法分析文件开头的BOM。
- 某些程序在文件开头插入前导字符来声明文件类型等信息，这与BOM的用途冲突。
