文件哈希计算器，免费

文件哈希到底是什么

密码学哈希是用一个确定性的数学函数，从任意输入数据（一个文件、一段字符串、一段字节流）计算出来的一个定长指纹。每一个不同的输入都会产生不同的输出（对于现代的哈希函数来说，碰撞概率小到几乎可以忽略）；多 GB 的大文件中只要任意翻一个比特，得到的哈希值几乎每一位都会变。这个函数只朝一个方向跑：从输入计算哈希很容易，但要从哈希反推输入，对任何一个像样的哈希函数来说在计算上都是不可行的。无论输入多大，输出都是同样的固定长度，SHA-256 都是 256 位（32 字节，显示为 64 个十六进制字符），不管输入是 1 字节还是 1 TB。三个性质很关键：抗原像（preimage）（你不能从哈希反向推出文件）、抗第二原像（你不能再造一个不同的文件却得到同一个哈希）以及抗碰撞（你找不到任何两个不同的文件哈希值相同）。本编辑器会用浏览器内置的 Web Crypto API 来计算你提供的任何文件的哈希，具体来说就是 SubtleCrypto.digest()，这是每一个现代浏览器都原生实现的接口，运行在你设备的 CPU 上，而不会把文件上传到任何地方。

这些算法，一段简史

本工具里有五种算法，按发布的时间先后排：MD5（Message Digest 5，MIT 的 Ronald Rivest 设计，RFC 1321 于 1992 年 4 月发表）输出 128 位哈希，是 1990 年代和 2000 年代初占主导地位的通用哈希。1996 年开始出现密码学上的弱点（Dobbertin 的伪碰撞）；2004 年 8 月，Xiaoyun Wang 和 Hongbo Yu 在 CRYPTO 2004 上演示了实用的碰撞攻击，单台机器上一小时之内就能完成。Marc Stevens 在 2008 年发表了选择前缀（chosen-prefix）碰撞攻击，可以伪造出相互碰撞的 X.509 证书。MD5 在密码学层面已经彻底报废，任何依赖抗碰撞性的场景都绝对不要再用它（数字签名、证书指纹、密码哈希）。它对非密码学意义上的完整性校验仍然有用（用来发现因为坏盘或网络抖动造成的偶发性损坏），以及在你信任来源不会蓄意作恶的前提下、做内容寻址用。

SHA-1（Secure Hash Algorithm 1，由 NSA 设计，1995 年 4 月作为 FIPS 180-1 发布）输出 160 位哈希，是 1990 年代末到 2010 年代初的主流密码学哈希。Wang、Yin 与 Yu 在 2005 年提出了理论上的攻击。第一次实用的 SHA-1 碰撞由 Marc Stevens 带领的 Google + CWI Amsterdam 团队于 2017 年 2 月 23 日公布（也就是「SHAttered」攻击）他们用了大约 9 京（quintillion）次 SHA-1 计算，造出了两个 SHA-1 哈希完全相同、但内容明显不同的 PDF 文件。在那之前，浏览器其实就已经在分阶段淘汰使用 SHA-1 的 TLS 证书了；现代 Git 也正在把对象身份从 SHA-1 迁到 SHA-256。和 MD5 一样，SHA-1 用来做非密码学的完整性校验没问题，但在 2026 年绝对不该再用在任何依赖抗碰撞性的地方。

SHA-2（NSA，FIPS 180-2 于 2002 年 8 月发布）是当下扛大梁的哈希家族，一组互相关联的函数，包括 SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256。SHA-256 输出 256 位，SHA-384 输出 384 位，SHA-512 输出 512 位；384 在本质上就是 SHA-512 截断输出、再换一个 IV 而已。截至 2026 年，SHA-2 家族还没有任何已知的实用攻击；SHA-256 是新应用的默认选择，也是 Bitcoin（挖矿和地址派生都用它）、TLS 证书指纹、Git 计划中的对象身份迁移、Ethereum 的交易哈希、JWT HS256 签名、以及绝大多数软件分发校验和的背后所用的哈希函数。当 256 位输出还不够、或者你想在 64 位 CPU 上拿到稍微更快一点的速度时，会更倾向于 SHA-512（SHA-512 的内部运算是 64 位的，对比 SHA-256 的 32 位，所以即使输出更大，它在 64 位硬件上每个 CPU 周期能处理更多数据）。

SHA-3（Keccak，由 Guido Bertoni、Joan Daemen、Michaël Peeters 和 Gilles Van Assche 设计，2012 年 10 月赢得 NIST SHA-3 竞赛，2015 年 8 月作为 FIPS 202 标准化）就是密码学意义上的「保单」：它的结构和 SHA-2 完全不同（用的是海绵构造，而不是 Merkle-Damgård），所以即便有什么突破能击破 SHA-2，也未必能击破 SHA-3。SHA-3 目前不在本工具的算法列表里，因为最初版本的 Web Crypto API 并没有把它纳入，未来的现代浏览器有可能加入。在今天，浏览器端做哈希推荐的默认仍然是 SHA-2 家族。

