一直被字符的编码搞得头晕脑胀，经常出现乱码却又无可奈何，最近看到两篇讲字符编码的文章，这才有点头绪，于是决定把它写出来。
位与字节
计算机是以二进制位进行存储的，8位构成一字节，那么就会引来一个问题，就是如何将现实生活中真正的字符（如'a'、'b'、'c'等）转为二进制位放到计算机中进行存储。因此字符编码也就应运而生了，即定义一些规范，将真实字符与二进制位联系起来。又因为计算机的内存是以字节为单位的，所以也就是将真实字符与字节联系起来。
字符集发展
最开始使用的是ASCII码字符集，用一个字节来表示就足够了（其实只用了7为二进制数），共128个字符，95的可打印字符（如'a'、'b'等），33个控制字符（如'\n'、'\t'等），ASCII码字符集基本满足了美国人民的需要。但是对于欧洲人民来说，这个字符集就不够用了，因为他们经常会用到一些扩展的拉丁字符（如'ẚ'等），怎么办呢？
最简单的办法就是将一个字节的8位全部用上，于是又了EASCII字符集，共256个字符，这满足了西欧人民的需要，但是对于北欧和东欧的人民来讲，仍然不够用，于是ISO 8859字符集出现了，它共由15个字符集组成，如ISO 8859-1为西欧字符集，ISO 8859-4为北欧字符集等。如此一来，欧洲人民的字符问题就解决了。
终于到我们大天朝了，中文字符数量太多，还分为简体和繁体两种。于是不得不采用两个字节进行存储，于是出现了以下几种字符集：
| 字符集 | 字节数 | 兼容性 | 说明 |
|---|---|---|---|
| GB2312 | 变字节，1-2 | 兼容ASCII（1字节） | 简体中文字符集 |
| BIG5 | 定字节，2 | 兼容ASCII（2字节） | 繁体中文字符集 |
| GBK | 定字节，2 | 兼容ASCII（2字节） | GB2312的扩展（支持繁体） |
Unicode
上面说了每个区域有各自的字符集标准，那么就无法再同一个文档中同时显示所有的字符，于是有人开始琢磨能不能把规定一个全球性的字符集标准，能够将世界上的所有字符都包括进去，因此有了Unicode字符集，它规定使用4个字节进行存储，包括了世界上所有的字符，并且可以扩展。但是用四个字节存储ASCII码浪费了太多存储空间，因此刚开始的时候Unicode难以得到推广，所以必须采用有效的编码方案。
可以这样说，上面讲的所有字符集都是把字符集（不包括Unicode）与编码方案紧密结合起来的，也就是每个字符都有确定的字节流（二进制位），因此GBK即可称为字符集，也可称为编码方案。但是可以说Unicode只是单纯的字符集，里面只有字符及其字符所对应的字符码。至于编码方案，有UTF-8,UTF-16，GB18030等。
UTF-8
UTF-8是目前使用最多的编码方案，其实更准确地说是Unicode的编码方案，主要有两条规则:
- 对于单字节字符，字节的首位二进制码为0，其余为Unicode码
- 对于n（2-4）字节字符，首字节的前n位二进制码为1，n+1位二进制码为0，后面字节的两位二进制码均为10，其余为Unicode码
具体如下表：
| Unicode（16进制） | UTF-8（二进制） |
|---|---|
| 00000000 - 0000007F | 0xxxxxxx |
| 00000080 - 000007FF | 110xxxxx 10xxxxxx |
| 00000800 - 0000FFFF | 1110xxxx 10xxxxxx 10xxxxxx |
如此一来，问题就得到解决了，UTF-8也得到了迅速发展。
注意事项
- ANSI：为Windows下默认的编码方案，对英文使用ASCII码，对中文使用GB2313编码方案
- BOM：微软用它来标识采用UTF-8编码方案的文件，并不是通用标准
- 乱码：乱码的根本原因是使用错误的编码方案去解码字节流，因此当出现乱码的时候，请去查看文件的编码方案是什么，这样才能根本解决乱码
参考
