分享一个用 WebAssembly 实现的超快在线文件 hash 校验工具

[jethroX]

吃过下载的 win10 镜像损坏的亏，从此以后下载大文件必校验，因为用得少，每次都得重新搜命令，搜索到的在线校验网站处理这种大文件慢的要死，所以自己用 rust 编译了一个 wasm 来处理大文件，速度一下子就起来了。

校验 win11 镜像跟命令行的速度差不多，支持 MD5 、SHA256 、SHA1 、SHA512 计算。

网站地址：https://hash.jethro.fun/

服务器和域名长期有效，欢迎保存为书签。

[menglizhi2333]

好工具, 收藏了

[lstz]

感谢分享，想请问这个会吃内存吗？刚刚试了一下好像页面卡住了

[jethroX]

@lstz 应该不会很吃内存，他是流式处理的，将文件一块一块的读取到内存里计算，一块 50M 大小。可能稍微大了点，你是用的什么设备？

[lstz]

@jethroX 那可能是我的备用机性能太古董了，感谢大佬

[jethroX]

@lstz 嘿嘿，我写的时候确实没考虑兼容问题，因为用到了 WebWorkers 和 WebAssembly ，所以需要新一点的浏览器内核。

[cat]

@jethroX 话说，分块读入，那怎么 hash 整个文件呢（真不懂

[Yanlongli]

不错，收藏了

[jethroX]

@cat 这些散列算法本身就是一块一块的算的，只是应用层面看起来是一起计算的整个文件。

[cat]

@jethroX 原来是这样，感谢

[mxT52CRuqR6o5]

用 web crypto api 应该比 wasm 快吧（不过算不了 md5 ）

[jethroX]

@mxT52CRuqR6o5 速度上和 wasm 比不会像和 js 比那么大差异，而且看了下接口，没看到流式处理的 api ，总不能把十多个 G 的文件直接读进内存丢过去计算吧。

[mxT52CRuqR6o5]

@jethroX #11 js 慢主要是大多数的 js 库写的太烂了，我试了一个 600M 的文件算 md5 ，web crypto api 用 600ms ，你这个 wasm 用 2600ms ，fast-sha256 用 3200ms

[mxT52CRuqR6o5]

@mxT52CRuqR6o5 #12 打错了，是算 sha256 不是算 md5

[mxT52CRuqR6o5]

我试了下 nodejs 的 crypto 的 polyfill ，性能好像也不错
我记得好像说是 wasm 的 jit 和 js 的 jit 是一个引擎，理论上花时间去优化 js 能和 wasm 差不多性能（不考虑一些 wasm 特殊指令的话）

[jethroX]

@mxT52CRuqR6o5 我不认为能优化到 wasm 这种程度，就拿计算斐波那契数列来说，这么简单的计算函数，js 和 wasm 的 jit 是一个引擎，那他们速度应该接近吧，可实际计算出来还是有几倍的差距。而且 web crypto api 的实现一定不是用 js 写的。

[mxT52CRuqR6o5]

@jethroX #15 jit 是一个引擎这件事我也是听说的，斐波那契数列这个性能差距有 benchmark 可以看看吗？
web crypto api 肯定不是 js 写的，可以认为性能等同于 native

[jethroX]

@mxT52CRuqR6o5 web crypto api 计算 sha256 确实快得有些离谱了。。。

[jethroX]

@mxT52CRuqR6o5 我没去找 benchmark ，我是在一个知乎帖子上看到的，见 https://zhuanlan.zhihu.com/p/664350420

[jethroX]

@mxT52CRuqR6o5 如果 web crypto api 能够支持分块计算的话，我就把 sha 部分的实现换成他了。有分块就可以展示进度，当长时间计算一个大文件没有进度的时候，心里会有点担心这玩意儿是不是卡死了，什么时候才能算出来啊。

[mxT52CRuqR6o5]

@jethroX #18 我感觉他这个 case 循环次数太少了，都不一定能测出 jit 的实际性能，应该算一个大点的菲波那切数循环个几百几千次

[jethroX]

@mxT52CRuqR6o5 确实，循环次数够大才能触发编译。有时间写个大点，还能水一篇博客，哈哈。

[vvhy]

powershell Get-FileHash 挺好用