同事说配置文本没有改，校验值却不一样，先别急着认定文件被恶意修改。末尾多一个换行、复制时夹入空格，都会改变实际输入。XunL SHA-256与SHA-512文本哈希把输入文本按UTF-8计算摘要，适合比较相同规则下的内容；它并不会判断哪一份资料才是正确版本。
先用一个已知摘要核对输入方法
输入三个小写字符abc，选择SHA-256，不增加空格或换行，可以用以下公开测试结果核对操作：
ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad这是对固定教学文本的独立计算值，不包含任何业务凭证。若结果不同，先检查是否输入成ABC、是否有末尾空格，以及当前选择的算法。不要把输出改成示例值，而应定位造成输入差异的原因。
SHA-256输出256位摘要，常用十六进制表示为64个字符；SHA-512则是512位，常见表示为128个十六进制字符。摘要算法的定义可查阅NIST安全哈希标准。比较前必须统一算法，不能把不同长度的结果直接放到一起判断是否相同。
把“看起来一样”拆成可以复查的输入条件
- 复制待核对的纯文本，确认不是带格式的截图或另一个文件的文件名。
- 明确采用UTF-8文本与同一种摘要算法，保留原始输入。
- 计算并复制完整摘要，再对第二份文本采用相同步骤。
- 若摘要不同，使用文本对比工具查具体改动，特别检查行尾、空白与字符大小写。
注意文本摘要与原始文件字节校验不是同一任务。将一个文件打开、复制其中的文字，再粘贴到网页，可能已经发生换行或字符处理。如果交付要求核对下载文件本身，应使用针对原始文件字节的校验方法，而不是把文件内容经过编辑器转了一圈。
哈希能帮助比较，但不会替你确认来源
假设两人核对产品说明，一方使用Windows换行，另一方使用另一种行尾表达，即使阅读时分段相同，实际字节也可能不同。这里应先决定业务要求是“文字意思一致”还是“字节完全一致”。前者需要内容审阅，后者才适合在明确编码规则后逐字节核对。
摘要相同是检查一致性的有用信号，但不能单独证明发布者身份。如果有人同时替换了下载文件和同一页面上的校验值，仅比较两者也不能建立可信来源。应从可信渠道取得预期摘要，或按实际流程使用签名等机制；不要把一串长数字当作天然的真实性证明。
哈希也不是可以输入摘要再“解密”还原原文的工具。对短小、常见的候选文本，人们仍可以逐个计算后比对，因此直接计算一次SHA摘要并不能解决密码存储问题。需要账户认证时，应采用相应系统的专用安全设计，不能把这个文本小工具当作完整认证方案。
保存检查记录时，建议同时记下文本版本、字符处理方式与算法，而不只留下摘要。以后出现差异，才能判断是在发布、复制还是编码环节发生变化。若已经确认内容需要修改，应重新生成摘要并连同新版本一起交付，避免旧校验值继续流传。
文本哈希常见问题
为什么只修改一个标点，整个结果都变了？
摘要用于反映完整输入，并不是按字符位置拼接的编码。改动一个字节就可能让输出大量变化。它适合判断是否一致，却不能从不同的摘要中告诉你具体改了哪一行；定位仍需要文本对比。
浏览器提示无法计算，要把敏感内容换个网站再试吗？
先确认使用HTTPS和支持相关浏览器能力的现代环境。排查可以用abc这样公开的教学文本完成，不需要反复搬运敏感内容。实际工作还应遵守自己组织的数据处理与工具使用规则。
个人微信：ssevening
