3. 文件完整性校验：哈希算法原理与实战

文件完整性校验，说白了就是回答一个问题：你拿到的这个文件，到底是不是它声称的那个样子？

我在做升级包分发时，最怕的就是文件在传输过程中被篡改，或者下载了一半就断了。你想想看，一个损坏的升级包刷进设备，轻则功能异常，重则直接变砖。所以，哈希算法就是我们用来给文件做「数字指纹」的工具。

3.1 哈希算法：文件的「数字指纹」

哈希算法，也叫散列函数。它能把任意长度的数据，映射成一个固定长度的字符串。这个字符串就是哈希值，或者叫摘要。

它有几个关键特性：

• 单向性：从哈希值无法反推出原始数据。这是安全的基础。
• 抗碰撞性：两个不同的文件，几乎不可能算出相同的哈希值。
• 雪崩效应：文件哪怕只改了一个比特，哈希值也会变得面目全非。

3.2 主流哈希算法：MD5、SHA-1、SHA-256

目前常用的算法就三种。我按出场顺序和安全性给你捋一捋。

算法	输出长度	安全性	我的建议
MD5	128 位 (32 位十六进制)	已破解，可人为构造碰撞	仅用于非安全场景，比如校验下载完整性
SHA-1	160 位 (40 位十六进制)	已过时，理论上有攻击方法	尽快迁移，不要再用于新项目
SHA-256	256 位 (64 位十六进制)	安全，目前无有效攻击	新项目首选，安全校验的底线

3.3 实战：计算与比对哈希值

理论说完了，咱们直接上手。我习惯用命令行，因为最直接、最可控。

3.3.1 在 Linux/macOS 上计算

# 计算 MD5
md5sum firmware_v2.0.bin

# 计算 SHA-1
sha1sum firmware_v2.0.bin

# 计算 SHA-256
sha256sum firmware_v2.0.bin

3.3.2 在 Windows 上计算

# 计算 MD5
certutil -hashfile firmware_v2.0.bin MD5

# 计算 SHA-1
certutil -hashfile firmware_v2.0.bin SHA1

# 计算 SHA-256
certutil -hashfile firmware_v2.0.bin SHA256

输出结果大概长这样：

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

拿到哈希值后，怎么比对？很简单，肉眼对比或者字符串对比。你从官方渠道拿到一个哈希值，然后跟自己算出来的比对。完全一致，文件就是完整的。

3.4 校验文件：.md5 与 .sha256

手动比对哈希值太麻烦，也不适合自动化。所以业界约定俗成，把哈希值存成一个文件，随升级包一起发布。

校验文件的格式很简单：

# firmware_v2.0.bin.sha256 文件内容
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  firmware_v2.0.bin

生成校验文件也很简单：

# 生成 .sha256 校验文件
sha256sum firmware_v2.0.bin > firmware_v2.0.bin.sha256

# 生成 .md5 校验文件
md5sum firmware_v2.0.bin > firmware_v2.0.bin.md5

校验时，用 -c 参数：

sha256sum -c firmware_v2.0.bin.sha256

如果输出 firmware_v2.0.bin: OK，说明文件完好无损。

3.5 知识体系：哈希校验流程

下面这张图，把整个流程串起来了。你可以把它当作一个标准操作规范。

3.6 避坑指南与最佳实践

• 不要只依赖一种哈希算法。 我建议至少使用 SHA-256。如果条件允许，可以同时提供 SHA-256 和 SHA-512，给用户多一层保障。
• 校验文件本身也要防篡改。 校验文件如果被改了，那校验就没意义了。所以，校验文件最好通过 HTTPS 分发，或者用数字签名保护起来。这个我们后面章节会讲。
• 注意换行符和空格。 生成校验文件时，sha256sum 的输出格式是固定的。如果你手动编辑，可能会破坏格式，导致校验失败。我建议直接用重定向生成，不要手动改。
• 大文件怎么办？ 哈希算法对文件大小不敏感。一个 1KB 的文件和一个 1GB 的文件，计算时间虽然有差异，但最终输出的哈希值长度是一样的。所以放心用。