Java程序读取Huffman编码的二进制文件时出现大量11111101（即0xFD），根本原因是误用字符流（如FileReader）处理纯二进制数据，导致UTF-8/Unicode解码失败后插入替换字符`（U+FFFD），其字节值为0xFFFD，低位字节恰好为0xFD`。
java程序读取huffman编码的二进制文件时出现大量`11111101`（即`0xfd`），根本原因是误用字符流（如`filereader`）处理纯二进制数据，导致utf-8/unicode解码失败后插入替换字符``（u+fffd），其字节值为`0xfffd`，低位字节恰好为`0xfd`。
Huffman编码生成的是原始字节序列，而非可读文本——每个字节都承载着压缩后的比特流，可能包含任意0–255范围内的值（包括非ASCII、控制字符甚至无效UTF-8字节序列）。而FileReader和BufferedReader是专为文本（character-based I/O） 设计的流，它们会按指定字符集（默认平台编码，通常是UTF-8）尝试将字节解码为Java char（16位Unicode码点）。当遇到无法解码的字节组合（如孤立的0xBD、0xFF等）时，Java会静默插入Unicode替换字符`（U+FFFD），其UTF-8编码为0xEF 0xBF 0xBD；但在你当前的代码中，由于FileReader以单字节方式错误映射（尤其在平台编码非UTF-8时），常见表现为将非法字节直接映射为0xFD（即U+FFFD的低8位），从而造成所有异常字节被统一“污染”为11111101`。
✅ 正确做法：使用字节流（byte-based I/O） 直接读取原始字节，绕过任何字符编码/解码过程：
import java.io.*;
public static void main(String[] args) throws IOException {
try (FileInputStream fis = new FileInputStream(property);
BufferedInputStream bis = new BufferedInputStream(fis);
FileWriter fw = new FileWriter("out.txt");
BufferedWriter bw = new BufferedWriter(fw)) {
printRemainingBytes(bis); // 注意：此处应传入 InputStream，而非 Reader
bw.close();
}
}
static void printRemainingBytes(InputStream is) throws IOException {
System.out.println("\nRemaining Bytes (binary):");
int b;
while ((b = is.read()) != -1) {
printByteBits((byte) b);
}
}
static void printByteBits(byte b) {
for (int i = 7; i >= 0; i--) {
int bit = (b >> i) & 1;
System.out.print(bit);
}
System.out.print(" ");
}
⚠️ 关键注意事项：
- 绝不使用 FileReader/BufferedReader 处理二进制文件：它们强制执行字符解码，是Huffman解码器出错的最常见根源；
- InputStream.read() 返回 int（0–255），需强制转为 byte 再进行位运算，否则高位补零逻辑错误（如 0xFF 读作 255，但 (int)255 >> 7 & 1 正确；若误用 char 则符号扩展会导致异常）；
- 若需同时处理文件头或元数据（如长度、树结构），也应统一采用字节流，并自行解析二进制协议；
- Huffman解码器后续需基于真实字节流构建比特缓冲区（bit buffer），逐位消费，而非按字节直接解释。
总结：二进制即二进制。坚持“字节流进、字节流出”，是实现可靠无损Huffman编解码的第一铁律。修复I/O层后，你的比特序列将与外部工具（如xxd或专用二进制查看器）完全一致，解码逻辑才能进入真正调试阶段。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
