java utf-8带bom格式内容(带"\uFEFF")转换成utf-8格式

从txt文件中读取一串字符串和数据库中另一串字符串比较的时候发现两串字符串一样，但是判断是否equal的时候发现返回的是false，也就是不相等。这就奇怪了，于是打印log，发现了端倪：

左边的字符串是数据库的，右边的字符串是从txt文档读取的，发现右边的字符串前有个小点。

把整个内容复制粘贴出来，发现那个小点又不见了：

E/id===: 55cdf761d9c74874b381d24a64cb2766,55cdf761d9c74874b381d24a64cb2766

单独复制那个小点，用百度搜索，发现什么也搜不到，空白，只会跳转到百度首页。

这就很奇怪了。

把那个小点复制粘贴到编辑器上，还是什么也没。添加双引号“”再粘贴进去，就出现内容了：

"\uFEFF"

发现这个是文档编码格式的问题。文档是utf-8带bom格式，这个是不标准的。标准的格式是utf-8无bom格式。

什么是BOM？
BOM（byte-order mark），即字节顺序标记，它是插入到以UTF-8、UTF16或UTF-32编码Unicode文件开头的特殊标记，用来识别Unicode文件的编码类型。对于UTF-8来说，BOM并不是必须的，因为BOM是用来标记多字节编码文件的编码类型和字节顺序（big-endian或little- endian）。而UTF-8中，每个字符的编码有多少位是通过第一个字节来表述的，而且没有big-endian和little-endian的区分。
UTF-8 不需要 BOM，尽管 Unicode 标准允许在 UTF-8 中使用 BOM。所以不含 BOM 的 UTF-8 才是标准形式，在 UTF-8 文件中放置 BOM 主要是微软的习惯（顺便提一下：把带有 BOM 的小端序 UTF-16 称作「Unicode」而又不详细说明，这也是微软的习惯）。
BOM是为 UTF-16 和 UTF-32 准备的，用于标记字节序（byte order）。微软在 UTF-8 中使用 BOM 是因为这样可以把 UTF-8 和 ASCII 等编码明确区分开，否则用Excel打开CSV文件有可能是乱码的。但这样的文件在 Windows 之外的操作系统里会带来问题。
「UTF-8」和「带 BOM 的 UTF-8」的区别就是有没有 BOM。即文件开头有没有 U+FEFF。
UTF-8 的网页代码不应使用 BOM，否则常常会出错。当从http 的response输出CSV文件的时候，设置为utf8的时候默认是不带
bom的，但是windows的Excel是使用bom来确认utf8编码的，所有需要把bom写到文件的开头。

由此可见如果txt文件格式是utf-8带bom是不标准的，这样获取的字符串可能有问题。那怎么处理呢？如果是utf-8带bom格式，那就把第一个字符去掉，从第二个字符开始截取。如果是utf-8无bom格式，那么就从第一个字符开始截取。代码如下：

String id;
//获取txt文件内容的id。后台导出的txt文件格式为带bom的utf-8。需要判断第一个字符是否是'\uFEFF'
if(inputTaskItem.substring(0,1).contains("\uFEFF")) {//是utf-8带bom格式
    //把第一位去掉，从第二位开始截取。inputTaskItem为txt文件内容字符串
    id = inputTaskItem.substring(1);
} else { //是utf-8无bom格式
    //正常获取
    id = inputTaskItem;
}

经测试，问题解决。