“我们都知道计算机底层是以二进制进行数据存储的，也就是说所有数据最终都会转换成"0101"这样的数字，包括现在看到的这些汉字或者是其他的字符，如拉丁文、emoji表情等。那么问题来了，0101又是如何转换成人类能够识别的字符的呢？
”
字符集
实现0101与字符转换的方式很简单，就是将字符与一个二进制数值一一对应起来。每当我们输入一个字符时会根据表中的对应规则将字符转换成二进制数值然后存储。这张逻辑上的表格就是字符集，世界上第一个字符集是ASCII码表。以下为ASCII码表一部分截图，图形列表示字符，比如小写字母"a"对应的二进制数为0110 0001。
ASCII码表收录了127个字符，包含了一些特殊字符如,?!@#$ 和26个英文字母。当然，对于美国这类英文为母语的国家是够用，但随着PC的普及，法语、汉字、韩语这类特殊符号也需要相应的字符集。例如中国前前后后就发布了GB2312、GBK、GB18030...字符集。这三个字符集也就收录了全部的汉字，同时还兼容了ASCII码表中的字符。
后来为了避免每个国家自己不断的更新字符集，Unicode联合会就推出了Unicode字符集俗称万国表，这个字符集收录了各个国家的字符，意在统一人类的字符、避免不同语言之间的字符经过计算机的存储后出现兼容性等问题。
字符编码
字符集定义了字符在计算机中存储的“编号”，比如上面举的例子中字符a的编号是0110 0001。在ASCII那个时代，一个字符占用1byte也就是8bit，但是到了Unicode时代还是采用1byte来存储肯定是不行的，1byte只能表示128个编号(00000000~01111111共128个数字)，也就是只能表示128个字符。
这个时候就需要采用2byte甚至是3byte或4byte存储。这也就是为什么Unicode被称为变长编码的原因：如果是英文字符就采用1byte编号(兼容了ASCII码表)，如果是中文字符就采用3byte或者4byte存储。
那到底是采用3byte还是4byte存储中文字符呢？这时候字符编码就上场了。比如Unicode字符集就有UTF-8、UTF-16等等的编码方式，虽然字符在Unicode表中的编号是不变的，但是采用了不同的字符编码就会导致了存储在磁盘上的二进制数据就是不一样。比如中文“啊”字采用UTF-8、UTF-16字符编码后转换后的数值(输出的是十进制)为：
因为Java采用的是Unicode字符集，所以上面的Java代码也就说明了同一字符集同一个字符采用了不同的字符编码会存储为不同的二进制数据。
我们平时开发默认都是采用Unicode字符集，排除了字符集不同外，发生乱码的最大原因就是采用了不同的字符编码。如果采用UTF-16去编写文件然后用UTF-8去读取，这个时候就会发生乱码，因此一定要确保读取文件采用的字符编码和编写的字符编码要一致。
Java中的String字符串
在上面我也提到过Java采用的是Unicode字符集，以下是CSAPP中的截图信息
有了字符集，还需要字符编码。默认的，String采用的是UTF-16字符编码，以下是String类源码的说明信息
当然也可以设置系统的字符编码方式为UTF-8。比如在IDEA中，我们都会将项目的运行环境设置为UTF-8，当JVM启动时就会按照当前系统设置的UTF-8字符编码进行字符解析。
一个有趣的小实验
1，编写一个用UTF-16BE字符编码的文件
2，在IDEA中将系统运行环境设置为UFT-16BE，然后编写一段IO流程序读取2.txt文件，打印输出到控制台
idea中Project Encoding设置为UTF-16就表示javac编译java源文件时采用UTF-16去读取。
3，在Windows系统下使用cmd窗口运行javac手动编译Test05文件，此时会疯狂报错，因为Windows采用的是GBK字符编码方式，在cmd窗口编译时是采用GBK去读取java源文件，因此就会报编译错误。
此时我们需要告诉Windows运行javac命令去读取时，使用UTF-16。
从上图也看出来了，虽然编译是成功了，但是读取到的文件还是乱码。原因还是CMD窗口的输出是以GBK编码方式输出的，如果要显示正常只能修改2.txt文件的字符编码为GBK或者修改系统的默认字符集为UTF-16。
总结
本篇主要理解了字符集、字符编码还有Java的String采用的字符集和字符编码，当然关于字符编码的细节还有很多，但理解了计算机存储字符时采用的大体策略也能够做到遇到乱码问题时“手中有粮，心中不慌”。
