Unicode签名BOM引发的事故原因分析

你是否曾经遇到过在编程时遇到的那些令人头疼的问题？比如今天我要分享的这个关于BOM的事故。当你在处理包含(include)文件时，特别是在处理header和footer文件时，你是否注意到过页面属性中的“包括Unicode签名BOM”这一选项？就是这个看似不起眼的选项，引发了我今天的困扰。

在深入研究后，我看到了那个可恶的BOM标记被勾选了。一旦去掉它，问题就神奇地解决了。虽然我平时比较懒惰，很少更新博客，但这次我不得不记录下这个经历，因为实在是太意外了。谁能想到，JS也会因为BOM引发事故呢？

那么，什么是BOM呢？BOM是Byte Order Mark的缩写，也就是字节序标记。在普通文本编辑器下，我们是看不到BOM的，它就像文件头部的隐形标识。只有在二进制编辑器下，我们才能看到它。在Unicode规范中，有一个叫做”ZERO WIDTH NO-BREAK SPACE”的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，因此不应该出现在实际传输中。

UCS规范建议我们在传输字节流前，先传输这个特殊字符”ZERO WIDTH NO-BREAK SPACE”。这样接收者就可以通过接收到的字符来判断字节流的顺序。如果接收到的是FEFF，那么就说明这个字节流是Big-Endian的；如果接收到的是FFFE，那么就说明这个字节流是Little-Endian的。这个字符被命名为BOM。

对于UTF-8编码来说，虽然它不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8编码是EF BB BF。如果接收者收到以EF BB BF开头的字节流，就能知道这是UTF-8编码。Windows系统就是使用BOM来标记文件的编码方式的。

希望这篇文章能够帮助你更好地理解BOM，并在未来的编程生涯中避免类似的困扰。毕竟，谁也不想因为一个小小的BOM而耗费近一个小时的时间去排查问题。