之前一直在纠结这些格式到底有什么区别，有时候因为格式的问题会让人抓狂。
下面通过实战来分析下：
下面在windows上建立一个txt文档。txt的优势是没有文件头，这样比较好分析。
ANSI格式：
可以看到，0D0A是
，可以忽略，这里的蛤被识别成B8 F2
UTF-8无BOM：
这里的英文字母还是ASCII格式，汉字在这里被识别成 E8 9B A4
UTF-8：
英文字母是ASCII，这里前面多了三个字节： EF BB BF，这个东西可能是BOM
蛤被识别成E8 9B A4
UCS2 大端：
这里有一个前缀 FE FF
这里的0123对应的30,31,32被扩展成两个字节， 也是。
汉字被识别成 86 E4
可以注意到，对于0，识别出 0030，是大端排列的
UCS2小端：
这里有一个前缀 FF FE
另外一个区别是数字和汉字对应的编码是小端排列的
那么这里来总结一下：
1.除了UCS2，其他格式的ASCII字母都是一个字节。
2.UCS2和UTF8都带有前缀
3.对于ANSI和UCS2，汉字被识别成2个字节，对于UTF8，汉字被识别成三个字节（实际上UTF8中，应该随着汉字而变化）。
这里的UCS2不论什么都识别成两个字节，比较变态。
网络上建议为了兼容性，使用无BOM的UTF8
那么有没有BOM有什么区别呢？知乎上这么解答（http://www.zhihu.com/question/20167122）：
下面的粗体字都是从这里拷过来的：
UTF-8 不需要 BOM，尽管 Unicode 标准允许在 UTF-8 中使用 BOM。所以不含 BOM 的 UTF-8 才是标准形式
后面又提到：在 UTF-8 文件中放置 BOM 主要是微软的习惯。 这样就释怀了，原来是微软干的，好像系统自带的记事本广受吐槽。
微软在 UTF-8 中使用 BOM 是因为这样可以把 UTF-8 和 ASCII 等编码明确区分开，但这样的文件在 Windows 之外的操作系统里会带来问题。
「UTF-8」和「带 BOM 的 UTF-8」的区别就是有没有 BOM。即文件开头有没有 U+FEFF。
在网页上使用BOM是个错误。BOM设计出来不是用来支持HTML和XML的。要识别文本编码，HTML有charset属性，XML有encoding属性，没必要拉BOM撑场面
其实说BOM是个坏习惯也不尽然，很多shell出于兼容的考虑不检测BOM，最后回头想想，似乎也真就只有Windows坚持用BOM了。
看起来BOM(EFBBBF)就是让编辑器识别他是UTF8，编辑器如果把它识别为字符的话就会出错。
UTF8的格式如下：
1、对于单字节符号，字节第一位为0，后面7位表示字节编码。
2、对于n字节符号，第一字节的前n位都设为1，第n＋1位为0，其余位位编码位置。
上面的蛤的表示是E8 9B A4，它有三个字节，第一个字节前面是1110，也正好符合。
那么什么是UCS2呢？UCS2在windows中指代Unicode。
这里（http://demon.tw/programming/utf-16-ucs-2.html）有解答：
简单的说，UTF-16可看成是UCS-2的父集。在没有辅助平面字符（surrogate code points）前，UTF-16与UCS-2所指的是同一的意思
所谓微软的 Unicode，确实是 UTF-16LE，那就是UCS2 LE了。
这里（http://www.zhihu.com/question/20650946）又讲了：
- 所谓的「ANSI」指的是对应当前系统 locale 的遗留（legacy）编码。[1]
- 所谓的「Unicode」指的是带有 BOM 的小端序 UTF-16。[2]
- 所谓的「UTF-8」指的是带 BOM 的 UTF-8。[3]
原来这里的ANSI实际上是GBK这些编码啊！
而记事本的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是FFFE后面接着UTF-16字符串的二进制文件，UTF-8是EFBBBF后面接着UTF-8字符串的二进制文件、ANSI是有时候会被解释为当前locale对应的code page的字符串的二进制文件。（还是根据前缀来的啊）
看到这一句话，说明GB开头的也可以无视了：
GB 是国标，中国的一个发布编码规范的机构，可以忽略掉，通用性太差了。微软在 GB2312 的基础上扩展了 GBK，也可以忽略掉。
那么UTF8 without BOM怎么解析呢，没有文件头？？
一些代码文件里面一般是在最前面加入了文件格式的说明，比如HTML的charset，python的开头一行也有。
这里有一个回答解决了疑惑（如何自动识别UTF8）
UTF-8 can be auto-detected better by contents than by BOM. The method is simple: try to read the file (or a string) as UTF-8 and if that succeeds, assume that the data is UTF-8. Otherwise assume that it is CP1252 (or some other 8 bit encoding). Any non-UTF-8 eight bit encoding will almost certainly contain sequences that are not permitted by UTF-8. Pure ASCII (7 bit) gets interpreted as UTF-8, but the result is correct that way too.
原来它是智能识别，根据UTF8特定的格式来校验它是否是UTF8
还有一些问题仍未解决的：
Qt中出现的Latin1，ASCII是什么？为什么Qt经常乱码？
1.根据百度百科的介绍，Latin1包含ASCII，具有一些其他的字符。当然了，使用英文的时候这些都可以。
2.local8bit应该是本地编码。QString内部应该要保存UTF8，然后输入输出的时候需要转换一下：
QString str = QString::fromLocal8Bit("汉字");//输入
std::cout << "Local Output:" << str.local8Bit() << endl;//输出
根据这篇博客的介绍：
http://blog.csdn.net/brave_heart_lxl/article/details/7186631
可以看出源代码文件的编码格式对其也有影响。而且QString赋值的时候必须要告诉QString自己是什么编码。
一般给个char*的时候，Qt并不知道你采用的是什么编码，而是需要告诉它你采用的是什么编码。
正确的操作应该这样：
告诉Qt 默认的编码（cpp源文件的编码需要对应）：
QTextCodec::setCodecForCStrings(QTextCodec::codecForName("GBK"));
QTextCodec::setCodecForCStrings(QTextCodec::codecForName("UTF-8"));
设置QString默认采用的编码。而究竟采用哪一个，一般来说就是源代码是GBK，就用GBK，源代码是UTF-8就用UTF-8。
还有涉及到路径的问题，那就有一个万能的办法：
QTextCodec *codec = QTextCodec::codecForName("UTF-8");
QTextCodec::setCodecForTr(codec);
QTextCodec::setCodecForLocale(QTextCodec::codecForLocale()); //外部路径，非文件中的代码，windows使用的gb2312,这里就采用了gb2312
QTextCodec::setCodecForCStrings(QTextCodec::codecForLocale());//