文件已经打开，为什么仍不能证明是同一版本：跨设备交接的三层核对

同事把一份资料从电脑传到手机，聊天窗口里出现两个同名文件。两份文件都能打开，首页标题也一样，字节数看起来只差一点。此时最容易出现的误判是：既然应用没有报错，就把后收到的文件覆盖原件。真正的问题却不是‘能不能打开’，而是双方手里的副本是否包含相同字节、是否指向同一版本，以及用来核对的摘要值是否来自可信发布渠道。

文件能打开只说明应用能够解析当前格式。PDF阅读器可能忽略尾部附加数据，压缩包工具可能只在解压到某个条目时才发现损坏，网页缓存还可能把旧附件和新页面组合在一起。可靠交接因此需要三层核对：第一层确认字节有没有变化，第二层确认双方比较的是不是同一个对象，第三层确认摘要基准是谁发布、从哪里取得。缺少任意一层，都只能得到局部结论。

能打开为何只是最低门槛

‘成功打开’是应用层的格式判断，不是完整性证明。一个文件只要保留了足够的结构，阅读器就可能显示封面和部分页面；这不能排除下载中断、附件缺失、宏或脚本区域被改动，也不能说明另一台设备上的副本完全相同。文件名更弱，因为改名不改变内容，反过来，不同内容也可以使用相同名称。修改时间同样会被复制、重写或受到设备时钟影响。

NIST在2015年8月发布的FIPS PUB 180-4中说明，安全散列算法把消息处理成固定长度的消息摘要，摘要可用于检测消息自生成摘要后是否发生变化。标准还指出，消息发生任何变化时，极可能产生不同摘要。这提供了一个比文件名、图标和‘能打开’更精确的比较对象：不是比较界面，而是让两端针对同一串字节重新计算。

这项机制的因果关系很直接。输入字节先按算法规定分块并参与运算，最终得到固定长度摘要；接收端对自己的副本执行同一算法。如果发送端和接收端得到不同结果，至少有一项没有对齐：文件字节不同、算法不同、取值对象不同，或者抄录的摘要有误。差异能触发停止条件，却不能自动告诉你变化发生在哪一段，更不能自动恢复正确版本。

第一层：用摘要核对同一串字节

以SHA-256为例，实务上应把算法名称与摘要值一起记录。只写一串十六进制字符而不写算法，接收端无法知道该用什么方法复算；只截图摘要而不保留可复制文本，又容易引入抄录错误。最好同时记录文件字节数，但字节数只用于快速发现明显差异：两个文件大小相同，内容仍可能不同；大小不同则可以直接确认不是同一字节序列。

NIST说明安全散列算法通常会和数字签名或带密钥的消息认证码配合使用，并明确提醒，符合散列标准并不保证整个实现安全。这意味着‘计算出SHA-256’不是终点。它回答的是确定输入经过确定算法后得到什么结果，不负责回答谁发布了文件、发布者是否可信、文件是否适合当前系统，也不审查正文结论。

接收端应在文件完整落盘后再计算，而不是根据下载页面显示的进度推断。若文件从电脑转到手机再传给同事，每一位接收者都可以对最终落盘副本复算。中间转发工具是否改名、压缩或重新打包，也会在这一步暴露：如果工具只是搬运原文件，摘要应保持一致；如果工具重新生成了容器，即使可见内容相同，字节摘要也会改变。

这里有一个重要反例。两个PDF分别由不同软件‘另存为’，页面视觉完全相同，但元数据顺序、字体子集、对象编号或压缩方式可能不同。此时SHA-256不同，并不等于其中一份被恶意篡改，只能说明它们不是同一字节序列。若业务要求确认‘视觉内容是否等价’，还要使用适合该任务的内容比较；不能要求字节摘要替代所有比较方法。

第二层：先确定摘要覆盖什么对象

文件落盘后的SHA-256通常覆盖整个文件，但HTTP传输中的摘要可能覆盖不同对象。IETF在2024年2月发布的RFC 9530将Content-Digest定义为对实际HTTP消息内容计算的摘要，将Repr-Digest定义为对完整选定表示计算的摘要。名称相近，核对范围却不同。不了解这个区别时，很容易把两个合法但用途不同的结果当成冲突。

RFC 9530给出的范围请求示例尤其适合解释这种差异。服务器以206 Partial Content只返回资源的一部分时，Content-Digest可以针对本次收到的局部字节计算；Repr-Digest则可以针对完整选定表示计算。标准示例中，两者因此得到不同结果。这不是计算错误，而是输入对象不同。与之相对，在完整200响应且消息内容就是完整表示时，两种摘要可能相同。

