Java杂谈之BOM谜题

---

0、前言

开发中做了一个导出CSV功能，本地通过wps测试都没有问题，但是测试人员测试的时候发现用excel打开中文表头会出现乱码现象，很奇怪的现象，用nodePad工具打开看也是正常的，但是用excel打开就是中文乱码，通过查找资料了解到是因为csv文件是utf-8编码的，但是没有增加bom头，这样就会导致在window环境下一些软件会用默认编码打开文件从而导致乱码问题，本文详细介绍从前端下载、后端读写如何解决该问题。

1、何为BOM

BOM —— Byte Order Mark，中文名译作“字节顺序标记”。关于 BOM 的说明：在UCS 编码中有一个叫做 “Zero Width No-Break Space” ，中文译名“零宽无间断间隔”的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符 “Zero Width No-Break Space”。这样如果接收者收到 FEFF，就表明这个字节流是Big-Endian的；如果收到FFF，就表明这个字节流是 Little- Endian的。因此字符 “Zero Width No-Break Space” （“零宽无间断间隔”）又被称作 BOM。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符 “Zero Width No-Break Space” 的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流，就知道这是 UTF-8编码了。Windows环境就是使用BOM来标记文本文件的编码方式的。

2、BOM头带来的问题

Windows自带的记事本等软件，在保存一个以UTF-8编码的文件时，会在文件开始的地方插入三个不可见的字符（0xEF 0xBB 0xBF，即BOM）。它是一串隐藏的字符，用于让记事本、office等编辑器识别这个文件是否以UTF-8编码。对于一般的文件，这样并不会产生什么麻烦。但对于解析来说，BOM是个大麻烦。文件读取时并不会忽略BOM，所以在读取、包含或者引用这些文件时，会把BOM作为该文件开头正文的一部分。