最近项目中涉及到了解析文件内容的需求，文件中全都是中文，由于这一过程中碰到的乱码问题实在过多，所以特地花时间研究了一下中文编码。本文中先介绍一下ASCII，GB2312，GBK和GB18030编码。
之所以把这几个放在一起介绍，是因为他们的相关性非常强。兼容性关系是GB18030兼容GBK，GBK兼容GB2312，GB2312兼容ASCII。所谓兼容，你可以简单理解为子集、不冲突的关系。例如GB2312编码的文件中可以出现ASCII字符，GBK编码的文件中可以出现GB2312和ASCII字符，GB18030编码的文件可以出现GBK、GB2312、ASCII字符。
每种编码方式的特点：
【1】ASCII 每个字符占据1bytes，用二进制表示的话最高位必须为0（扩展的ASCII不在考虑范围内），因此ASCII只能表示128个字
【2】GB2312 最早一版的中文编码，每个字占据2bytes。由于要和ASCII兼容，那这2bytes最高位不可以为0了（否则和ASCII会有冲突）。在GB2312中收录了6763个汉字以及682个特殊符号，已经囊括了生活中最常用的所有汉字。
【3】GBK 由于GB2312只有6763个汉字，我汉语博大精深，只有6763个字怎么够？于是GBK中在保证不和GB2312、ASCII冲突（即兼容GB2312和ASCII）的前提下，也用每个字占据2bytes的方式又编码了许多汉字。经过GBK编码后，可以表示的汉字达到了20902个，另有984个汉语标点符号、部首等。值得注意的是这20902个汉字还包含了繁体字。
【4】GB18030 然而，GBK的两万多字也已经无法满足我们的需求了，还有更多可能你自己从来没见过的汉字需要编码。这时候显然只用2bytes表示一个字已经不够用了（2bytes最多只有65536种组合，然而为了和ASCII兼容，最高位不能为0就已经直接淘汰了一半的组合，只剩下3万多种组合无法满足全部汉字要求）。因此GB18030多出来的汉字使用4bytes编码。当然，为了兼容GBK，这个四字节的前两位显然不能与GBK冲突（实操中发现后两位也并没有和GBK冲突）。我国在2000年和2005年分别颁布的两次GB18030编码，其中2005年的是在2000年基础上进一步补充。至此，GB18030编码的中文文件已经有七万多个汉字了，甚至包含了少数民族文字。
你一定比较好奇这些中文编码是如何做到“兼容”的，我们来看下图：
各种中文编码方式的前两位这图中展示了前文所述的几种编码在编码完成后，前2个byte的值的范围（用16进制表示）。每个byte可以表示00到FF（即0至255）。从图中我们可以一目了然地看到为什么GB18030可以兼容GBK，GB2312和ASCII了。他们几种编码之间前两位没有重合部分。需要注意的是ASCII只有1byte，所以是没有第二位的。另外GB18030在上图中占的面积虽然很小，但是它是4bytes编码，这图只展示了前两位。如果后两位也算上，GB18030的字数要远多于GBK。另外需要注意的是，由于GBK兼容GB2312，因此属于GB2312的蓝色区域其实也可以算作是GBK的区域。同理GBK的区域理论上也属于GB18030的区域。上表中只是展示了多出来的部分。
实际生活中，我们用到的99%以上的汉字，其实都在GB2312那一块区域内。至于GB2312每个编码对应的到底是哪个汉字本文不再赘述，可以参考链接（链接地址）查询。GBK编码所对应的汉字可以参考链接（链接地址）查询。至于GB18030编码，由于字数实在太多太难写，已经很难在网上找到在线的编码全表了。不过经过一番搜寻，还是找到了我国发布GB18030编码时的相关文档（GB18030-2005文档、GB18030-2000文档）。
在实际使用中，GBK编码已经可以满足大部分场景了，GB18030编码中所有汉字都是我们这辈子都不一定能见到的文字，这也是平时为什么经常会使用GBK的原因吧。