所以，摘要比较之前至少要写清四件事：算法是什么、输入是完整文件还是局部片段、字节位于压缩前还是压缩后、摘要针对消息内容还是完整表示。如果一方拿本地完整PDF的SHA-256，另一方拿HTTP响应头里的Content-Digest，不能看到算法都写着sha-256就直接比较。算法相同只表示运算规则相同，不保证输入范围相同。

压缩也会改变比较条件。同一JSON内容使用不同压缩级别，线上字节可能不同；RFC 9530指出完整性字段与Content-Encoding和Content-Type有关，同一资源可能在不同HTTP传输形式下出现不同摘要。若工作目标是确认下载后的压缩文件是否逐字节一致，就比较压缩文件；若目标是确认解压后的资料集合是否一致，则应对约定后的文件清单逐一计算，不能混用两个层级。

这种对象区分还能解释‘网页已更新但附件没变’的情况。页面HTML、图片和PDF是三个独立资源，各有自己的URL、缓存与字节序列。验证HTML摘要不能证明PDF也更新，验证压缩包摘要也不能证明解压目录没有被后续程序修改。每个结论只能落在实际参与计算的对象上。

第三层：摘要基准必须有可信来源

即使双方已经对齐算法与输入对象，还要问摘要从哪里来。最危险的做法，是从同一份未知压缩包里读取一个sha256.txt，再用它核对旁边的文件。如果压缩包整体可以被替换，文件和摘要也可以一起被替换；二者相符只说明它们彼此配套，无法说明它们来自预期发布者。

RFC 9530明确说明，摘要字段不提供认证、授权或隐私，也不是对恶意篡改HTTP消息的通用防护。缺少额外机制时，路径上的恶意参与者可以删除原摘要，或替换内容后重新计算一个新摘要。规范建议结合TLS或数字签名等机制，以保护摘要或相关元数据。这里的关键不是多加一个安全名词，而是让基准与待核对文件拥有独立的信任路径。

例如，文件可以从团队存储下载，摘要值则从经过身份确认的发布记录取得；或者由发布者对摘要清单进行数字签名，接收端先验证签名，再比较文件摘要。若文件与摘要只能从同一个未经确认的聊天账号获得，结果最多能证明这位发送者提供的两项数据相互一致。它不能越过账号身份不明这个缺口。

TLS也要放回准确边界。HTTPS可以保护当前连接并帮助验证所连接的域名，但不能自动证明页面运营者就是你期望的文件作者，也不能审查文件内容。RFC 9530还提醒，HTTP消息常经过多条独立连接，传输层完整性通常只覆盖单条连接；HTTP摘要的价值之一，是让最终应用在跨越多个系统边界后验证收到的表示或内容。两者承担不同层次，不能互相替代。

因此，可信来源记录至少应包含发布者名称、来源页面、发布日期或版本号、算法和摘要值。如果来源页面后来更新，保留核对日期；如果只能拿到别人转发的截图，标明它是待确认线索，不把它升级为正式基准。来源无法确认时，正确动作不是继续寻找一个能让两串值相等的算法，而是暂停覆盖旧文件。

三个交接场景如何得出不同结论

第一个场景是电脑向手机直接传文件。双方约定对完整落盘文件计算SHA-256，手机复算结果与电脑记录一致。这个结果支持两端副本是同一字节序列。如果摘要记录由电脑端临时生成，却没有可核验的发布者来源，它仍不能证明电脑上的原件就是官方版本。此时第一层通过，第三层仍待确认。

第二个场景是从网页下载一个大文件，浏览器使用范围请求续传。HTTP响应可能分别携带局部内容摘要与完整表示摘要，本地工具又对合并后的完整文件计算SHA-256。三者可能都正确，却不能直接互比。应先确认每个值覆盖的对象，再选择与完整文件对应的基准。若某个分段失败，浏览器显示‘下载完成’也不能代替最终文件复算。

第三个场景是发布者重新导出PDF，页面内容没有明显变化，但文件摘要改变。若新摘要来自已确认的发布记录，发布日期和版本号也随之更新，这更像一次重新生成，而不是传输损坏。接收端应保留旧版与新版，记录它们各自摘要和适用日期，再决定是否替换。若版本说明没有变化，则需要向发布者确认，不应仅凭视觉相同把差异忽略。

