1. 文件名相同与内容相同是两回事
下载的安装文件若在名称与大小上都符合说明页面，很容易让人以为已正确取得文件。然而，名称可以更改，大小相同的文件也可能有不同内容。反过来说，把照片文件复制成另一个名称，并不表示文件内的字节一定会改变。这时，把文件内容送入固定计算过程并以短数值表示的哈希，就能协助比较。我们要确认的问题不是文件名看起来是否可信，而是收到的字节是否与可信的基准一致。将备份文件移到另一个存储设备时，也可以提出同样的问题。
SHA-256 是一种从输入生成 256 位哈希值的算法。通常用 64 位十六进制数表示，因为一位十六进制数代表 4 个二进制位。即使文件变大，结果长度也不会随文件大小等比例增加。对相同字节应用相同算法，就会得到相同结果。不过，由于必须把所有输入映射到长度有限的数值，原理上仍存在不同输入得到相同数值的碰撞。应区分“可用于实际比较”与“在数学上为所有文件赋予独一无二名称”这两种说法。RFC 6234 提供了包括 SHA-256 在内的哈希计算与测试资料。
2. 哈希不是加密，也不是文件的缩小副本
知道哈希值，不代表就有了解码按钮，可以还原原本的文档或照片。加密的设计是让人能用适当的密钥取回原文，但密码学哈希并不是用于还原原文的存储格式。这也不表示只公开哈希，就能保护所有输入的秘密。若可能的输入只有几个，便可以逐一计算哈希后比较。因此，不能把用于文件验证的 SHA-256 说明，延伸成“直接把密码做哈希后存储就已足够”的建议。确认完整性、保密与存储密码，是条件要求各不相同的工作。
若计算整个文件，所比较的也不只是屏幕上看得见的文字。即使看起来是同一句话，换行方式、字符编码或文档内部元数据不同，都可能使字节不同。解压后得到的文件，与原本的压缩文件是不同的比较对象。若先将文字规范化或改变换行再计算，得到的就是转换后资料的哈希。若发布者提供的是原始压缩文件的数值，应先拿收到的压缩文件本身来比较。这一区分，是把既有 Unicode 与 UTF-8 文章中“显示内容与字节不同”的观念，应用于实际文件验证的例子。
3. 下载文件应以相同算法与基准值比较
验证前，先在制作者的官方发布说明中，一并确认目标版本、操作系统、文件名与哈希算法。其他操作系统的安装文件或不同版本的数值，不能作为比较基准。在 PowerShell 中，可用 Get-FileHash -LiteralPath '.\download.zip' -Algorithm SHA256 读取本地文件并计算。这个命令不会执行该路径的文件内容。Microsoft 官方文档说明，数值是根据文件内容计算，仅更改名称不会改变数值。请把文件名与路径改成实际取得的文件，计算期间也不要修改文件。
在输出中，将 Hash 字段的完整 64 位数，与发布者公开的 SHA-256 值逐一核对。不能只因开头或结尾几位相同，就认定整个数值一致。十六进制英文字母的大小写代表同一个数，但若混入其他字符或位数不足，应先检查复制的值。结果匹配，可支持收到的字节与所信任基准值的一致性；这并不是已检查文档事实、程序质量或恶意行为的结果。若基准文件本身有问题，与它完全相同的副本也会具有相同哈希。计算成功与文件是否适合使用，必须分开判断。
4. 不匹配是调查原因的信号，并非攻击的确证
例如，假设将昨天取得的发布文件，与今天说明中的数值比较，发现两者不同。这是说明用案例，并非真实事故记录。首先要确认说明是否指向同一版本、是否取得其他设备的文件，以及是否在下载完成前就开始计算。也可能是计算了解压后的文件，而不是压缩文件，或编辑器重新保存了文档。因此，必须区分比较对象改变，与传输或存储过程中内容改变的情况。仅凭数值不同，无法得知是谁、何时、改了什么。
不要为了确认而立刻执行哈希不匹配的安装文件；应重新确认官方发布说明与基准值，再比较重新下载的文件。若仍不同，宜查阅发布者的更正公告或支持渠道，并留下结果。记录中应一并写下确认时间、来源网址、文件版本、算法与计算值。重复计算结果相同，可作为以相同方式读取当前本地文件的线索，但这并不会解决发布者所刊数值有误或发布途径有问题的情况。若用预期值覆盖基准记录，就会失去判断日后是否发生更改的依据。
5. 信任基准值的依据与数字签名的作用
若攻击者能同时更改文件与说明中的哈希值，就能计算被修改文件的哈希，并把它列为新的基准。NIST SP 800-175B 说明了不使用密钥或签名、仅使用哈希时的这一限制。从官方网址的 HTTPS 页面取得数值，有助于确认来源与传输途径，但并不能保证连发布服务器本身遭入侵的情况也已排除。重点不是哈希字符串看起来很长，而是基准值从何处、通过什么信任程序取得。同一屏幕复制的两个数值匹配，并不足以确认制作者的身份。
数字签名让人利用以可信方式取得的公钥等，验证签名与资料之间的关系。若发布者提供签名验证程序，应依官方说明操作，包括如何确认密钥持有人与指纹。若直接信任来路不明文件旁第一次看到的公钥，信任起点的问题仍未解决。使用共享秘密密钥的 HMAC 也是不同于一般哈希的认证工具，但不是任意附加到所有下载项目，就能解决问题的功能。即使签名有效，也不能推论程序没有缺陷，或文档内容一定属实。字节一致、来源确认与内容评估彼此相关，但各自仍需要可验证的依据。
6. 备份与协作也应记录比较范围
备份个人照片时，保存原始文件的 SHA-256 并与副本比较，有助于确认移动过程中是否发生更改。这时，也要妥善保管基准清单，避免与原始文件一起丢失或被覆盖。若照片管理软件重新写入旋转信息或拍摄元数据，即使看到的照片相似，文件哈希仍可能不同。因此，应先区分目的是逐字节保存，还是确认编辑后照片的意义是否相同。若要确认整个文件夹，不能只算一个文件的哈希就结束，而应一起管理纳入的文件清单、相对路径与各文件的数值。
在协作文档审阅中，哈希也可以作为固定已审阅版本的标记。然而，检查哈希匹配，不能取代某人确实读过全文或对照过翻译的证据。先记录审阅了什么、何时审阅、采取什么方法，再把记录关联到相应文件的数值，才有意义。本文的图片是自行制作的说明示意图，整理字节比较、基准值来源与验证范围，并非实际测量结果或证书。确认文件时，请依次记录对象与算法、基准来源，以及结果能支持的说法范围。如此便能避免夸大匹配或不匹配的意义，也让下一个人重现相同步骤。