SHA-2 之外的现代选择

出于性能考虑，有两个非 NIST 哈希家族也得到了广泛使用。BLAKE2（Aumasson、Neves、Wilcox-O'Hearn、Winnerlein，2013 年 1 月）在与 SHA-2 相当的安全性下速度更快，被广泛用于加密货币、Argon2 密码哈希，以及 SHA-2 速度成为瓶颈的高性能场景。BLAKE3（O'Connor、Aumasson、Neves、Wilcox-O'Hearn，2020 年 1 月）是一个重新设计的版本，可以在多个 CPU 核心之间并行，速度还要更快，对于很大的文件尤其有吸引力，因为工作可以干净地拆分到多个核心上。它们都不在 Web Crypto API 标准里，所以为了兼容性，本工具仍然只用 SHA-2 家族 + MD5 + SHA-1；要在命令行做 BLAKE3 哈希，规范的实现是 BLAKE3 参考仓库里的 b3sum。在 2026 年，对于浏览器端的文件哈希，SHA-256 仍然是默认选择，除非你有具体的理由要换别的，它兼容性广、没有专利问题、在大多数现代 CPU 上都有硬件加速（Intel SHA Extensions 自 2016 年的 Goldmont 起就有，几乎每一部智能手机的 ARMv8 都有 SHA-2 指令），而且即使是浏览器里几 GB 的大文件也能跑出可以接受的速度。

文件哈希在哪些场景下真正派上用场

• 校验下载下来的文件和发布方给的校验和是否一致。Linux 发行版（Ubuntu、Debian、Fedora、Arch）、开源项目（Node.js、Python、Go），以及对安全敏感的下载（Tor 浏览器、签名过的固件镜像）都会和下载链接一起公开 SHA-256 哈希。下载完成后，本地算一下这个文件的哈希，和官方公布的值逐字符比对，如果对得上，就说明文件完整无缺，没有被篡改、也没有半路下错。
• 找出重复文件。同一份文件不管文件名、所在路径、修改时间戳如何，得到的哈希一定相同。一个简单的去重流程：把目录树里的每个文件都算一个哈希，按哈希分组，同一组里有多个文件的就是重复的。Linux 上的 fdupes 这类工具就是用 MD5 在做这件事（这里用 MD5 完全可以接受，因为去重并不依赖密码学意义上的抗碰撞性）。
• 检测文件是否被改动过。今天给一个文件算个哈希存起来，过段时间再算一遍、做对比，只要哪怕一个比特不一样，文件就一定改过了。文件完整性监控工具（最早的 Tripwire，1992 年；现代的 OSSEC、Wazuh）、备份校验系统、以及 rsync 类的增量同步，都用的是这种方式。
• 内容寻址存储。Git 用每个 blob、tree、commit 各自的 SHA-1 哈希来标识它们（即将切到 SHA-256）。IPFS 用 multihash。Docker 镜像层是按内容哈希来寻址的。任何一个需要便宜又可靠地回答「这是不是同一份内容」的系统，底层用的都是内容哈希。
• 数字取证里的证据保管链。对取证镜像而言，业内的标准做法是在采集时就算一次磁盘镜像的 SHA-256，然后在之后的每一步都再算一次，任何一次对不上，都说明镜像被动过手脚。NIST 的 National Software Reference Library（NSRL）会公开发布「已知正常」和「已知有害」文件的哈希，供取证现场快速分流时使用。
• 软件供应链验证。Sigstore、in-toto、SLSA、npm 包完整性（package-lock.json 里的 integrity: sha512-...）、Go 的 module proxy 校验和数据库，它们底层全都靠文件哈希来作为完整性原语。一个发布出来的产物的哈希，正是「我相信这个签名」与「这就是签名所背书的那份产物」之间的桥梁。

本工具是怎么工作的

当你把一个文件拖到编辑器里，浏览器会用 FileReader.readAsArrayBuffer() 把它读进一个 ArrayBuffer（在现代浏览器里，更高效的做法是用返回 Promise 的 File.arrayBuffer()）。然后由 Web Crypto API 的 crypto.subtle.digest(algorithm, buffer) 用原生代码做哈希，浏览器引擎里 C++ 实现，常常还会用上硬件加速（自 Goldmont 起 x86-64 上的 Intel SHA Extensions、几乎每一部智能手机上的 ARMv8 SHA-2 指令）。返回的 ArrayBuffer 再被转成十六进制字符串显示出来。三种纯 JavaScript 实现的哈希（MD5 和 SHA-1，是在 Web Crypto API 拒绝处理或者用了 polyfill 的情况下走的路径）则由几小段专门的实现负责。没有任何上传步骤、没有任何服务端处理、没有任何遥测，你拖一个文件进去时打开 DevTools 的 Network 选项卡看一下（不会有任何请求被发出），或者在页面加载完之后让它离线（飞行模式），这个哈希工具仍然能在本地文件上正常工作。它的实际容量上限是浏览器的内存：哈希一个 1 GB 的文件可以，但操作期间会占用差不多 1 GB 的 RAM；好几 GB 的文件就可能让浏览器开始 swap、或者直接失败。对非常大的文件，专门的命令行工具更合适（macOS/Linux 上的 shasum -a 256、Windows 上的 certutil -hashfile ... SHA256）。

