Netty分片传输文件时MD5哈希值变更问题

这个问题我做WebSocket文件传输时也碰到过，核心原因出在你处理文件读写的逻辑上——你的代码忽略了FileInputStream.read()方法返回的实际读取字节数，最后一次分片大概率读不满64KB，但你还是把整个缓冲区的内容写进去了，这就导致目标文件多了一些冗余的旧数据，MD5自然就和原文件不一致了。

第一步：修复本地模拟代码的读写逻辑 #

你需要把每次读取到的实际字节数保存下来，然后只写入对应长度的字节，而不是整个缓冲区。修正后的代码如下：

public static void rechunck(File file1, File file2) {
    FileInputStream is = null;
    FileOutputStream os = null;
    try {
        byte[] buf = new byte[1024 * 64];
        int readLen; // 保存实际读取的字节数
        is = new FileInputStream(file1);
        os = new FileOutputStream(file2);
        // 循环读取，直到read返回-1表示文件结束
        while ((readLen = is.read(buf)) != -1) {
            // 只写入实际读取到的字节数
            os.write(buf, 0, readLen);
        }
    } catch (IOException e) {
        e.printStackTrace();
    } finally {
        // 别忘了关闭流资源
        try {
            if (is != null) is.close();
            if (os != null) os.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

第二步：确保Netty WebSocket传输的分片逻辑一致 #

在Netty的发送端和接收端，你需要遵循同样的逻辑：

• 发送端：读取文件分片时，记录每次实际读取的字节数，然后把这个长度的字节数组封装成WebSocket帧发送，不要强制把分片填充到64KB（比如用空字节补全）。
• 接收端：收到WebSocket帧后，只提取帧里的实际有效字节（不要假设每个帧都是64KB），然后写入目标文件，同样要使用write(buf, 0, actualLength)的方式。

额外的验证建议 #

为了避免传输过程中出现丢包或篡改，你可以：

• 给每个分片添加序号和长度标识，接收端可以校验分片的完整性和顺序，避免乱序导致文件损坏。
• 传输前计算原文件的MD5，传输完成后计算目标文件的MD5进行比对，确认文件完整。

内容的提问来源于stack exchange，提问作者Felix Gaebler