文件哈希校验工具

计算文件的 MD5、SHA-1、SHA-256、SHA-384、SHA-512 哈希值

上传文件

拖拽文件到此处

支持任意文件类型和大小

选择哈希算法

MD5

128 位

SHA-1

160 位

SHA-256

256 位

SHA-384

384 位

SHA-512

512 位

校验比对

什么是文件哈希？

文件哈希会用指定算法把文件内容计算成固定长度的摘要。同一个文件在同一算法下总会得到相同结果，而哪怕只改动一个字节，也可能产生完全不同的哈希值。它常用于校验下载文件、比较备份、识别重复文件、确认传输完整性，或与软件发布页和安全公告中的校验值进行核对。本工具支持 MD5、SHA-1、SHA-256、SHA-384、SHA-512 等算法。MD5 和 SHA-1 在旧流程中仍会出现，但不适合现代安全保证；需要可靠完整性校验时通常应选择 SHA-256 或更强算法。哈希值不能反推出原文件内容。

使用方法

使用步骤

将文件拖到上传区域，或点击「选择文件」按钮
勾选需要计算的哈希算法（支持多选）
点击「计算哈希」按钮开始
计算完成后，可复制单个哈希值或一键全部复制
如需验证，请在对比栏中输入已知哈希值

验证流程

请在文件完整下载或复制完成后再计算哈希；不完整的文件或传输中断会得到不同的值。
与已发布的校验和比对时，请从官方渠道获取，并确保算法完全一致。

使用场景

一次上传计算多种文件摘要拖入文件并任意勾选 MD5（128 位）、SHA-1（160 位）、SHA-256（256 位）、SHA-384（384 位）、SHA-512（512 位），即可在本地以进度反馈生成哈希。文件读入内存后交给 crypto.subtle.digest（SHA 系列）或 JavaScript MD5 例程在浏览器内完成计算，二进制内容不会离开设备，适合专有固件、内部构建、未发布产物等场景。

将已发布的校验和与所选算法进行比对在计算前后粘贴预期的哈希值，当某个生成值与比对字符串相等时，页面会自动识别匹配的算法。比对基于规范化的小写十六进制进行，因此发布方提供的大写摘要和本地生成的小写摘要无需手动转换即可匹配。

在需要信任判断时使用更强的哈希算法MD5 和 SHA-1 适用于旧系统兼容和重复文件检测（两者均已公开碰撞攻击），但在下载验证和防篡改场景中应选择 SHA-256 或更强的算法。SHA-256 生成 64 字符的十六进制摘要，目前没有已知碰撞；SHA-384/512 在高保障发布流程中提供更高安全等级。对于超大型发布制品，BLAKE3 越来越常见，因为它在现代 CPU 上比 SHA-256 快约三到四倍（持续吞吐量达 GB/s 级别），同时保持支持验证流式读取的 Merkle 树设计，不过本工具的算法选择器仍覆盖大多数发布方公布的 SHA 系列。

对分卷压缩包的每个分卷分别计算哈希大型下载常被切成 .001、.002 或 .zipx 等分卷，并附带每段哈希（多为 SHA-1 或 SHA-256）。合并前先把每个分卷与厂商公布的列表逐一比对——只要有一段对不上，重新拼出的文件就会损坏。本页可对所有分卷使用同一算法，无需上传。每个分卷会先在浏览器内读入内存再计算，因此实际上限取决于当前标签页可用堆；超过该上限时请改用从磁盘流式读取的桌面工具（sha256sum、certutil -hashfile、Get-FileHash）。

用比对字段实现大小写无关匹配有些发布方使用大写十六进制，有些使用小写。粘贴一次预期值后，页面会按算法标识和规范化大小写进行匹配，无需手动逐字符调整大小写即可完成验证——'A591A6...' 和 'a591a6...' 形式的同一摘要都能成功匹配。

技术原理