隐私：为什么对文件哈希来说「只在浏览器里跑」尤其重要

你想要做哈希的文件经常会包括：刚下载下来、还没建立信任的软件（你正是因为不信任它，才需要校验完整性）；你想留个哈希记录、又不想把内容交给任何人的私密文档；尚未发布的媒体文件；取证调查里的证据；以及哪怕只是上传给在线哈希服务都不能接受的专有构建产物。服务端的文件哈希工具，即使嘴上说「我们不会保留文件」，整份文件的内容也已经进了它们的内存（那一刻起，隐私保证就已经失效了。本工具完全在你的浏览器里、通过 Web Crypto API 运行；文件永远不会经过网络。你拖一个文件进来时打开 DevTools 的 Network 选项卡看一下（除了页面初次加载之外不应该有任何网络活动）。在页面加载完成之后让它离线（飞行模式））哈希工具照样能用，这就证明了它纯粹本地运行的架构。对于任何含有敏感内容的文件（机密文档、未发布的软件、财务记录、医疗扫描，或者任何受 NDA 或合规规定约束的内容）浏览器端做哈希就是唯一安全的选择。

常见问题

应该使用哪种哈希算法？

对 2026 年里的任何新用途，SHA-256 都是默认正确选择，兼容性广、没有已知的实用攻击、在所有现代 CPU 上都有硬件加速。如果你需要 512 位输出、可以用 SHA-512（在 64 位 CPU 上稍快一点，抗碰撞性的比特数也更多）。只有在你需要去对照某个用了那些老算法的已发布校验和时，才会用到 MD5 或 SHA-1（一些 Linux 发行版至今仍会和 SHA-256 一起再发一份 MD5 sum，是为了向后兼容），绝对不要把它们用于任何新的密码学用途。要做的就是：跟你正在校验的那个文件的发布方一致，发布方用什么算法，你就用什么算法。

可以反向破解哈希以恢复原文件吗？

不能。哈希函数被刻意设计成单向的（给你一个哈希，没有任何高效的算法能反推回输入。唯一可走的攻击路线就是暴力穷举：不停地哈希候选输入，直到某个的哈希正好对上。对于任何稍微像点样的文件（哪怕只是几个字节以上）来说，这在计算上根本不可行）光是 1 KB 的可能取值数，就已经远远超过可观测宇宙的原子总数许多倍了。正是因为有这种单向性，哈希才在密码存储（配合加盐和拉伸）、数字签名以及内容寻址存储里都很有用。

MD5 对文件验证安全吗？

如果只是用来抓非对抗性的完整性问题（不靠谱的网络、坏盘上的偶发损坏），MD5 够用，随机的比特翻转极大概率会算出一个不一样的 MD5。但要是用来对付对抗性情境（有人故意把文件换成另外一个），MD5 就已经被破了：碰撞攻击早在 2004 年就实用化，2008 年甚至有了选择前缀的碰撞。现代的安全实践是这样：只要场景里存在「有人可能想骗你」的可能，就一律用 SHA-256；只有当来源完全可信、你只是要一个快的校验和时，才用 MD5。

文件有大小限制吗？

没有硬性上限，实际上能做多大取决于浏览器的内存。几百 MB 以内的文件在任何现代设备上都能很快算完哈希。1-2 GB 的文件能算，但在做哈希的整个过程中会占用和文件大小差不多的 RAM。再往上、好几 GB 的文件，就有可能触发 swap，甚至让浏览器因为 OOM 直接崩掉。对于这种非常大的文件，命令行工具会更合适（macOS/Linux 上的 shasum -a 256 file、Windows 上的 certutil -hashfile file SHA256、PowerShell 里的 Get-FileHash），因为它们可以以流式的方式处理文件，不必把整份都装进内存。

如果两份文件的哈希相同，意味着什么？

对一个健康的哈希函数（SHA-256、SHA-512，或者 2026 年里 SHA-2 家族中的任何一种）来说，这意味着这两份文件按位完全相同，两份不同的文件碰巧得到同一个哈希的概率小到可以忽略。但对已经被破解的哈希函数（MD5、SHA-1）来说，那要么是两份相同的文件，要么是有人特意构造出来的碰撞。一个实用规则：如果用 SHA-256 算两个文件、得到了相同的值，那它们就是同一份文件；如果是用 MD5 得到了相同的值，那它们很可能是同一份，但不能排除有目的明确的对手特意把它们构造成会碰撞。

相关工具