在一个网页被捕获十年后打开它，页眉仍会完整显现，下方的文章却只剩一片空白。HTML 已经抵达，原本负责获取正文的脚本却没有成功运行。截图能够留下眼前可见的文字，却会失去链接、菜单和搜索功能。由“网页，全部”生成的文件夹有时只保存了一个像样的外壳，却没有说明这个外壳由哪些远程响应拼合而成。

Web 归档之所以困难，在于现代网页更接近一场短暂的演出，而不像一份静止的文档。浏览器先请求 HTML 外壳，再执行代码、处理同意选项、调用 API、按视口选择图片、响应滚动，有些内容还要等到用户点击才会出现。要保存这场演出，需要多个职责各异的开源层协同工作：Browsertrix Crawler 或 ArchiveWeb.page 操作实时网站；WARC 记录网络交换；WACZ 将记录连同索引和页面元数据封装起来；ReplayWeb.page 再把封装还原为可浏览的体验。

这些层相互契合时，整套系统便能运转；契合只说明各层遵守了约定，距离事实全貌仍有一层。流畅无瑕的重放也会忠实再现一次不完整的抓取。有效的摘要值可以证明封装没有发生变化，却无法证明实时服务器曾经发送过所声称的字节。体量庞大的 WARC 可以装下数千条响应，偏偏缺少那个赋予页面意义的 API 调用。因此，梳理这一生态时，更有用的尺度是每一层掌握什么证据，以及哪些问题超出了它的回答范围。

图片背景：Jason Scott 于 2013 年拍下旧金山的 Internet Archive 存储机架。这些机器无法证明某个具体页面是否得到了妥善捕获。它们代表另一层耐久性工作：选取、捕获、封装和重放完成各自任务之后，持久保存才从这里开始。[8]

五份契约，共同完成一次保存

这种分工在实际运行中很重要。保存团队可以更换爬虫，同时继续以 WARC 作为证据界线；也可以更换查看器，同时继续以 WACZ 作为交付界线。面对空白页面时，团队也能沿层排查，而不把整个归档笼统地称为“损坏”。缺失资源分属几种情况：从未被请求、没有进入封装索引，或已经存在却在重放时受到了错误处理。

捕获是一项由浏览器执行的编辑工作

Browsertrix Crawler 在 Puppeteer 控制下运行真实的 Brave 浏览器，并通过 Chrome DevTools Protocol 记录流量。它可以启动多个浏览器窗口、接受 YAML 配置、从种子列表开始抓取、对每个种子应用范围规则、拦截指定 URL、复用浏览器配置文件，还能执行自动滚动或站点专用交互等行为。抓取过程可以实时查看，这一点很实用，因为一个看似忙碌的爬虫会困在日历、分面搜索或其他能够持续生成近乎无穷 URL 的空间里。[1]

这些能力把策展判断写进了配置。全域范围容易跟进过多内容；前缀范围会漏掉 JavaScript 路由，因为相关 API 位于另一台主机。自动滚动能够唤醒无限信息流，却仍会错过“加载更多”控件。四个并行浏览器窗口可以缩短任务时间，同时也会改变限流压力，或者改变网站生成个性化内容的先后顺序。因此，配置本身也应纳入归档记录，与其他证据一同保留。

另一条捕获路线来自 ArchiveWeb.page，与自动抓取互为补充。操作者可以使用其浏览器扩展和 Electron 应用，一边浏览网站，一边交互式记录。应用通过 Chrome 调试协议工作，将捕获内容保存在本地 IndexedDB 中，并能导出便携式 Web 归档。[2] 对于范围有限的体验，这种方式往往更清楚：例如拥有多条非线性路线的展览、收藏者获准保存的已认证页面，或者需要特定手势才能出现的状态。操作者可以亲眼确认轮播是否前进、地图标签是否出现。

代价体现在覆盖范围上。交互式捕获保留操作者实际走过的路径，未走的路径则留在记录之外。自动抓取可以重复运行，覆盖面也更广；某个状态有多少文化价值或证据价值，仍取决于人的判断。一套成熟的馆藏可以同时采用两者：用定期 Browsertrix 任务覆盖稳定外围，再用 ArchiveWeb.page 定向会话处理需要观察和明确意图的交互。

凭据让这条界线更加鲜明。保存下来的浏览器配置文件能够捕获已认证页面，cookie、标头、浏览器存储和个性化响应也会把秘密或个人数据带入归档。专用捕获账户、最小权限、明确授权、限制原始归档的访问权限，以及发布前的审查环节，都属于基本要求。爬虫可以记录浏览器所见；机构有权保留或披露哪些内容，则需要另行作出决定。

