下载页面给出一串 SHA-256 值时，可以用 文件哈希计算 对照自己的文件是否具有相同摘要。这适合检查下载中断、传输错误，以及文件是否与可信来源公布的版本一致。
哈希不能单独证明软件安全或发布者身份。 如果文件和“正确哈希”都来自同一个不可信位置，两者一致也不足以建立信任。先确认来源，再进行比对。
第一步：准备可以复现的三字节文件
练习文件的内容必须是 abc，使用 UTF-8，不含 BOM，也没有结尾换行。文件大小应为 3 字节。
在 Windows PowerShell 中，可以在测试目录创建它：
[System.IO.File]::WriteAllBytes('abc.txt', [byte[]](97, 98, 99))这条命令在当前目录写入 abc.txt，会覆盖同名文件；请使用专门的测试目录。用普通编辑器保存时，自动添加的换行或 BOM 会改变摘要，不能仅凭看起来都是“abc”判断文件相同。
第二步：选择 SHA-256 并计算
- 打开 文件哈希计算，选择
abc.txt。 - 在“算法”中选择
SHA-256；选文件或更换算法后，工具会自动计算。 - 查看“结果”，确认得到 64 位十六进制字符串。
- 与下面的预期值逐字符比较。
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad文件摘要按原始字节计算，不是按文件名或图片预览计算。同样的算法和字节应得到同样的摘要；SHA-256 与 SHA-512 的结果不能直接互比。算法接口与输出含义可参阅 MDN digest 文档。
第三步：把样例换成实际下载文件
从发布者官方网站或其他可信发布渠道找到同版本、同系统、同架构的校验值，确认它标注的是 SHA-256，再计算下载文件的 SHA-256。
比对时可以忽略十六进制字母大小写，以及复制时带入的首尾空白，但不能忽略中间字符或截断后只比较前几位。如果公布信息含有文件名，复制其中的摘要部分，不要把文件名当作哈希的一部分。
例如 Windows 安装包、macOS 安装包和源码 ZIP，即便来自同一个版本，摘要也通常不同。要比对的是你实际下载的那个文件。
不一致时，按这个顺序排查
| 排查点 | 要核对的内容 |
|---|---|
| 算法 | 两边是否都是 SHA-256 |
| 发布版本 | 是否下载了相同版本、平台与架构 |
| 文件状态 | 是否下载完成、是否误选旧文件 |
| 校验值来源 | 是否来自可信且对应当前版本的页面 |
| 字节变化 | 是否经过解压、重新压缩、另存或编辑 |
校验 ZIP 时选原始 ZIP，不能把解压后的某个文件拿来比较 ZIP 的摘要。校验值不一致时先停下使用文件，重新确认来源和下载；不要只改文件名再试，因为改名本身不会修复字节差异。
文件哈希与文本哈希有什么区别？
文本哈希生成 对你输入的文本编码后计算摘要，而文件哈希读取文件原始字节。二者只有在输入字节确实一致时才会相同。编辑器换行、编码、BOM 和不可见字符都是常见差异来源。
文件哈希当前支持 SHA-1、SHA-256、SHA-384 和 SHA-512，一次最多选择 50 个文件，单个文件上限为 50 MB。工具逐个计算并按文件名展示结果，可单独复制哈希，也可复制包含文件名、算法和哈希的全部结果。选择接收方要求的算法；用于新的文件完整性练习时，本文使用 SHA-256，不用摘要充当密码存储或数字签名。
最后保存什么证据？
记录文件来源、版本、文件名、字节大小、算法、可信预期值以及计算结果。这样再次下载或交接时，可以说明比较的是哪个文件。
如果你需要确认文档是否经过特定人签署，要查看对应签名机制和验证结果；对 PDF 算一个哈希不能替代证书签名验证。需要处理 PDF 的文件结构，可参考 PDF 工作流程指南。