哈希、ID与随机数
下载文件与发布方的哈希值一致吗？
使用工具
下载完成且文件名正确，仍可能拿错版本或遇到损坏。发布页上的长串十六进制字符就是核对线索：摘要根据内容的字节计算，而不是根据文件名或修改时间。但预期摘要来自哪里，与比较本身一样重要。
先用 abc 确认比较步骤
打开 SHA 哈希计算，输入小写 abc，不加末尾空格或换行，选择 SHA-256 和十六进制。结果应与下方 64 字符一致。每个十六进制字符表示四位，因此 256 位摘要总是 64 位十六进制数，与文件大小无关。
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad换成 SHA-512 会计算另一种摘要；只换 Base64 输出则是同一摘要字节的不同表示。核对时既要一致的算法，也要一致的表示格式，不能把 SHA-256 与 SHA-512 的差异当作下载失败。
看起来相同却不一致的原因
在 abc 后加一个 LF 换行，仅多一个字节也会得到外观完全不同的摘要。哈希处理的是字节，不理解文字含义。编辑器自动加末尾换行或复制时带入空格都会影响结果；不能依据摘要相似程度判断内容改动大小。
edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb编码也会影响结果：相同文字的 UTF-8 与 UTF-16 字节不同。本工具的文本输入按 UTF-8 计算，文件选择则使用原始文件字节。先转编码或改换行就不再是在核对原下载文件，应在打开并另存之前选择原文件。
核对下载文件的顺序
先在官方发布页确认版本、系统、CPU、文件名和摘要算法，再选择已保存文件计算，并核对完整摘要而非前几位。ZIP 与解压后的程序、不同平台、同名不同版本都有不同字节，必须明确公布值对应哪个文件。
不一致时先复核目标和算法，随后才考虑下载不完整或内容变化。摘要本身不能定位原因，不应通过运行文件来试验。超过工具限制时改用合适的本地工具，不要截取片段后当作原文件摘要。
一致不等于确认发布者
文件与摘要都来自同一可疑页面时，完全一致也不能确认发布者：修改内容的人也能重新计算摘要。核对的价值在于用可信渠道得到的预期值比较手中文件，与确认官方 HTTPS 网站或数字签名的作用不同。
一致也不意味着程序安全，正式版本仍可能有漏洞；不一致也不必然是攻击，版本或换行不同就会产生差异。把结果理解为内容核对，不要直接跳到安全判断或原因结论。
区分哈希、CRC 与加密
CRC32 可以检查数据变化，但不是为了抵抗攻击者蓄意修改。发布方给出 SHA-256 时不要换成 CRC32。摘要不是可还原的加密，直接使用 SHA-256 也不等于合理的密码存储设计，那与文件核对是不同问题。
要能复核，可记录文件名与版本、算法、预期值来源及比较结果，无需分享机密内容。计算在浏览器内进行，但共享设备与剪贴板仍需谨慎。有效的结论应包含比较对象、可信参考及采用算法。
用来比较的摘要来自哪里？
文件与同处下载的摘要一致，只证明字节对应那个值。若两者都被替换，一致不证明安全。比较运算与信任期望值是两回事；官方要求签名验证时，不能用哈希替代并称等效。工具不认证来源或签名者。
先统一算法和输出格式，同一 SHA-256 的十六进制与 Base64 文字不同。把文件粘入文本栏可能改变编码或换行，文件核对应使用原始文件输入。摘要与文件名等格式分开，比较完整值而非短前缀。
不一致可能是版本、下载不完整、压缩前后或换行变化，不自动证明攻击，也不能不明原因就当差不多继续使用。记录版本、文件名、字节数、算法和两个摘要。哈希发现差异，但不诊断原因。