批量文件哈希与清单验证器
一次
批量选择或拖入多个文件，本页就在浏览器内算出每个文件的 MD5、SHA-1、SHA-256、SHA-384 或 SHA-512 摘要。然后既可以把结果复制成
sha256sum 兼容行放进你的发布说明，也可以粘贴一份校验和清单（
SHA256SUMS、
.sha256、
.sfv、BSD
openssl dgst 输出），让页面告诉你哪些文件通过验证、哪些不匹配、哪些缺失。任何东西都不会被上传。
单文件、更多算法见
哈希生成器。
1. 选择文件
拖放文件到此处，或点击选择
最多 50 个文件、每个 200 MB。文件始终留在本机。
未选择任何文件。
2. 算法
— 十六进制输出；至少勾选一个。
3. 结果
点击任意摘要单元格即可复制。名称和大小总是列出，因此表格也可当批量文件大小视图用。
4. 对照清单验证（可选）
粘贴 GNU（哈希 文件名）、BSD（SHA256 (name) = hash）、SFV（文件名 crc32）或 plain（sha256=哈希）格式的清单，或直接上传 .sha256 / SHA256SUMS / .sfv 文件本身。以 ; 开头的行视为注释。
隐私：每个摘要都由浏览器自己的 JavaScript 与 WebCrypto 引擎计算 — 文件从不离开这个标签页。提示：验证完下载后直接关闭本页即可，什么都没有存储。
什么是批量文件哈希？
校验和是文件的一份简短指纹：把文件的字节喂给哈希函数，得到的摘要在文件哪怕一个字节改变时几乎必然改变。软件发布方把摘要登在下载旁边，让你能证明收到的文件就是他们发出的那份 — 下载没有被截断或损坏，也没有人调包成别的内容。
一次下一个文件，对单个下载来说没问题。一旦你面对的是一个文件夹，或内含 SHA256SUMS 清单的发布包，就需要批量版：每个文件哈希一次，再把清单每一行对到相应文件上核对。本页自动化的正是这个循环。
本页能读的清单格式
| 样式 | 示例行 | 出处 |
|---|
| GNU | 900150983c... hello.txt | sha256sum / md5sum 输出，Linux 发行版的 SHA256SUMS 文件 |
| BSD | SHA256 (hello.txt) = 900150983c... | macOS/BSD 上的 openssl dgst -sha256 |
| SFV | hello.txt 1A2B3C4D | Simple File Verification 文件，老式二进制新闻组 |
| plain | sha256=ba7816bf... | 下载页、发布说明、Docker checksums |
哈希长度本身就说明了算法：32 个十六进制字符是 MD5，40 是 SHA-1，64 是 SHA-256，96 是 SHA-384，128 是 SHA-512 — 所以 GNU 格式的行不需要注明是哪个程序生成的。
简要工作原理
每个文件由浏览器的 FileReader 读取一次，交给 crypto.subtle.digest（SHA 家族）和本地 MD5 实现。摘要按十六进制编码，与清单条目一一对齐；只有当计算出的摘要与期望值逐字符相等时，文件才算通过验证。SFV 行携带的是 CRC-32 而不是密码学哈希 — 本页会将其标记为不支持，而不是假装 CRC 等同于摘要。
常见错误
「我所有文件都不匹配。」 — 原因通常是清单对应的是另一个版本的下载。先核对文件名：匹配器比较的是基本名，所以 dist/app-1.2.bin 能匹配清单里的 app-1.2.bin。「SHA-1 验证通过，文件就安全了？」 — 不是。验证只证明字节与发布方发布的一致；发布方是否可信是另一个问题。而且 SHA-1 自 2017 年起已被碰撞攻破，有得选时优先用 SHA-256 清单。
常见问题
哈希大文件慢吗？ — 普通机器上大约每 200 MB 一秒；进度行会显示批次的进度。
能验证 CRC-32 的 SFV 清单吗？ — SFV 行会被解析并列出，但本页不计算 CRC-32；单文件请用加密中心的 CRC 工具。
为什么只有十六进制？ — 实际流传的清单都是十六进制；base64 摘要算附加功能。
我的文件会怎样？ — 什么都不发生：没有服务器、没有存储、没有分析；关掉标签页，输入的每个字节都消失了。
自测