做Java开发的人早晚都会遇到这么一件事用FileInputStream去读一个文本文件读出来全是乱码。或者写了一个文本导出功能在Windows上一切正常部署到Linux服务器上中文全部变成问号。当年我第一次碰到这个问题时排查了整整一个下午最后发现问题不在于我的业务代码而在于我压根用错了工具。文本文件就应该用字符流来处理字节流是拿来处理二进制数据的硬要用它读文本编码问题迟早会找上门。FileReader和FileWriter就是Java为了解决“按字符读写文本文件”这个诉求而提供的基础类。它们是InputStreamReader和OutputStreamWriter的快捷子类核心职责就是完成“字节到字符”的转换。本文不打算做API手册式的罗列而是想把这两个类的设计逻辑、使用场景、编码陷阱和常见替代方案一次讲清楚尤其是那些文档里不会写、但实际开发中一定会踩到的坑。1. 为什么文本文件读写不能只用字节流1.1 一个中文字符被劈成两半的真相计算机底层只认字节也就是0和1组成的序列。但一个文本文件里的字符在磁盘上存储时是以某种编码规则转换后的字节序列。以UTF-8为例英文字母一个字节常见的中文字符通常是三个字节。当你想读取文件里的“汉”字时FileInputStream根本不知道“汉”这个概念它只会机械地返回一个又一个字节。在UTF-8编码下“汉”的三个字节分别是0xE6、0xB1、0x89。如果你用字节流逐字节读取并且把字节直接转成char那么这三个字节可能会被当作三个独立的字符显示或者因为字节值超出了ASCII范围最终显示成乱码。关键在于字节流读的是数据字符流读的是语义。字符流内部会根据指定的字符集把字节序列解码成真正的字符再把字符交给你。所以处理文本文件时选择字符流是逻辑上的必然。1.2 FileReader和InputStreamReader的关系很多人以为FileReader是独立实现的一套读取逻辑其实是误解。你打开FileReader的源码就会发现它直接继承自InputStreamReader构造方法里做的事情就是把传入的File对象包装成FileInputStream然后交给InputStreamReader处理。也就是说FileReader fileReader new FileReader(a.txt)等价于new InputStreamReader(new FileInputStream(a.txt))。两者的区别在于FileReader在底层固定使用平台默认字符集来解码而InputStreamReader允许你显式传入Charset对象从而控制解码规则。FileWriter同理它继承自OutputStreamWriter本质上是new OutputStreamWriter(new FileOutputStream(file))的便捷形式。理解这层包装关系非常重要因为它决定了后续所有编码问题的根源都在哪里。2. FileReader的构造器与读取动作详解2.1 构造器的三种形式和新增的Charset版本FileReader的构造器分两代。JDK 11之前只有三个构造器接收String路径、接收File对象、接收FileDescriptor。这三个版本都没有办法指定字符集只能默默使用平台默认值。JDK 11开始官方终于补上了带Charset参数的构造器public FileReader(String fileName, Charset charset) throws IOException public FileReader(File file, Charset charset) throws IOException所以现在如果你在JDK 11及以上版本里做新项目遇到中文文本文件完全可以直接用带Charset的构造器指定UTF-8不用再绕道InputStreamReader。如果是维护老项目JDK版本较老那就只能老老实实用InputStreamReader包装FileInputStream。2.2 read方法到底怎么读FileReader的读取方法继承自Reader常用的有三个public int read() throws IOException public int read(char[] cbuf, int off, int len) throws IOExceptionread()每次返回一个字符的int表示范围在0到65535之间读到文件末尾时返回-1。这里有个初学者经常困惑的点为什么返回值不直接用char原因在于char没法表达“文件结束”这个状态。如果返回char你可能需要用一个特殊字符来标记结束这在文本内容不可控时根本不安全。所以Java选择了int用-1表示EOF0到65535表示实际读到的字符。按字符读取的效率很低因为每次read()调用都会发生一次方法调用和解码操作。实际开发中更推荐先把数据读入char数组char[] buf new char[1024]; int len; while ((len fileReader.read(buf)) ! -1) { // 处理 buf 中下标 0 到 len-1 的字符 }read(char[] cbuf, int off, int len)可以控制填充数组的起始偏移量和最大读取量。这个方法返回的是实际读到的字符数不是数组长度。注意区分否则很容易在处理时多读或者少读。2.3 一次经典的文件读取示范完整读取一个文本文件并打印内容的标准写法如下try (FileReader reader new FileReader(D:/example.txt)) { char[] buffer new char[2048]; int readCount; while ((readCount reader.read(buffer)) ! -1) { System.out.print(new String(buffer, 0, readCount)); } } catch (IOException e) { e.printStackTrace(); }这段代码用了try-with-resourcesreader在使用结束后会被自动关闭不必写finally块。new String(buffer, 0, readCount)是关键只截取实际读取到的部分避免把数组尾部残留的旧数据也转换出去。3. FileWriter的写入逻辑覆盖、追加与关闭时机3.1 覆盖模式和追加模式怎么选FileWriter的构造器比FileReader多一些主要是多了boolean append这个参数。默认情况下只传文件路径的构造器是覆盖模式也就是说文件如果已经存在打开的时候内容直接清空写入的数据会完全取代原有内容。如果你希望写入的数据追加到文件末尾就必须显式传trueFileWriter writer1 new FileWriter(log.txt); // 覆盖 FileWriter writer2 new FileWriter(log.txt, true); // 追加 FileWriter writer3 new FileWriter(new File(log.txt), true); // 追加追加模式在写日志、记录审计数据这类场景下非常常用。但有一个细节容易忽略FileWriter打开文件不是无锁的。同一个JVM内多个线程同时用FileWriter写同一个文件会出现互相覆盖、内容交错的问题追加模式不能保证原子性。需要并发写同一文件时要么加锁要么用BufferedWriter配合同步块要么干脆考虑日志框架。3.2 write方法的重载与写入缓冲FileWriter的写方法主要有四个重载public void write(int c) throws IOException public void write(char[] cbuf) throws IOException public void write(String str) throws IOException public void write(String str, int off, int len) throws IOException注意write(int c)这里接收的是字符编码对应的整数不是字节。比如writer.write(65)写出来的是字符A而不是一个ASCII码为65的字节。如果想直接写字符串writer.write(hello)就好不需要手动转char[]。FileWriter内部其实并没有特别大的缓冲它继承自OutputStreamWriter后者内部有一个StreamEncoder默认有一个8192字符的缓冲区。这个缓冲区只有被填满或者显式调用flush()/close()时才会把字符真正冲刷到磁盘。这也就解释了为什么写完后不调用flush()有时会丢失数据。3.3 flush和close别混为一谈flush()的作用是把缓冲区里的数据强制写入磁盘但流仍然可以继续使用。close()会先执行flush然后关闭底层文件句柄之后流就不能再写入了。两者的关系是close()一定包含了flush()的效果但如果你在写长文件的循环中很久不flush()一旦进程异常退出缓冲区里的数据就会全部丢失。经验是做日志或者需要频繁观察中间结果时每写几十行就flush()一次。但flush()不是免费的每次调用都会触发一次底层系统写盘操作太频繁会严重拉低性能。实务中应根据业务对实时性和性能的要求来权衡频率比如业务日志一般按批次flush而实时监控日志相对频繁。示例try (FileWriter writer new FileWriter(output.txt)) { writer.write(第一行\n); writer.write(第二行\n); // 这里不写 flush等 close 自动处理 }4. 编码问题是FileReader唯一的硬伤4.1 平台默认字符集的坑FileReader在设计上最大的争议点就是它默认使用Charset.defaultCharset()来做字符集解码。这个默认值取决于JVM启动时的环境在Windows中文版上通常是GBK在Linux上通常是UTF-8还可能被启动参数-Dfile.encoding覆盖。这带来一个很现实的问题你的代码在本机测试一切正常部署到服务器上读同一个文件得到的字符却完全不同。因为源文件是UTF-8编码的本机默认字符集恰好也是UTF-8完美解码服务器默认字符集是GBKUTF-8的字节序列被按照GBK规则解码后输出的就是你看到的乱码。反过来如果源文件是GBK编码本机默认GBK时正常服务器默认UTF-8时又是一堆错误字符。字符集不匹配读文件输出乱码几乎是必然事件。4.2 老版本JDK怎么绕路JDK 11之前没有带Charset的FileReader构造器解决编码问题的标准姿势是用InputStreamReader手动指定String charset StandardCharsets.UTF_8.name(); try (InputStreamReader reader new InputStreamReader(new FileInputStream(path), charset)) { char[] buffer new char[1024]; int len; while ((len reader.read(buffer)) ! -1) { // 处理内容 } }同理写入时用OutputStreamWriter指定编码try (OutputStreamWriter writer new OutputStreamWriter(new FileOutputStream(path), StandardCharsets.UTF_8)) { writer.write(中文内容); }这样写虽然比直接用FileReader多用一层包装但换来的是明确的、跨平台稳定一致的编码行为。所有生产环境的多环境部署项目都应该采用显式指定字符集的方式不要依赖平台默认值。4.3 判断文件真实编码的小技巧读取文本文件前你应该确认它的编码。这不是靠猜可以从文件的字节特征入手。UTF-8的BOM开头是EF BB BFUTF-16 LE的BOM是FF FEUTF-16 BE是FE FF。没有BOM的文件只能用探测工具或经验判断。Java里有一个老牌的探测方案是juniversalchardet或者直接用ICU4J的CharsetDetector都能给出比较可靠的推断结果。实际开发中的建议是关联文件类的数据在写入时就把编码信息固定下来并让读取方通过配置参数明确指定。例如上传导入模板统一规定为UTF-8读取时显式指定UTF-8不要依赖探测探测毕竟只是概率判断。5. 缓冲流组合与更新版本API对比5.1 为什么FileReader裸读很慢FileReader裸读慢的原因在于每次read(char[])都是一次底层文件I/O调用同时伴随着字符集解码操作而且没有任何额外的流内缓冲。逐字符读取时每次read()都触及操作系统文件系统调用系统调用耗时比内存操作高几个数量级循环次数一多性能差异就非常明显。对流式I/O而言中间的缓冲层几乎是必须的。BufferedReader做了一层字符缓冲它内部维护一个默认8192字符的缓冲数组从底层Reader批量读入后再逐一给你大大减少了底层I/O调用的次数。5.2 BufferedReader和BufferedWriter的组合效应把FileReader包装成BufferedReader之后重点不只是在性能还在于拿到一个非常实用的readLine()方法try (BufferedReader reader new BufferedReader(new FileReader(data.txt))) { String line; while ((line reader.readLine()) ! null) { // 按行处理 } }readLine()会返回一行内容不包括换行符遇到整个文件结束时返回null。它解析换行的逻辑是遇到\n、\r或\r\n都会识别并且不会把换行符拼进返回的字符串。这样就省掉了手动分割换行符的麻烦。写入端对应的是BufferedWriter它同样有一个8KB的字符缓冲能累积一批写入后再一次性刷到底层减少磁盘写入次数。包装写法如下try (BufferedWriter writer new BufferedWriter(new FileWriter(output.txt))) { writer.write(第一段内容); writer.newLine(); writer.write(第二段内容); }newLine()会根据平台自动写入对应的换行符。Windows上是\r\nLinux上是\n。如果写出的文件只在服务器之间流转建议还是固定使用\n避免因系统差异导致文件内容被意外重构。5.3 更高层的Files工具类从JDK 7开始java.nio.file.Files提供了一系列更现代的文件读写方法。读取整个文件内容的便捷方式是ListString lines Files.readAllLines(Paths.get(data.txt), StandardCharsets.UTF_8);还有Files.newBufferedReader(Paths.get(data.txt), StandardCharsets.UTF_8);以及写入整个内容Files.write(Paths.get(output.txt), contentList, StandardCharsets.UTF_8);这些方法的优势在于API更简洁支持显式Charset参数并且内部引用了合适的缓冲策略大部分场景下都不需要再自己手动包BufferedReader。需要注意readAllLines一次性读入全部内容对超大文件几百MB来说非常容易撑爆堆内存更适合中小文件的场景。大文件流式处理时还是应该选择BufferedReader按行迭代。5.4 几种方式的核心对比方式编码可控性性能适合场景FileReader直接读默认字符集JDK 11后可指定偏低小文件、本机快速验证FileReader BufferedReader默认字符集JDK 11后可指定良好中大规模文件按行处理InputStreamReader FileInputStream高良好老JDK、必须指定编码的读文件场景Files.readAllLines高只适合小文件整体读取、快速处理小文件Files.newBufferedReader高良好现代JDK的标准按行读取6. 实战中反复踩到的几个坑6.1 乱码不一定是读文件出错也可能在写文件时就错了排查乱码问题有个先后顺序先确认源文件本身是什么编码再确认读取时用的什么编码最后确认你的IDE或者终端显示用的什么编码。很多时候源头没错读的时候也指定对了结果屏幕上仍然显示乱码那是因为IDE控制台默认用了GBK或别的编码显示输出。这种情况不算程序错只是显示错。验证方法很简单把读到的字符串转成字节打印出来或者写入一个新文件再用十六进制工具类观察字节序列就知道内容是否真正正确。6.2 生产环境上用FileReader处理所有文本文件的教训早期接手过一个报表导出功能代码里写死了new FileReader(templateFile)本机Windows跑得好好的上了Linux服务器模板文件里的中文标题全部变成问号。后来排查发现模板文件是UTF-8编码服务器默认字符集也是UTF-8看似没有问题但代码里运行时的JVM参数被某框架改成了-Dfile.encodingGBK。这就是依赖环境配置的典型翻车案例你的程序行为取决于一串外部参数而不是代码本身。从那天开始我定了一个死规矩凡是处理文本文件的代码一律显式传Charset凡是依赖平台默认字符集的写法一律不通过评审。6.3 大文件读取不要用readAllLinesFiles.readAllLines非常方便但只适合小文件。如果文件有200MB这个方法会在底层调用readAllBytes把整个文件读进内存然后按行切分瞬间产生一个200MB的字节数组、一个几百万行的ListString每个字符串对象还有自己的头信息。堆内存小于512MB的服务直接OOM。处理大文本文件务必要用BufferedReader的readLine()循环逐行处理、逐行释放。6.4 不要一边读一边写同一个文件用FileWriter打开一个已存在的文件无论你是否追加底层都会先清空或准备覆盖。如果你在读取同一个文件时创建了指向它的FileWriter在文件内容被完整读取之前文件已经被截断或者被写入新内容了后续读到的就是被破坏的内容。需要做“原地修改”操作时先读完整内容到内存关闭读取流再打开写入流写回。或者用临时文件方案读到一行写入临时文件最后替换原文件。7. 最后再说点实用的小技巧我在实际项目里养成了几个习惯对你有参考价值。第一个习惯是准备一个静态工具方法统一管理文本读取项目中所有人都用这一个方法而不是直接在业务代码里写new FileReaderpublic static String readText(String filePath, Charset charset) throws IOException { return new String(Files.readAllBytes(Paths.get(filePath)), charset); }这个方法只对中小文件适用但把编码选择集中到了一个地方排查问题时少浪费很多时间。第二个习惯是确认文件编码后再动手。项目里上传的文件来源不可控UTF-8、GBK、UTF-16都可能出现我会先用ICU4J的CharsetDetector做初步判断再结合业务方对文件来源的了解确认。纯靠猜测写代码等于把地雷埋给后面接手的人。第三个习惯是读写文件的资源释放无论用不用try-with-resources都要确保close()会被执行。流没关造成文件句柄泄漏在Windows上会导致文件被锁、无法删除在Linux上则可能导致句柄耗尽进程抛Too many open files异常。虽然这事低级但确实是生产环境最常出现的问题类型之一。FileReader和FileWriter本身不是什么高性能武器它们是理解Java字符I/O体系的入口。搞明白了它们的设计逻辑和边界再去选择InputStreamReader、BufferedReader还是Files工具类就会很自然。核心原则无非三条文本文件用字符流二进制文件用字节流编码永远显式指定。