windows自带记事本导致文本文件乱码问题

最近在写一个读取文本文件(.txt)中的数字并求取平均数的程序中,发现读取文件,并成功保存在list中后,将String类型的数字转化为double类型时,老是抛出类型不匹配的异常,经输出测试发现list中的数字是正确的,很懵逼。当时就感觉是记事本编码的问题。经过不断的测试,百度后终于发现了原因

正文:


在windows平台下,使用系统的记事本以UTF-8编码格式存储了一个文本文件,但是由于Microsoft开发记事本的团队使用了一个非常怪异的行为来保存UTF-8
编码的文件。他们”自作聪明”的在每个文件开头添加了0xefbbbf(十六进制)的字符,所以我们就会遇见很多不可思议的问题,比如类型转换失败等等。
为了验证这个原因,我们来测试一下

测试过程


首先我们新建一个txt文件,用系统自带的记事本打开,并将其以UTF-8格式来保存


在该文件中我仅仅输入了test这四个字符,那么读取该文件的内容后的长度也应该是四,我们来看一段测试代码

test.java


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class test {
public static void main(String[] args) {
String path = "C:\\Users\\hyf\\Desktop\\test.txt";
File file = new File(path);
try {
InputStreamReader inputStreamReader = new InputStreamReader(new FileInputStream(file),"utf-8");
BufferedReader br = new BufferedReader(inputStreamReader);
System.out.println(br.readLine().length());
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}

按道理输出结果应该是 4
但是请看运行结果:


这说明了上面的说法是正确的,有兴趣的童鞋可以自己尝试着将最前面的字符拿出来,然后再输出切割后的字符是不是还是test
ps:经我测试结果是的。

解决办法


有时候bug就是这样莫名其妙,这时候就记住一点不要用微软自带的记事本,用其他的文本编辑器代替即可,sublime,notepad++等都可


博文内容纯原创,如有交流请求,请联系我