自己也不是很明白这些编码，百度了一下，整理出来与大家分享分享，在此感谢作者。
先说说这些编码
ANSI：最早的时候计算机ASCII码只能表示256个符号（含控制符号），这个字符集表示英文字母足够，其中，我们键盘上可见的符号的编码范围是从32到126（大小写英文字母、数字、英文符号等）。但表示汉字、日语、韩语就不太够用了，汉字常用字有3000多个。
但是中国人也要用电脑打字，于是，中国人就研究出来了最早的中文字符集GB2312（GBK就是后来的扩展），GB2312的做法是，把ASC码取值范围的128～255这个区间挪用了一下，用两个ASC码表示一个汉字，这样可用的编码范围用十六进制表示就是0x8080到0xFFFF，这大概能表示一万多个符号，足够了。[注:实际没用那么多，GBK的范围是8140-FEFE]
那个时候，计算机技术还不发达，各个国家搞自己的，比如台湾，也另搞了一套，叫BIG5（俗称：大五码），跟大陆的也不太一样，但方法是类似的，都是用0x80到0xFF这个区间。
然后日语（有编码JIS）、韩语等等也各搞一套。
这些国家的编码区间都是重叠的，但同一个汉字（比如有一些汉字同时存在于简体、繁体、日语汉字中）有不同的编码，很混乱是不是？但也凑合用了。编码不同导致了很多麻烦，比如一个网页，如果你不知道它是什么编码的，那么你可能很难确定它显示的是什么，一个字符可能是大陆简体/台湾繁体/日本汉字，但又完全是不同的几个字。
所以如果用一些很老的软件，可能会听说有中文版/日文版之类的，对应的版本只能在对应的系统上运行。
后来，这个对操作系统的开发实在是太困难了，因为这意味着不同语言的版本，都要重新编码。于是发明了Unicode。
Unicode这个东西，就是要把地球上所有的语言的符号，都用统一的字符集来表示，一个编码真正做到了唯一。
Unicode里有几种方式：
UTF-16BE/LE：UTF-16就是Windows模式的编码模式(Windows里说的Unicode一般都是指这种编码），用2个字节表示任意字符，注意：英文字符也占2个字节（变态不？），这种编码可以表示65536个字符，至于LE和BE，就是一个数值在内存/磁盘上的保存方式，比如一个编码0x8182，在磁盘上应该是0x81 0x82呢？还是0x82 0x81呢？就是高位是最先保存还是最后保存的问题，前者为BE，后者为LE。
UTF-8：UTF-8则是网页比较流行的一种格式：用一个字节表示英文字符，用3个字节表示汉字，准确的说，UTF-8是用二进制编码的前缀，如果某个UTF-8的编码的第一个字节的最高二进制位是0，则这个编码占1字节，如果是110，则占2字节，如果是1110，则占3字节……
好了，说了这么，再来研究Windows的记事本。
Windows早期（至少是95年以前的事情了）是ANSI字符集的，也就是说一个中文文本，在Windows简体中文版显示的是中文，到Windows日文版显示的就不知道是什么东西了。
后来，Windows支持了Unicode，但当时大部分软件都是用ANSI编码的，unicode还不流行，怎么办？Windows想了个办法，就是允许一个默认语言编码，就是当遇到一个字符串，不是unicode的时候，就用默认语言编码解释。（在区域和语言选项里可以改默认语言）
这个默认语言，在不同Windows语言版本里是不同的，在简体中文版里，是GBK，在繁体中文版里，是BIG5，在日文版里是JIS
而记事本的ANSI编码，就是这种默认编码，所以，一个中文文本，用ANSI编码保存，在中文版里编码是GBK模式保存的时候，到繁体中文版里，用BIG5读取，就全乱套了。
记事本也不甘心这样，所以它要支持Unicode，但是有一个问题，一段二进制编码，如何确定它是GBK还是BIG5还是UTF-16/UTF-8？记事本的做法是在TXT文件的最前面保存一个标签，如果记事本打开一个TXT，发现这个标签，就说明是unicode。标签叫BOM，如果是0xFF 0xFE，是UTF16LE，如果是0xFE 0xFF则UTF16BE，如果是0xEF 0xBB 0xBF，则是UTF-8。如果没有这三个东西，那么就是ANSI，使用操作系统的默认语言编码来解释。
Unicode的好处就是，不论你的TXT放到什么语言版本的Windows上，都能正常显示。而ANSI编码则不能。（UTF-8的好处是在网络环境下，比较节约流量，毕竟网络里英文的数据还是最多的）
举例：
同样一段中文文本（可以插入一些英文），保存成ANSI/Unicode/UTF-8，三个文件。
修改windows的默认语言为日语之类的（WIN7的改法是：控制面板-时钟、语言和区域-更改显示语言-区域和语言-管理-非unicode程序语言-更改区域设置/WNIXP改法是：控制面板-区域和语言选项-非unicode程序语言）。
修改完要求重启，重启以后，再打开这三个文件，ANSI的编码全乱了，其余两个都正常显示，这就是UNICODE的作用。
另外，为什么记事本、开始菜单什么的还是正确的中文呢？明明我已经改了默认语言了？因为它们的程序编码也是unicode的。
要把txt发给国外的朋友或者用在非中文的操作系统/软件里，那么你的编码最好选择unicode
再说说「带 BOM 的 UTF-8」和「无 BOM 的 UTF-8」
BOM是用来标示Unicode纯文本字节流的，用来提供一种方便的方法让文本处理程序识别读入的.txt文件是哪个Unicode编码（UTF-8，UTF-16BE，UTF-16LE）。Windows相对对BOM处理比较好，是因为Windows把Unicode识别代码集成进了API里，主要是CreateFile()。打开文本文件时它会自动识别并剔除BOM。Windows用这个有历史原因，因为它最初脱胎于多代码页的环境。而引入Unicode时Windows的设计者又希望能在用户不注意的情况下同时兼容Unicode和非Unicode（Multiple byte）文本文件，就只能借助这种小trick了。相比之下，Linux这样的系统在多locale的环境中浸染的时间比较短，再加上社区本身也有足够的动力轻装前进（吐槽：微软对兼容性的要求确实是到了非常偏执的地步，任何一点破坏兼容性的做法都不允许，以至于很多时候是自己绑住自己的双手），所以干脆一步到位进入UTF-8。当然中间其实有一段过渡期，比如从最初全UTF-8的GTK+2.0发布到基本上所有GTK开发者都弃用多locale的GTK+1.2，我印象中至少经历了三到四年。
BOM不受欢迎主要是在UNIX环境下，因为很多UNIX程序不鸟BOM。主要问题出在UNIX那个所有脚本语言通行的首行#!标示，这东西依赖于shell解析，而很多shell出于兼容的考虑不检测BOM，所以加进BOM时shell会把它解释为某个普通字符输入导致破坏#!标示，这就麻烦了。其实很多现代脚本语言，比如Python，其解释器本身都是能处理BOM的，但是shell卡在这里，没办法，只能躺着也中枪。说起来这也不能怪shell，因为BOM本身违反了一个UNIX设计的常见原则，就是文档中存在的数据必须可见。BOM不能作为可见字符被文本编辑器编辑，就这一条很多UNIX开发者就不满意。
顺便说一句，即使脚本语言能处理BOM，随处使用BOM也不是推荐的办法。各个脚本语言对Unicode的处理都有自己的一套，Python的 # -*- coding: utf-8 -*-，Perl的use utf8，都比BOM简单而且可靠。另一个好消息是，即使是必须在Windows和UNIX之间切换的朋友也不会悲催。幸亏在UNIX环境下我们还有VIM这种神器，即使遇到BOM挡道，我们也可以通过 set nobomb; set fileencoding=utf8; w 三条命令解决问题。
最后回头想想，似乎也真就只有Windows坚持用BOM了。
相关文章：
再次感谢原作者。
*以上文章均属转载，如有侵权，请联系博主进行删除。
来源：https://www.cnblogs.com/cjhs/p/4855734.html