ANSI,UTF8等等这些格式

之前一直在纠结这些格式到底有什么区别，有时候因为格式的问题会让人抓狂。

下面通过实战来分析下：

下面在windows上建立一个txt文档。txt的优势是没有文件头，这样比较好分析。

ANSI格式：

可以看到，0D0A是\r\n，可以忽略，这里的蛤被识别成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被扩展成两个字节，\r\n也是。

汉字被识别成 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());//