java的IO字节流在读取windows记事本文件时出现乱码去不掉的问题(记事本BOM)

有时候，我们在使用javaIO字节流读取windows下的.txt文件时，发现明明记事本的编码格式已经改了过来，内容也分毫无差，可是当我们读取时依然会在头部出现几个乱码，而且这种乱码还是无论怎么去都去不掉的那种，就好像凭空出现，完全不知道它是从哪里来的.....别着急，先上几个图。

点击记事本文件，另存为，查看编码格式，编码格式也正确无误

使用IO读取文件内容

乱码出现了，明明什么都是正确的，可是依然还有乱码......

别着急，再上几张图，因为Editplus可以查看文件的十六进制数，所以我们用Editplus打开这个文件

点击HX,发现红框位置多出了几个字节

按照正常情况，abcdefg这几个字母的16进制数为：61 62 63 64 65 66 67 ，可是现在却多出了三个十六进制数EF BB BF .我们用IO流将读取的字节转化为十六进制数来查看一下

发现同样的三个十六进制数出现了，本来文件中是没有这三个东西的，可是现在却凭空有了，于是可以猜想乱码也是因为这三个数字。乱码根源找到了，就是因为这个，那么这三个十六进制数字到底是什么东西呢？

这其实是windows记事本自动给我们的文本添加的一种标识.用来区分你现在所存储的文件所采用的编码格式是什么。因为记事本并不像我们想的那么智能，而编码格式又有很多种(GBK ,UNICODE ...)，Microsoft为了记事本可以识别到底采用什么编码，于是在存储文件时会自动添加一个BOM头，这个是记事本自动添加的，我们看不到，而EF BB BF这三个十六进制数字就是记事本用来识别utf-8编码的一种标记，如果我们不小心，读取utf-8编码格式的记事本文件时便出现了乱码。

（注意GBK编码格式是不会添加BOM头的）

好了，既然根源问题找到了，那么我们就去解决他，只要去掉这个BOM头便可以，要想去掉也简单，同样是使用Editplus,打开另存为，选择无BOM头格式存储便可以。

我们再次读取时，发现乱码没有了

话外题：java中，utf-8 以及unicode 编码其实还有大端与小端的区别，eclipse默认采用的是小端的形式，有兴趣的可以通过java.nio包下的Charset 这个封装类来查看当前的所有编码格式