Java中Reader读取字符异常：为何'¸'被识别为65533？

首先，65533是Unicode的替换字符（�），出现这个值说明你的代码在解码文件字节时，遇到了当前编码无法识别的字节序列，只能用替换字符兜底。

问题出在代码的编码处理逻辑 #

你用的FileReader会默认使用JVM平台的默认编码来解码文件（比如Windows下通常是GBK，Linux/macOS是UTF-8），但你的.xs文件的实际编码大概率和这个默认编码不匹配，导致解码失败。

比如你提到的ASCII 184对应的字符'¸'，在Windows-1252编码里它是单个字节184，但如果用UTF-8解码，184不是有效的UTF-8字节（UTF-8多字节字符的首字节范围是192-255，且后续字节有规则），所以会被替换成65533。

解决步骤 #

1. 确认文件的实际编码 #

在IntelliJ里打开ala.xs，看窗口右下角会显示当前识别的编码；或者通过File -> File Properties -> File Encoding查看文件的编码设置。

2. 修改代码，指定正确编码读取 #

替换FileReader为InputStreamReader，它支持手动指定文件编码，示例代码如下：

import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.Reader;

public class Main {
    public static void main(String[] args) throws IOException {
        // 把这里的编码改成你实际的文件编码，比如Windows-1252、UTF-8等
        try (Reader reading = new InputStreamReader(new FileInputStream("ala.xs"), "Windows-1252")) {
            int character;
            while ((character = reading.read()) != -1) {
                char ch = (char) character;
                System.out.println((int) ch);
            }
        }
        // try-with-resources会自动关闭流，不用手动调用close()
    }
}

3. 验证结果 #

如果编码指定正确，原本输出65533的位置会显示对应字符的正确Unicode码点（比如'¸'的码点就是184）。

额外提示 #

• 不要依赖平台默认编码，读取文件时始终明确指定编码，避免跨环境出现兼容问题。
• 如果调整编码后还是有问题，检查文件是否被保存时就出现了编码损坏，比如用错误编码保存过文件。

内容的提问来源于stack exchange，提问作者Michał Jagodzinski