JAVA读取文件中存在BOM的问题

最近在做项目的时候，需要从文件中读取中文字符然后处理。结果，当处理到文件开头的中文字符串的时候总是报错。调试的时候发现输出开头的字符串明明是一个中文字符，但是输出长度的时候却显示长度为2。

于是将开头的字符串的两个字符分别输出，发现第一个字符是编码为65279的字符，输出以后感觉是没有长度的字符。第二个字符才是正确的目标字符。于是去网上查了下发现这个神秘的字符叫BOM。一下摘自百度百科：

BOM —— Byte Order Mark，中文名译作“ 字节顺序标记”。在这里找到一段关于 BOM 的说明：

在UCS 编码中有一个叫做 “ Zero Width No-Break Space” ，中文译名作“ 零宽无间断间隔”的字符，它的编码是 FEFF。而 FFFE 在 UCS 中是不存在的字符，所以不应该出现在实际传输中。UCS 规范建议我们在传输 字节流前，先传输字符 “Zero Width No-Break Space”。这样如果接收者收到 FEFF，就表明这个字节流是 Big-Endian 的；如果收到FFFE，就表明这个字节流是 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 来标记文本文件的编码方式的。

一般使用windows系统自带的文本编辑器打开UTF-8编码的文件后，编辑器会自动在文件开始的地方插入三个不可见的字符（0xEF 0xBB 0xBF，即BOM）。它是一串隐藏的字符，用于让记事本等编辑器识别这个文件是否以UTF-8编码。

解决办法有两个：

1、使用sublime等软件打开文本文件，选择 File->save with encoding->utf-8.这样重新用不含BOM的utf-8保存一下。

2、在程序中，判断读入的第一个字符是不是 65279，如果是，就处理掉。