这三个场景构成一个受控比较：第一项固定输入对象与算法，观察跨设备副本是否一致；第二项改变HTTP返回范围，说明Content-Digest与Repr-Digest为何不能混比；第三项保持可见内容近似，却改变生成过程，说明字节变化不必然等于恶意行为。比较条件写清后，摘要才从一串字符变成可解释证据。

建立可以复核的交接记录

交接前先给文件一个不会与旧版混淆的版本标识。版本标识可以是发布批次、日期加修订号或内部批准编号，但不要只把‘最终版’写进文件名。随后记录文件名、准确字节数、摘要算法、完整摘要值、摘要来源页面、发布者、发布日期与本次核对时间。若包含多个文件，按稳定顺序列出相对路径，避免只验证外层文件夹名称。

接收端不要先覆盖旧文件。把新副本保存到独立位置，确认下载或转发结束后重新计算摘要，再逐字符比较。结果一致时，只记录‘副本字节一致’；不要扩大成‘来源绝对可信’或‘内容一定正确’。结果不一致时，先核对算法和输入范围，再重新下载一次。第二次仍不一致，就保存两个结果、停止覆盖并回到发布记录确认。

若HTTP头提供Content-Digest或Repr-Digest，记录字段名称而不只摘录值。字段名称决定摘要的语义范围。遇到206响应、内容编码或分段重组时，同时记录状态码、Content-Range和Content-Encoding。普通读者不必手工理解每个协议细节，但至少要知道这些条件变化会改变摘要对象，不能把所有‘sha-256’都视为同一问题。

团队交接还应分开‘计算者’与‘确认者’。计算者负责从确定对象产生摘要，确认者负责核对来源、版本和接收结果。如果同一个未知账号同时提供文件、摘要和‘已验证’结论，记录里没有独立证据。相反，即使是熟悉同事发送，也应保留发布记录，因为账号被盗、错选附件和旧版误传都不需要恶意动机就会发生。

可以把停止条件写得很具体：算法不明时不比较；输入范围不明时不比较；摘要来源无法确认时不覆盖；复算不一致时不改名冒充新版本；只有截图没有可复制摘要时先要求原始记录。这些动作都由前面的机制推出，不是额外增加流程。它们把不确定性保留下来，避免一次方便的覆盖操作消灭了可追踪证据。

先收窄能够下的结论

三层核对能够回答三个有限问题：接收副本是否与基准保持相同字节，双方比较的是否是同一种表示或内容，以及摘要基准是否来自可以说明身份的渠道。它不能替代恶意软件扫描、数字签名验证、账号授权、文件格式安全检查，也不能判断正文事实是否正确。SHA-256一致不能单独证明发布者身份、文件用途、正文事实正确或文件没有恶意行为。

反过来，摘要不同也不是自动定罪。压缩参数、局部范围、元数据和重新导出都可能改变字节。最稳妥的结论不是‘相同就安全、不同就危险’，而是把差异放回对象、算法、来源与版本记录中解释。交接前记录文件名、字节数、算法、摘要、来源页面与发布日期；接收端重新计算，无法对齐时停止覆盖现有文件。这样保住的不是一串哈希值，而是一条以后仍能复查的资料链。

算法选择也属于交接条件

摘要值只有连同算法才有意义，算法本身也会随安全认识变化。RFC 9530把可用于HTTP摘要字段的算法分为Active、Provisional与Deprecated等状态，并建议一般应用选择Active算法。已知较弱的算法或许还能发现偶发损坏，却不应在可能存在对手的场景中承担真实性保护。团队不能因为旧工具只输出较短摘要，就把‘总比没有好’写成长期规则。

迁移算法时，发送端可以同时提供多个摘要，让接收端选择双方支持的较强算法；但接收端若仍接受最弱选项，整体判断就可能被最弱算法限制。记录中因此要写下实际采用的算法，而不是笼统标注‘哈希已核对’。旧批次若只有历史算法，保留原记录并标明用途；新批次使用当前约定算法重新生成，不能偷偷改写旧记录后假装两批资料从未变化。

算法协商也不是身份认证。RFC 9530指出，完整性字段本身不能阻止算法降级或替换；需要限制可接受算法，并结合TLS或数字签名保护字段。对普通交接而言，可执行的边界是：事先约定算法清单，发现对方只提供未约定或已弃用算法时先停止，不用一次碰巧相等的结果换取继续覆盖。

资料来源

• National Institute of Standards and Technology：《FIPS PUB 180-4 — Secure Hash Standard (SHS)》，发布或更新于 2015-08-01
• Internet Engineering Task Force：《RFC 9530 — Digest Fields》，发布或更新于 2024-02-01