页面中所有 SHA 摘要都通过 W3C Web Cryptography API（浏览器中以 crypto.subtle 暴露）计算。调用形式为 await crypto.subtle.digest(algorithm, buffer)，其中 algorithm 取 'SHA-1'、'SHA-256'、'SHA-384' 或 'SHA-512'（大小写敏感），buffer 是 ArrayBuffer 或任意 TypedArray。函数返回一个 Promise，解析得到摘要字节的 ArrayBuffer，页面再以 new Uint8Array 遍历并将每字节映射为 byte.toString(16).padStart(2, '0') 得到小写十六进制。SubtleCrypto 仅在安全上下文（HTTPS 或 localhost）下可用；SHA-1 仍保留以兼容遗留场景，但规范明确指出其抗碰撞性已被打破。 MD5 不在 Web Crypto 规范内（W3C 因碰撞攻击有意省略），所以本页面的 MD5 由完全在浏览器内运行的纯 JavaScript 实现完成。无论 MD5 还是 SHA 系列，本工具都通过 FileReader.readAsArrayBuffer 一次性把文件读为 ArrayBuffer，再交给 JavaScript MD5 例程或 crypto.subtle.digest 处理。本工具不提供 .append 增量接口，也不使用 Web Worker 回退，因此内存必须能装下整个文件：常见下载没问题，但多 GB 负载更适合改用从磁盘流式读取的桌面工具（sha256sum、certutil -hashfile、Get-FileHash）。摘要长度与安全态势：MD5 = 128 位 / 32 个十六进制字符（RFC 1321，王小云 2004 起抗碰撞被打破，2012 年被 Flame 恶意软件实战利用）；SHA-1 = 160 位 / 40 个十六进制字符（FIPS 180-4，Google 在 2017 年 SHAttered 中以约 9.2 ×10^18 次 SHA-1 运算公开碰撞，NIST 计划于 2030 年后正式弃用）；SHA-256 = 256 位 / 64 个十六进制字符（FIPS 180-4，目前无已知碰撞，是推荐基线）；SHA-384 与 SHA-512 = 384 / 512 位，是 SHA-512 家族的截断与完整输出（FIPS 180-4）。密码学哈希的雪崩效应意味着输入翻转 1 比特平均会改变约一半输出比特，这也是为什么改动一个字节就会得到完全不同的摘要。

crypto.subtle.digest(algorithm, buffer) 接受 'SHA-1'、'SHA-256'、'SHA-384'、'SHA-512'（区分大小写），拒绝 'MD5'；需要安全上下文（HTTPS 或 localhost），返回 Promise<ArrayBuffer>。
十六进制编码：遍历结果 new Uint8Array(digestBuffer)，将每个字节映射为 byte.toString(16).padStart(2, '0')；摘要比对时大小写不敏感（通过 .toLowerCase() 规范化）。
MD5 不在 Web Crypto 内（规范有意省略）；本工具用纯 JavaScript 计算 MD5，通过 FileReader.readAsArrayBuffer 一次性把文件读为 ArrayBuffer，单次产出 32 个小写十六进制字符的摘要。
内存特点：页面会把整个文件一次性读入单一 ArrayBuffer（没有 .append 增量接口，也不卸载到 Web Worker），再一次性交给 JavaScript MD5 或 crypto.subtle.digest 处理。文件超过当前标签页可用堆时，请改用从磁盘流式读取的桌面工具（sha256sum、certutil -hashfile、Get-FileHash）。
摘要大小（FIPS 180-4）：MD5 128 位，SHA-1 160 位，SHA-256 256 位，SHA-384 384 位，SHA-512 512 位；十六进制字符数为字节数的两倍。
已知碰撞攻击：MD5 被王小云 2004 年破解，2012 年被 Flame 利用；SHA-1 被 Google SHAttered 2017 年破解（约 9.2 × 10^18 次运算，约 110 GPU 年）；SHA-256 及以上无已知实际碰撞。
雪崩效应：输入翻转一个比特平均翻转约 50% 的输出比特；这就是为什么一字节编辑会产生完全不同的十六进制摘要，也是部分文件匹配不可能存在的原因。

示例

用官方校验值验证下载文件

