Java Commons Codec怎样流式计算文件摘要

Java Commons Codec 计算文件摘要时，优先把文件当成 InputStream 交给 DigestUtils，而不是先调用 Files.readAllBytes。这样摘要方法可以边读边更新内部的 MessageDigest，调用方只需要负责输入流的生命周期和算法选择。小文件可以直接使用 File 或 Path 重载；需要自定义摘要对象、组合多个输入或接入已有流时，再使用 updateDigest。

官方地址：https://commons.apache.org/proper/commons-codec/

官方 API：https://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/digest/DigestUtils.html

先按输入来源选流式入口

Commons Codec 的 DigestUtils 同时提供 InputStream、File 和 Path 入口。三者最终都围绕 MessageDigest 消费字节，但资源控制权不同：已有网络流、上传流或压缩解码流时选择 InputStream；本地文件路径明确且希望由库打开文件时选择 File 或 Path。

用 InputStream 计算大文件摘要

当输入已经是流时，最短写法是使用实例方法 digestAsHex(InputStream)。它的返回值是十六进制字符串，避免调用方再写一段字节数组转字符串的代码。下面的示例只把文件内容交给流读取，不创建整文件的 byte[]。

import java.io.IOException;
import java.io.InputStream;
import java.nio.file.Files;
import java.nio.file.Path;
import org.apache.commons.codec.digest.DigestUtils;

public class FileDigestExample {
    public static String sha256Hex(Path path) throws IOException {
        // try-with-resources 负责关闭文件描述符，避免批量任务积累句柄。
        try (InputStream input = Files.newInputStream(path)) {
            // DigestUtils 按流读取并返回 SHA-256 的十六进制摘要。
            return DigestUtils.sha256Hex(input);
        }
    }
}

这里的关键不是方法名更短，而是输入边界保持为流。若文件在读取期间被替换，摘要反映的是这次读取实际得到的字节；若业务需要稳定版本，应在上层先定义文件锁、临时文件或对象存储版本号策略，不能把摘要方法当成并发一致性方案。

什么时候需要自己持有 MessageDigest

便捷方法适合“一个输入对应一个摘要”的任务。如果一个摘要需要按顺序合并多个输入，或者算法对象要由工厂统一创建，就可以把 MessageDigest 交给 updateDigest，最后只调用一次 digest()。

import java.io.IOException;
import java.io.InputStream;
import java.nio.file.Files;
import java.nio.file.Path;
import java.security.MessageDigest;
import org.apache.commons.codec.binary.Hex;
import org.apache.commons.codec.digest.DigestUtils;

public class DigestStateExample {
    public static String sha256Hex(Path first, Path second) throws IOException {
        // 由工具类创建算法实例，避免手写 NoSuchAlgorithmException 处理。
        MessageDigest digest = DigestUtils.getSha256Digest();
        try (InputStream left = Files.newInputStream(first);
             InputStream right = Files.newInputStream(second)) {
            // 两个流按调用顺序进入同一个摘要状态，结果对应拼接后的字节序列。
            DigestUtils.updateDigest(digest, left);
            DigestUtils.updateDigest(digest, right);
            // digest() 会结束当前状态；不要在同一实例上误以为它还能续接上一轮。
            return Hex.encodeHexString(digest.digest());
        }
    }
}

这段写法的适用边界很窄：它表达的是“先读 first，再读 second”的组合摘要，不等同于分别计算两个文件后再拼接两个十六进制字符串。如果业务要求两个文件独立校验，就应该为每个文件建立独立的摘要调用。

便捷方法、File/Path 与手动状态怎么取舍

可以把选择规则压缩成三个问题。第一，输入是否已经是一个必须继续消费的流？是，就用 InputStream 重载。第二，是否只有一个本地文件，并且不需要组合输入？是，就用 File 或 Path 重载。第三，是否要组合多个来源、统一算法创建或在摘要前后插入额外处理？是，就持有 MessageDigest，并通过 updateDigest 明确数据边界。

大文件场景的四项回收清单

1. 资源：自己打开的 InputStream 放进 try-with-resources；不要把关闭责任藏在业务回调里。
2. 输入位置：摘要前确认流尚未被其他逻辑读取；对已经读过一部分的流，摘要只覆盖剩余字节。
3. 算法：发送方和接收方固定算法名称，不能一边使用 SHA-256、一边把 MD5 字符串当成同类结果比较。
4. 输出：跨接口传递时统一十六进制大小写和字符编码；需要二进制存储时保留原始 byte[]，不要来回转换。

如果只需要为单个文件生成校验值，优先用 DigestUtils.sha256Hex(InputStream) 或对应的 File/Path 入口；如果需要把多个流纳入同一摘要，才把 MessageDigest 生命周期显式拿到代码中。这样既保持流式读取，也能让资源、输入顺序和结果格式一眼可见。

相关问题

DigestUtils.digestAsHex(InputStream) 会把大文件一次性读进内存吗？

官方 API 将它定义为从 InputStream 读取并返回摘要字符串，调用方不需要先构造整文件字节数组。内存上限仍受流实现、缓冲策略和外围业务代码影响。

File 和 Path 重载应该选哪个？

新代码通常保留 Path，因为它和 NIO 文件 API 的组合更自然；老接口已经使用 File 时直接使用 File 重载即可，没必要为了换类型增加一层转换。

为什么调用 digest() 后不能继续追加同一轮数据？

digest() 会完成当前摘要并结束这次状态。若要计算另一份独立数据，应创建新的摘要实例或使用新的便捷方法调用，避免把多轮数据误合并。