Unicode 在实践中检测非UTF字节顺序标记（BOM）是否值得

严格地说，BOM应该是一个endianness指示器 但是，对于UTF-16和UTF-32，它可以用于指示所使用的编码，正如 带有UTF-8 BOM标记EF BB BF的箱子

作为一个双八位编码点，BOM表可以转换为任何 支持双字节代码点，因此可能会产生不同的编码。 下面列出了一些示例：

除了常见的导致问题的UTF-8 BOM外，是否存在其他问题 实际生成文件的任何工具或应用程序 这种编码特定的标记？这是否会引起任何问题 标记以这种编码出现在文件中可能是由于 从其他编码转换。这一点的实际含义是： 这是一个很好的实践，以检测这种标记的应用程序中 它支持的编码池，如果至少要忽略和跳过它们的话

---

避免错误。

这真的重要吗？您的应用程序可以将BOCU-1转换为Unicode码点，也可以不转换。如果可以，您将在结果中找到BOM，而不需要知道FBEE28。如果不能，那么了解FBEE28就没有意义了。你当然不能跳过它们。这些bom简直太棒了。这就像比尔·布赖森（Bill Bryson）关于语言和方言之间区别的评论：语言是一种有陆军和海军的方言。在这些BOM选择背后有一家大公司，让他们在某处注册。就像IBM支持UTF-EBCDIC一样，中国政府支持GB-18030。实际使用是很简单的，除非你万不得已，否则不要为它们编码。检测和跳过它们更安全。它取决于您的应用程序，但想象一下jsp、asp、mustache或任何其他类型的模板框架，它们将来自不同文件的字符串组合在一起。你可以在最后的字符串中间用BOM结束，它们不再意味着BOM了。可能还是安全的，但不能保证。。。

UTF-1          F7 64 4C
UTF-EBCDIC     DD 73 66 73
SCSU           0E FE FF[t 4]
BOCU-1         FB EE 28
GB-18030       84 31 95 33