文件：sample.bin（3 字节，内容：abc）

SHA-256（计算值）：
  ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

发布方公布的 SHA256SUMS 行：
  ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad  sample.bin

一致 -> 下载完整，未被篡改

（这两个值都是 FIPS 180-2 中针对 3 字节输入 'abc' 的
SHA-256 标准向量。实际使用时换成真实文件即可，
算法输出是确定性的。）

对同一输入的多算法对比

文件： sample.txt（3 字节，内容：abc）

MD5:     900150983cd24fb0d6963f7d28e17f72
SHA-1:   a9993e364706816aba3e25717850c26c9cd0d89d
SHA-256: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
SHA-512: ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f

相同输入、不同算法 -> 安全校验请使用 SHA-256 或更强算法

（MD5 来自 RFC 1321 标准向量，其余来自 FIPS 180-2 标准向量，
均针对 3 字节输入 'abc'。）

检测 1 字节差异（雪崩效应）

输入 A：abc（3 字节）
输入 B：abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq（56 字节）

A 的 SHA-256：ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
B 的 SHA-256：248d6a61d20638b8e5c026930c3e6039a33ce45964ff2167f6ecedd419db06c1

输入的微小变化会产生完全不同的摘要 -> 这就是雪崩效应。

（两个值都是 FIPS 180-2 SHA-256 标准向量。）

在浏览器控制台中复核

// 在 Node.js 中复算对照
$ printf 'abc' | shasum -a 256
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

// Windows 下的 PowerShell
PS> 'abc' | Get-FileHash -Algorithm SHA256 | Select-Object -ExpandProperty Hash
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

// 浏览器控制台中使用 Web Crypto API：
// const buf = new TextEncoder().encode('abc');
// const hash = await crypto.subtle.digest('SHA-256', buf);
// -> 'abc' 的 SHA-256 ArrayBuffer（FIPS 180-2 标准向量）

文件全程留在浏览器中，不会上传。

常见问题

支持生成哪些哈希算法？

常见选项有 MD5、SHA-1、SHA-224、SHA-256、SHA-384 和 SHA-512。SHA 系列由浏览器的 Web Crypto API 计算，MD5 由内置 JS 实现完成。如今通用场景推荐选 SHA-256。

文件会被上传吗？

不会。哈希计算完全通过 File API 和 Web Crypto 在浏览器中进行。文件字节会分块读入内存并在本地计算哈希——文件不会经过网络。你可以在哈希过程中查看“网络”面板来验证。

MD5 既然已经被攻破了，为什么还提供？

MD5 在安全用途上已被攻破（碰撞容易构造），但仍是验证下载文件与源文件字节一致的事实标准——许多供应商至今会同时给出 MD5 和 SHA-256。MD5 仅可用于此场景，绝不要用于密码哈希或签名。

为什么看起来一样的文件，SHA-256 却不同？

哈希以每一个字节为输入，因此末尾多一个换行、一个 BOM，或换行符不同（CRLF 与 LF）都会让哈希完全不同。请重新下载原文件，而不是复制粘贴；或用二进制查看器确认两个文件的字节完全一致。

文件大小有限制吗？

浏览器需要分配足够内存来读取文件。现代桌面浏览器可以处理数 GB 的文件，但移动端在几百 MB 时就可能因内存不足而失败。超大文件建议用桌面工具（sha256sum、certutil、Get-FileHash），它们会从磁盘流式读取，速度也更快。

两个不同的文件可能产生相同的哈希吗？

理论上可能（鸽巢原理），但 SHA-256 出现碰撞的概率极低。MD5 和 SHA-1 已经存在已知的碰撞攻击，所以 MD5 或 SHA-1 一致并不能证明文件相同。SHA-256 在已知攻击下尚不可行被构造碰撞。

为什么我算的哈希和官网公布的不一致？

最常见的原因是：你下载的是本地化、已签名或重新打包的版本；页面公布的是另一个版本的哈希；或下载本身被截断了。换个工具重新下载并再次哈希，如果仍然对不上，就不要信任该文件。