bom以及字符编码

最近在做php项目的时候遇到了两个都与BOM有关的问题，这里记录一下

1、项目中很多需要发送Ajax请求来加载的资源（例如一些弹出框以及图片）都不能正确显示。

通过用chrome分析请求响应过程发现：返回的响应头部多出了EF BB BF，导致前端javascript解析错误。

最后查找出的原因：在开发过程中将某些用于输出的php文件存储成了UTF-8的形式。但目前还不知道为什么文件的保存形式会影响到输出流中的内容。

2、下载csv文件，中文内容乱码

下载的csv文件只要文件中有中文，打开excel就显示乱码。但文件名显示正常。

通过研究后台用于输出的程序发现，程序将内容以UTF-8编码并放到输出流的过程没有问题，响应头的设置也不存在问题。

最后的原因是csv遇到中文是默认以GBK打开，而后台在传输时对字符的编码是UTF-8。这就会导致excel解析出问题。

通过阅读 Unicode standard，BOM对于UTF-8而言是不推荐也是没必要添加的。除了一下两种情况：

1.Unmarked Byte Order. 

Some machine architectures use the so-called bigendian
byte order, while others use the little-endian byte order. When Unicode
text is serialized into bytes, the bytes can go in either order, depending on the
architecture. Sometimes this byte order is not externally marked, which causes
problems in interchange between different systems.
2. Unmarked Character Set. 

In some circumstances, the character set information
for a stream of coded characters (such as a file) is not available. The only information
available is that the stream contains text, but the precise character set is
not known.

第一种是在不同架构的计算机通信时，有些采用“大尾”的排序方式，有些采用“小尾”。这会使得不同系统的交互混乱。

第二种是当一个已经过编码的流（例如文件）的编码信息未知。唯一能确认的只是该流中含有字符，但精确到是何种字符编码未知。本次项目遇到的第二个问题就是这种情况。

个人理解的Unicode、ANSI、UTF-8以及各种编码的区别

Unicode与ANSI是对字符的编码规则，ANSI相对于Unicode来说较为古老。

UTF-8是便于字节传输，将Unicode转换为UTF-8，按8位传输。

Unicode在传输时可以转换成UTF-8，转换规则如下：

Unicode 
UTF-8

0000 - 007F 
0xxxxxxx

0080 - 07FF 
110xxxxx 10xxxxxx

0800 - FFFF 
1110xxxx 10xxxxxx 10xxxxxx

      例如"汉"字的Unicode编码是6C49。6C49在0800-FFFF之间，所以要用3字节模板：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 1100 0100 1001，将这个比特流按三字节模板的分段方法分为0110 110001 001001，依次代替模板中的x，得到：1110-0110 10-110001 10-001001，即E6 B1 89，这就是其UTF8的编码。

另外在UTF编码过程中，常常在开始处加上EF BB BF（BOM signature ），这是为了使得软件识别出该文件是用UTF-8编码。