WARC 以网络交换为记录单位

WARC 1.1 格式由一系列带类型的记录组成。request 记录可以保存 HTTP 请求，response 记录保存返回的消息，metadata 记录保存背景信息，revisit 记录则保存一次重复检测事件，并回指此前存储的 payload。WARC-Date、WARC-Type 和 WARC-Record-ID 等必填字段用于标识事件与记录；目标 URI 和并发记录链接则把相关证据连接起来。区块摘要与 payload 摘要可以让后续的字节级变化显现出来。[3]

这一模型有意停留在比“页面”更底层的位置。假设一条 HTML 响应加载 app.js，脚本向 API 请求 story.json，返回的故事引用一张响应式图片，用户点击后又发出评论请求。每笔事务都可以成为一条独立的 WARC 记录。捕获浏览器若从未点击评论控件，记录中便不会出现评论请求。API 若返回一次临时错误，WARC 也会如实保存这次错误。同一张图片若已被存储，revisit 记录可以免去再次写入完整 payload，同时留下后来再次观察到它的证据。[3]

这正是该格式的长处：它保留带有来源线索的协议材料，避免把所有内容压平为一张渲染位图。也正因如此，WARC 文件大小并非理想的质量指标。更多字节既会来自更深的覆盖，也会来自重复噪声、超大媒体文件或爬虫陷阱。真正有意义的问题在于：所需状态是否得到操作，其依赖是否被捕获，另一台浏览器能否从这组记录中解析出这些依赖。

现代 JavaScript 让最后一个问题始终悬而未决。OSDI 2022 发表的一项独立系统研究发现，归档即使保留大量 JavaScript，页面重放仍会出错；终态截图则会丢失加载后的交互。研究者设计的实验性 Jawa，在一百万页面的语料库上，相较于对照技术减少了 41% 的存储用量，同时提高了重放保真度；它所处理的是非确定性执行，并未宣告捕获问题已经解决。[7] 这一层经验同样适用于今天的工具：保存下来的代码属于必要证据，未来执行是否沿同一路径仍需另行验证。

WACZ 把顺序证据变成便携式馆藏

WARC 是耐久的记录容器，远程查看器若要从头扫描数 GB 数据才能定位一条响应，访问效率就会受到限制。WACZ 在此之上增加了一份交付约定。1.2 版定义了一种 ZIP 封装：WARC 数据位于 archive/，CDXJ 查找索引位于 indexes/，必需的 pages/pages.jsonl 导航列表与根目录的 datapackage.json 清单也包含其中。每个页面条目至少带有 URL 和时间戳，还可以包含标题、提取文本及汇总大小。[4]

CDXJ 索引把已归档 URL 和捕获时间映射到 WARC 数据中的字节位置。配合独立压缩的 WARC 记录，基于范围的访问便能实际运行：查看器只请求相关片段，不用传输整套馆藏。清单列出各项资源及其路径、大小和哈希值。可选的 datapackage-digest.json 对清单本身取哈希，把完整性检查延伸至整个封装。[4]

由此，WACZ 把面向不同读者的几类内容装进同一个文件。WARC 继续保存协议证据；CDXJ 负责查找；pages.jsonl 提供人工导航和搜索背景；清单负责资源盘点与完整性。将它们一起压缩，能够简化馆藏的移动、发布和打开，也保留了底层捕获格式的原有定义。

这里有两条界线需要保持清晰。第一，完整性与真实性分属两项主张：哈希匹配只表明封装仍与清单一致，无法表明源站为内容背书，也无法证明收藏者选择了充分的范围。第二，可移植性与长期保存也分属两层。WACZ 仍需冗余存储、访问控制、定期完整性检查、有文档记录的保留制度，以及经过测试的恢复流程。封面照片中的服务器机架属于这一较后的层次。任何封装规范都替代不了持续维护的副本。

重放是一套受约束的请求解析过程

ReplayWeb.page 是一款开源查看器，在现代浏览器中以客户端方式运行。它可以从本地或远程存储加载静态 Web 归档文件，搜索页面和 URL 元数据，利用随附的提取文本做全文搜索，并渐进加载大型文件。查看器不依赖中央重放服务器，因此馆藏能够以静态数据形式托管，也能嵌入另一个网站。[5]

它有一项重要行为：健全的重放流程会从捕获记录中响应归档页面的请求，遇到缺失材料时，不会悄然转向今天的实时 Web 获取内容。实时泄漏会让损坏的归档看起来一切正常，把两个历史时刻混在一起，还会向第三方暴露读者的请求。测试时拦截出站网络访问，是揭开这层假象最简便的方法之一。

