Java DataInputStream.readFully 读不满时怎么区分文件截断

导入定长二进制记录时，最容易误判的是“这次 read 返回的字节比要求少”。少读本身不等于文件截断：InputStream.read(byte[], off, len) 允许一次只返回一部分数据，只要返回值不是 -1，后面仍可能有内容。真正需要判断“记录是否被截断”，应让 DataInputStream.readFully 负责填满目标范围；如果流提前结束，它会抛出 EOFException。

官方文档：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/io/DataInputStream.html

为什么 read 读不满不能直接判定文件截断

普通读取方法的契约是“最多读取指定长度”。例如请求 4096 字节时，本次可能只拿到 700 字节，调用方需要继续读取。只有在没有读到任何字节且已经到达流末尾时，read 才返回 -1。因此，把一次返回值小于缓冲区长度当成坏文件，会把正常的分段输入误报成截断。

这也是定长协议读取中不建议手写一次 read 判断的原因。你真正关心的是“目标区间是否已填满”，而不是某一次底层调用恰好返回了多少。

用 readFully 把提前结束变成明确的 EOFException

当记录长度已经确定，例如每条记录必须有 128 字节，可以直接把记录缓冲区交给 readFully：

import java.io.DataInputStream;
import java.io.EOFException;
import java.io.IOException;
import java.io.InputStream;

static void readOneRecord(InputStream source) throws IOException {
    byte[] record = new byte[128];

    try (DataInputStream in = new DataInputStream(source)) {
        // readFully 只在 128 字节全部到齐后返回；提前到达 EOF 就抛出 EOFException。
        in.readFully(record);
        // 这里才把 record 交给解析器，避免半条记录进入业务层。
        parseRecord(record);
    } catch (EOFException e) {
        // 定长记录未读满，按输入文件截断记录处理，不要当成空记录。
        throw new IOException("定长记录不足 128 字节，输入可能被截断", e);
    }
}

static void parseRecord(byte[] record) {
    // 示例只保留边界：实际项目中在这里解析字段并校验记录版本。
}

这里的关键不是异常名称本身，而是调用位置：只有在 readFully 返回后，业务层才拿到完整记录。EOFException 表示流在所需字节数之前结束；如果是磁盘读取或网络读取本身发生故障，则应保留并区分普通 IOException，不能一律归类为文件格式问题。

偏移量场景要补齐剩余区间

有些解析器会先读到记录头，再把后续字段写入同一数组。这时使用带偏移量的重载，off 是写入起点，len 是必须补齐的字节数：

static void readPayload(DataInputStream in, byte[] frame, int headerLength, int payloadLength)
        throws IOException {
    // 先检查长度，避免 off + len 超出数组范围而得到参数异常。
    if (headerLength  frame.length - payloadLength) {
        throw new IllegalArgumentException("帧缓冲区不足以容纳头部和负载");
    }

    try {
        // 只填充负载区间，不覆盖前面已经解析过的头部。
        in.readFully(frame, headerLength, payloadLength);
    } catch (EOFException e) {
        // 头部存在但负载不完整，仍然是当前帧截断，而不是一条合法短帧。
        throw new IOException("负载未读满，当前帧不完整", e);
    }
}

如果前面已经用一次普通 read 取得了部分负载，后续只能补齐 remaining = expected - received，并把写入偏移移动到 received。更简单的做法是从一开始就让 readFully 管理整个区间，避免自行维护计数时漏掉末尾边界。

按输入意图选择方法

生产导入可以把“期望记录数、当前记录索引、期望长度、已读长度、文件标识”写入失败日志。这样恢复任务时能判断是源文件不完整，还是读取介质本身异常；不要仅记录一行“EOF”。

常见问题

readFully 会一次底层读取就完成吗？

不保证。它可以在内部多次读取，直到目标区间填满或输入提前结束；调用方只需要处理成功返回和异常边界。

EOFException 是否说明文件一定损坏？

不一定。它只说明当前调用要求的字节数没有读满。若协议允许文件在记录边界自然结束，调用方应先判断是否还有下一条记录，再决定是否把它报告为异常。

为什么不能用 available 判断剩余记录长度？

available 只是“不阻塞时可读取字节数”的估计，不是完整文件长度，也不适合作为定长记录完整性的依据。

结论很明确：判断固定记录是否截断，看 readFully 是否在目标区间填满前收到 EOF；判断普通读取是否正常，则看累计读取逻辑和最终 EOF，不要把一次少读当成文件结束。