这种情况我之前碰到过，大概率是Windows记事本的编码识别“抽风”导致的，结合你描述的细节，咱们一步步拆解：

核心原因分析 #

1. 编码识别机制差异
   Windows记事本对编码的判断非常依赖文件开头的BOM（字节顺序标记）：

   • 如果文件是带BOM的UTF-8，记事本能正常识别；
   • 如果是无BOM的UTF-8，记事本经常会误判成UTF-16或者系统默认的ANSI编码（比如中文系统是GBK）。
     而Hex编辑器和Notepad++会自动检测文件编码，所以能正常显示内容。
     你说之前生成的文件正常，可能是当时的文件开头字节刚好“巧合”让记事本识别对了编码，这次的文件触发了误判（比如开头的数字组合刚好符合UTF-16的字节模式）。

2. 换行符的潜在影响（不是乱码直接原因，但可能叠加问题）
   Android里用的是\n（LF）作为换行符，而Windows传统上用\r\n（CRLF）。虽然这不会直接导致乱码，但记事本对纯LF的换行支持不好，可能会让内容显示得更混乱，加重“乱码”的观感。

解决办法 #

你可以试试这几个方案，快速解决问题：

• 给UTF-8文件添加BOM
  在写入内容前，先往文件里写入UTF-8的BOM字节（0xEF 0xBB 0xBF），强制记事本识别为UTF-8编码。代码示例：

  val file = File(Environment.getExternalStorageDirectory(), "textfile.txt")
  val outputStream = FileOutputStream(file)
  // 写入UTF-8 BOM
  outputStream.write(byteArrayOf(0xEF.toByte(), 0xBB.toByte(), 0xBF.toByte()))
  val writer = OutputStreamWriter(outputStream, StandardCharsets.UTF_8)
  val bufferedWriter = BufferedWriter(writer)
  
  // 正常写入内容
  bufferedWriter.write(String.format("%d\n", intvar))
  bufferedWriter.close()
  

• 使用Windows兼容的换行符
  把代码里的\n改成\r\n，让换行符符合Windows标准，避免内容排版混乱：

  var1BufferedWriter?.write(String.format("%d\r\n", intvar))
  

• 检查写入逻辑的一致性
  对比之前正常的文件和现在异常文件的十六进制内容，看看是否有字节层面的差异（比如是否不小心改了编码、是否混入了额外字节），确认写入逻辑和之前完全一致。

验证方式 #

修改后生成新文件，复制到Windows后：

1. 先用记事本打开，看是否正常显示；
2. 再用Hex编辑器确认内容和BOM是否正确。

备注：内容来源于stack exchange，提问作者user13267