汉字ANSI编码发展
GB2312：为了表示汉字，我们国家首先发明了GB2312 编码，GB2312 编码规定一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的”全角”字符，而原来在127号以下的那些就叫”半角”字符了。
GBK 后来发现很多偏僻字和少数名族的语言还是没办法编码进来，为了表示这些字符，于是干脆不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为 GBK 标准，GBK包括了GB2312的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。
GB18030 后来少数民族也要用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK扩成了GB18030。从此之后，中华民族的文化就可以在计算机时代中传承了。
BOM介绍
1.BOM的来历： 为了识别 Unicode 文件，Microsoft 建议所有的 Unicode 文件应该以 ZERO WIDTH NOBREAK SPACE（U+FEFF）字符开头。这作为一个“特征符”或“字节顺序标记（byte-order mark，BOM）”来识别文件中使用的编码和字节顺序。
2.不同的系统对BOM的支持：因为一些系统或程序不支持BOM，因此带有BOM的Unicode文件有时会带来一些问题。
①JDK1.5以及之前的Reader都不能处理带有BOM的UTF-8编码的文件，解析这种格式的xml文件时，会抛出异常：Content is not allowed in prolog。 ②Linux/UNIX 并没有使用 BOM，因为它会破坏现有的 ASCII 文件的语法约定。 ③不同的编辑工具对BOM的处理也各不相同。使用Windows自带的记事本将文件保存为UTF-8编码的时候，记事本会自动在文件开头插入BOM（虽然BOM对UTF-8来说并不是必须的）。而其它很多编辑器用不用BOM是可以选择的。UTF-8、UTF-16都是如此。
3.BOM与XML：XML解析读取XML文档时，W3C定义了3条规则：
①如果文档中有BOM，就定义了文件编码； ②如果文档中没有BOM，就查看XML声明中的编码属性； ③如果上述两者都没有，就假定XML文档采用UTF-8编码。
决定文本的字符集与编码
软件通常有三种途径来决定文本的字符集和编码:
1.检测BOM
对于Unicode文本最标准的途径是检测文本最开头的几个字节。
2.用户选择： 采取一种比较安全的方式来决定字符集及其编码，那就是弹出一个对话框来请示用户。
3.采取“猜”的方法： 如果软件不想麻烦用户，或者它不方便向用户请示，那它只能采取自己“猜”的方法，软件可以根据整个文本的特征来猜测它可能属于哪个charset，这就很可能不准了。使用记事本打开那个“联通”文件就属于这种情况。（把原本属于ANSI编码的文件当成UTF-8处理。
记事本的几种编码介绍
1.ANSI编码：记事本默认保存的编码格式是：ANSI，即本地操作系统默认的内码，简体中文一般为GB2312。这个怎么验证呢？用记事本保存后，使用EmEditor、EditPlus和UltraEdit之类的文本编辑器打开。推荐使用EmEditor，打开后，在又下角会显示编码：GB2312。
2.Unicode编码：用记事本另存为时，编码选择“Unicode”，用EmEditor打开该文件，发现编码格式是：UTF-16LE+BOM（有签名）。用十六进制方式查看，发现开头两字节为：FF FE。这就是BOM。
3.Unicode big endian 用记事本另存为时，编码选择“Unicode”，用EmEditor打开该文件，发现编码格式是：UTF-16BE+BOM（有签名）。用十六进制方式查看，发现开头两字节为：FE FF。这就是BOM。
4.UTF-8 ：用记事本另存为时，编码选择“UTF-8”，用EmEditor打开该文件，发现编码格式是：UTF-8（有签名）。用十六进制方式查看，发现开头三个字节为：EF BB BF。这就是BOM。
