哈希、ID与随机数
CRC 一致就安全吗？
使用工具
文件旁八位十六进制与本地计算一致，容易让人以为安全，但 CRC32 不证明作者或无害。它有助排查误配和损坏。先用已知短输入核对算法，再明确比较能证明什么。
用 123456789 核对 CRC 变体
123456789
CRC-32/ISO-HDLC: cbf43926仅输入九个字符 123456789，不加示例标签或换行，CRC-32/ISO-HDLC 得 cbf43926。其他 CRC32 变体对同字节可能不同，不能只凭 CRC32 名称统一参数。
八位十六进制表示三十二位。保留前导零便于比较。字母大小写不改数值，但缺位或算法不同不能当作大小写差异。
比较字节而非文字外观
123456789 后加 LF 就是另一字节串，CRLF 又不同。文本按 UTF-8 编码，文件则使用实际字节。编码、BOM、末尾换行可改变外观相同的文档，应先查来源、长度和字节约定。
删换行后匹配，不证明原文件正确。发布文件的字节检查不同于文字含义比较。应对原始制品字节计算，不能为匹配而随意规范化。
不同文件也可能具有相同 CRC
CRC32 只有 2³² 种输出，文件可能性更多，碰撞不可避免。它不是抵御故意篡改的密码学认证，匹配不能扩展为输入绝对相同或无恶意改变的证明。
同算法同对象前提下，不一致说明存在差异，但不指出位置、原因或谁正确。应查版本、转换、误取文件。校验值是排查入口，不是修复数据。
确认来源还要看参考值从何取得
即便 SHA-256，预期摘要也需可信来源。攻击者同时替换文件和参考值时，匹配不认证发布者。签名制品需适当密钥和流程验证，CRC32 或单纯 SHA 计算不会替代。
CRC32 与 SHA 都不加密文件，没有逆转换按钮不等于保密。不要把 CRC32 用于密码存储或授权。校验和、哈希、签名即便外观相似也职责不同。
记录结果时附对象与算法
除文件名，还记版本、字节数、CRC 变体、预期值来源和结果。“该版本制品的 CRC-32/ISO-HDLC 与发布记录一致”比“安全”更准确且可复现。