项目中经过 InputStream 读取文本文件数据时常常会遇到读入的字符流中含有特殊首字符的状况。这个标识在 Java 读取文件的时候,不会被去掉,并且 String.trim() 也没法删除,致使读入的数据比预期的长度大1,此时的特殊首字符有可能就是系统保存文本文件时添加的 BOM 标识。编辑器
BOM 即 Byte Order Mark,是 Unicode 规范中推荐的标记字节顺序的方法。好比说对于 UTF-16,若是接收者收到的 BOM 是 \uFEFF,代表这个字节流是 Big-Endian 的;若是收到 \uFFFE,就代表这个字节流是Little-Endian的。在 UTF-8 中不须要 BOM 来代表字节顺序,但能够用其来代表 UTF-8 的编码规则。BOM的 UTF-8 编码是 EF BB BF(用 UltraEdit 打开文本并切换到16进制能够看到)。因此若是接收者收到以 EF BB BF 开头的字节流,就知道这是 UTF-8 编码了。编码
在 Windows 下用文本编辑器建立的文本文件,若是选择以 UTF-8 等 Unicode 格式保存,会默认在文件头(第一个字符)都会加入一个不可见的 BOM 标识。code
在读入数据时,因为 BOM 字符不会被忽略掉,并且 String.trim() 也没法删除,会致使咱们判断首字符时出现没必要要的麻烦,例如当咱们须要判断读入字符串以某个字符开头时 BOM 字符就可能形成判断失败,须要针对 Unicode 格式保存的文件作特殊处理。字符串
可使用 Apache Commons IO 中的 BOMInputStream 去封装下原始的 InputStream 便可得到一个过滤了 BOM 字符的输入流,而后再继续后续的操做便可。it