WhatsApp 聊天记录备份到电脑后，如何检查消息、附件与归档完整性？

把聊天记录保存到电脑后，常见的困惑是：消息能看见，附件却打不开；总数看起来不少，某个日期之前的内容又找不到。这些现象涉及不同的数据层，单看“备份完成”或一个文件大小，很难判断问题出在哪里。

本文以 WABak 中已经保存的本地记录为操作示例，重点讨论如何检查资料是否可用。后文的目录与脚本是通用的归档示例，不是软件的内部存储格式，也不访问真实客户数据。

一、先确定范围，再判断是否完整

“完整”需要有明确的参照物。先记录所属账号、目标对话、期望日期范围，以及两三条内容已知的消息。例如，示例项目 DEMO-0920 包含一段规格确认、一张图片和一份文档，可以把这三个对象作为检查样本。

首次连接时能够同步的历史，与账号全部历史并不一定一致；连接后新增的消息，也只会在相应同步条件满足时进入记录。因此要分别检查旧历史和新增消息，不能因为最新一条已出现，就推断几年前的内容也已经保存。

范围记录可以写在普通文本中，至少包括账号标识、目标日期、实际检查到的最早及最近时间、尚未确认的区间。这里记录的是可核实的覆盖范围，不能用文件生成时间代替聊天发生时间。

二、消息、媒体与历史同步分别检查

如果正在建立备份，先确认客户端运行、目标账号连接正常，并检查自动备份、媒体备份和历史同步设置。自动保存文字，不意味着每个媒体文件都已成功保存；历史同步开关开启，也不代表能取得所有不可访问的旧消息。

如果曾经关闭备份或出现连接中断，应把对应时段列为待复核区间。恢复连接后再检查缺口，避免把“重新开始同步”理解成“所有缺失内容已经补齐”。

三、用代表性对话检查上下文

在本地记录中找到样本对话，先核对账号和对方号码，再检查日期与收发方向。显示名称可能变化，也可能重复，因此不要只凭昵称确认对象。需要搜索或导出时，应具备客户端相应功能权限。

以规格修改为例，至少应看到原始要求、修改意见和最后确认。如果只找到中间一条消息，即使文字没有乱码，也不足以说明这件事的资料已经齐全。附件则应实际打开：图片看关键细节，文档看内容，音视频检查能否播放。

还应选择一段跨日对话和一种较少使用的文件类型作为补充样本。只有最近的几条纯文字正常，并不能代表复杂记录都正常。抽查能够发现常见问题，但不能替代逐条比对；没有完整来源清单时，也不能据此给出百分之百完整的结论。

四、保留导出文件之间的目录关系

HTML 适合阅读连续对话，Excel 适合整理字段。选择导出范围后，如果需要附件，应明确包含媒体，再完整解压输出。下面是一种便于说明的目录结构，实际文件名以导出结果为准：

chat-archive/
notes.txt
conversation.html
records.xlsx
media/
image-001.jpg
document-001.pdf

例如页面使用 media/image-001.jpg 引用图片，浏览器会从页面所在目录寻找这个路径。只复制 conversation.html，或者把媒体文件夹改名，都可能导致图片无法显示。遇到这种情况，先检查目录关系，不要立刻认定原图已经丢失。

归档时保留一份原始导出包，在另一个副本上整理和备注。需要重命名时，可以改外层文件夹名，尽量保留包内结构。附带说明应写清导出时间、内容范围和未确认项，让后续使用者能够理解这份资料的边界。

五、用只读脚本检查复制是否改变文件

文件名、大小相同，并不足以证明内容一致。复制前后可以按相对路径比较 SHA-256 摘要。以下示例用于 Windows PowerShell 5.1 或 PowerShell 7，读取当前目录下的 chat-archive，只向终端输出清单，不修改文件：

Import-Module Microsoft.PowerShell.Utility –ErrorAction Stop
$archiveRoot = (Resolve-Path –LiteralPath '.\\chat-archive' –ErrorAction Stop).Path
$manifest = @(
Get-ChildItem –LiteralPath $archiveRoot –File –Recurse –Force –ErrorAction Stop |
Sort-Object FullName |
ForEach-Object {
[pscustomobject]@{
RelativePath = $_.FullName.Substring($archiveRoot.Length).TrimStart([char[]]'\\/')
Bytes = $_.Length
SHA256 = (Get-FileHash –LiteralPath $_.FullName –Algorithm SHA256 –ErrorAction Stop).Hash
}
}
)
ConvertTo-Json –InputObject $manifest –Depth 3

分别对复制前后的目录运行，检查相对路径集合、文件大小及摘要是否一致。缺少一个路径属于缺文件；相同路径的摘要不同，则需要确认文件是否发生修改。计算期间应避免继续往目录写入数据，否则两次结果可能不对应同一状态。

这项检查针对的是文件复制一致性。摘要一致不能证明聊天来源真实，也不能证明历史消息全部齐全；如果首次导出就漏了附件，复制后的文件仍可能全部匹配。命令行为可参阅 Microsoft 的 Get-FileHash 文档。

六、几类异常的排查顺序

旧消息缺失： 先检查账号、日期条件和可访问历史范围，再核对是否有停止同步的区间。不要只按消息总数判断。

附件打不开： 先看实际文件是否存在、是否为零字节，再检查相对路径、格式和打开它的应用。已有记录里只剩文件名时，还需确认备份阶段是否取得了完整内容。

导出后文字乱码： 先用支持对应格式的应用打开，检查文本文件的编码。不要在唯一一份原始文件上直接批量替换字符。

换一台电脑就无法阅读： 检查是否复制了完整目录，是否仍依赖远程资源或某个客户端。一个本地文件存在，并不等于它已经具备独立阅读条件。

交接前还可以做一次简短核对：目标账号与日期范围是否写清，未确认的区间是否标注，附件是否实际打开，原始导出包是否保留。聊天正文和附件都可能含有联系方式或业务资料，工作副本也应限制访问，避免放进公开共享目录。分享排查截图时，先遮盖号码、姓名和具体内容；脚本输出的文件名与命中行，同样不应直接发布到公开论坛。

总结

聊天归档可以按“范围可说明、消息可阅读、附件可打开、复制可核验”四个层次检查。先选已知样本确认内容，再保留文件间的引用关系，最后验证复制前后的清单。这样的记录才能在后续查阅和交接时提供可靠的依据。