重放自身也有故障面。URL 重写会失败；请求会落在查看器没有选中的时间戳下；现代浏览器中的安全规则会阻止捕获时原本能够运行的行为；远程提供的封装若不支持查看器所需的访问方式，加载也会受阻。页面发生故障时，操作者应依次追问：相关交互执行了吗？由此产生的响应写入 WARC 了吗？它进入 WACZ 索引了吗？查看器能够解析它吗？沿着这条顺序排查，比盲目重新抓取更有用。

QA 比较两次观察，最终由人作出判断

Browsertrix 可以针对已有 WACZ 运行 QA 抓取，将重放结果与捕获时浏览器所见加以比较。使用 --screenshot view 和 --text to-warc 时，分析过程可以比较视口图像和提取文本；页面信息也会显示资源数量和响应状态分组。由此产生的分数有助于找出重放与捕获差异显著的页面。[6]

这些指标用于分流排查，不能当作验收证明。很高的截图相似度也会掩盖一个始终无法打开的菜单。文本匹配时，时间顺序仍会错乱，媒体也会出错。资源数量相等，并不能证明资源版本正确。反过来，动画、轮播横幅或延迟字体会拉低视觉分数，即使保存内容依然可用。自动比较可以缩短审查队列；一套馆藏怎样才算“足够好”，仍由收藏者依照馆藏目的判断。

一组可辩护的验收样本，规模应允许逐项检查，类型也要足够多样，能够检验既有假设。样本应包括静态文章、客户端渲染路由、无限滚动或分页视图、带第三方资源的页面，以及——仅在获得授权时——认证状态。对每个代表性页面：

1. 记录种子、范围规则、排除项、行为、浏览器配置文件政策，以及确切的爬虫版本或容器摘要。
2. 捕获一次，随后在实时网络出口被拦截的条件下重放。
3. 检查文本、图片、内部导航、时间戳，以及赋予页面意义的那项交互。
4. 改变爬虫行为之前，先在 WARC 和 WACZ 索引中检查缺失请求。
5. 将通过验收的 WACZ 连同配置、审查笔记、完整性记录和经过恢复测试的副本一起存储。

团队分工随馆藏规模变化。研究者若要保存十二个精心挑选的体验，可以使用 ArchiveWeb.page，并认真记录每次会话。小型图书馆若要反复执行数项限定范围的抓取，则需要把 Browsertrix 配置纳入版本控制，同时监测存储并维护审查队列。大型项目还需要调度、访问角色、敏感数据处理、保留政策，以及能够区分爬虫故障与重放故障的操作人员。单纯增加浏览器窗口，无法替代这些运行能力。

开放生态的真正优势来自各层可检查的分工，和神奇的捕获按钮无关。Browsertrix 与 ArchiveWeb.page 显示收藏者要求浏览器执行了什么。WARC 显示网络中传输了什么。WACZ 显示证据如何编制索引、如何封装。ReplayWeb.page 显示这些记录此刻能否支持一次访问。QA 则显示两次观察之间的分歧。

可信的 Web 归档会让这些主张保持分离，直到每一项都经过检验。它能够说明尝试了什么、记录了什么、哪些内容原样留存至今、哪些内容依然能够重放，也会如实承认：这四个问题会得到四个不同的答案。

来源

1. Webrecorder，《Browsertrix Crawler 文档》——浏览器架构、CDP 捕获、范围控制、配置文件、行为、并行窗口与 QA 支持。
2. Webrecorder，archiveweb.page——交互式浏览器扩展与 Electron 捕获、Chrome 调试协议、IndexedDB 存储和导出架构。
3. International Internet Preservation Consortium，《WARC Format 1.1》——记录模型、必填字段、请求与响应元数据、revisit 记录、摘要值及压缩指南。
4. Webrecorder，《Web Archive Collection Zipped (WACZ) 1.2.0》——封装布局、CDXJ 索引、页面元数据、清单盘点及摘要规则。
5. Webrecorder，《ReplayWeb.page 文档》——客户端重放、静态托管、渐进加载、搜索、嵌入与离线访问。
6. Webrecorder，《Browsertrix Crawler 质量保证》——对比捕获与重放的截图、提取文本及页面资源。
7. Ayush Goel、Jingyuan Zhu、Ravi Netravali 与 Harsha V. Madhyastha，《Jawa: Web Archival in the Era of JavaScript》，USENIX OSDI 2022——对 JavaScript 重放故障、交互丢失及一种经过评估的替代设计所作的独立分析。
8. Wikimedia Commons，《Internet Archive servers 5051 — Jason Scott》——文章照片的来源、日期、地点、作者、尺寸及 CC BY 2.0 许可。