不丢字符的关键是解码准、缓冲稳、边界清:必须显式指定UTF-8编码(禁用FileReader/FileWriter默认编码),配用BufferedReader/BufferedWriter,读取用readLine(),写入前flush,关闭用try-with-resources。

用字符流读写文本时,不丢字符的关键不是“读得快”,而是“解码准、缓冲稳、边界清”。FileReader 和 FileWriter 默认依赖系统编码,一旦和文件真实编码不一致,中文就容易被截断或跳过——这不是丢数据,是根本没正确识别字符边界。
明确指定字符编码,别信默认值
FileReader/FileWriter 构造时不支持传入编码参数,它们内部硬编码使用 系统默认编码(Windows 常是 GBK,Linux/macOS 多为 UTF-8)。如果文件是 UTF-8 编码,但在 Windows 上用 FileReader 直接读,一个中文字符的三个字节会被错误拆成两段处理,导致部分字符无法还原。
- 改用 InputStreamReader + FileInputStream 组合,显式指定编码: new InputStreamReader(new FileInputStream("a.txt"), "UTF-8")
- 同理,写入时用 OutputStreamWriter + FileOutputStream: new OutputStreamWriter(new FileOutputStream("b.txt"), "UTF-8")
- 开发中建议统一约定文件编码为 UTF-8,并在所有字符操作处强制声明,避免环境差异引发隐性丢失
用带缓冲的字符流,避免单字符读写
FileReader.read() 每次只返回一个 int(对应一个 char),看似简单,但实际底层仍需按字节块解码。若手动循环调用 read() 且未配合缓冲,容易在边界处因缓冲区未填满而提前结束,尤其遇到换行符或文件末尾的不完整字符序列时。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式,或要求按照代码注释规范处理 Java 文件时,使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则,并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括:补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 优先使用 BufferedReader 和 BufferedWriter,它们自带 8KB 缓冲区,能自动对齐字符边界
- 读取推荐按行:readLine() 内部会完整解析一行,不会在中文中间切断
- 写入时用 newLine() 而非 "\n",确保换行符符合当前平台规范,避免后续读取错位
关闭前务必 flush,尤其写入场景
FileWriter 和 BufferedWriter 都有内部缓冲区。如果只 close() 不 flush(),最后一批尚未写出的字符可能滞留在内存中,随着 JVM 退出而丢失——这不是编码问题,是资源释放顺序导致的静默丢数据。
- 使用 try-with-resources 时,close() 会自动触发 flush(),相对安全
- 若手动管理流,必须在 close() 前显式调用 flush()
- 注意:FileWriter 的构造方法若传入 true(追加模式),flush 后内容会追加到文件末尾,不会覆盖,但依然要保证 flush 成功
检查文件末尾是否含 BOM 或非法字节
有些编辑器(如 Windows 记事本)保存 UTF-8 文件时会添加 BOM(EF BB BF),而 FileReader 不识别 BOM,可能把前三个字节当乱码跳过,造成首字符“消失”的假象;另外,文件若被异常中断写入,末尾残留半截 UTF-8 字节序列(如只剩两个字节的“汉”),解码器会静默跳过该字符。
- 用十六进制编辑器确认文件真实编码和结尾字节
- 读取时可先用字节流检查前几个字节是否为 BOM,再决定是否跳过
- 生产环境建议用 Apache Commons IO 的 FileUtils.readFileToString(file, "UTF-8"),它内置 BOM 处理逻辑
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










