网页证据如何长期复核：快照、静态 HTML 与 PDF 归档链路
网页证据如何长期复核，真正困难的通常不是完成一次 API 调用，而是让结果可以校验、失败可以定位、后续能够回到原始证据。本文围绕“如何保存网页快照、静态 HTML、PDF 和域名状态，建立可复核的网页归档证据链”给出一套可以直接落到任务状态和数据契约上的实现方式。
问题与结果
抓取时间、原 URL、HTML、截图、PDF 和文件哈希统一入档，后续能证明归档内容来自哪次采样。
最终交付不是一段不可追溯的模型回答，而是一组带来源、版本、状态和失败记录的数据。这样既方便接入后续系统，也能在接口、页面或模型输出变化时定位问题。
适用场景
- 公开网页定期归档
- 活动与政策页面留痕
- 站点变更前后对比
实现前先确定边界
- 归档任务必须记录采样时间和最终跳转 URL
- HTML、截图和 PDF 是不同证据形态
- 访问受限或抓取失败时只记录失败状态，不尝试绕过
可验证工作流
API 编排与职责
| 步骤 | 接口 | 请求方式 | 用途 |
|---|---|---|---|
| 标题图标 | 获取任意站点标题与图标 |
GET | 保存页面标题、站点图标等基础信息 |
| DNS 查询 | 域名 DNS 信息查询 |
GET | 保存域名解析信息 |
| SSL 证书 | 域名 SSL 证书信息解析 |
GET | 保存证书主体、有效期等信息 |
| WHOIS | 域名 Whois 查询 |
GET | 保存域名注册信息 |
| 网页快照 | 网站截图与 HTML 快照 |
POST | 同时保存截图和 HTML 快照 |
| 静态 HTML | URL 转静态 HTML 文件 |
POST | 生成可归档的静态 HTML |
| PDF 导出 | HTML/URL 转 PDF |
POST | 将页面导出成 PDF |
| Word 导出 | HTML 转 Word |
POST | 将页面内容导出成 Word |
最小可运行实现
保存网页快照：
curl -X POST "https://api.gugudata.com/websitetools/url2snapshot?appkey=YOUR_APPKEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/campaign/page",
"responseFormat": "base64",
"fullPage": true,
"width": 1920,
"height": 1080,
"deviceScaleFactor": 1,
"isMobile": false
}'
生成静态 HTML：
curl -X POST "https://api.gugudata.com/websitetools/url2html?appkey=YOUR_APPKEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/campaign/page"
}'
查询域名 SSL 信息：
curl -G "https://api.gugudata.com/v2/websitetools/sslcertinfo" \
--data-urlencode "appkey=YOUR_APPKEY" \
--data-urlencode "domain=example.com"
Agent 可以用归档任务记录每次执行：
def build_archive_record(url: str, snapshot_id: str, status: str) -> dict:
"""Build a webpage archive record."""
return {
"source_url": url,
"snapshot_id": snapshot_id,
"status": status,
"artifacts": ["snapshot", "html", "pdf"],
}
归档记录怎么设计
网页归档建议保存以下字段：
| 字段 | 说明 |
|---|---|
| source_url | 原始 URL |
| normalized_url | 规范化后的 URL |
| captured_at | 归档时间 |
| page_title | 页面标题 |
| domain_info | DNS、SSL、WHOIS 摘要 |
| snapshot_file | 截图或快照文件 |
| html_file | 静态 HTML 文件 |
| pdf_file | PDF 文件 |
| status | 成功、部分成功、失败、待重试 |
对于需要长期保存的页面，应保留多个版本，而不是覆盖旧文件。版本差异可以用于活动复盘、竞品监控或内容审计。
失败分类与降级
如果页面需要登录、被防爬或加载超时，Agent 应记录失败原因，而不是生成空白归档。若 DNS 或 SSL 查询失败，但页面快照成功，可以标记为部分成功。对于动态页面，建议同时保存全页截图和 HTML 快照。
归档任务应支持重试，但重试生成的是新版本，不应覆盖第一次归档时间。
数据契约与留痕
建议至少保存以下字段；真实项目可以继续拆分，但不要删除来源、版本和状态信息。
| 字段 | 作用 |
|---|---|
archive_id |
稳定业务标识，用于关联记录并避免名称冲突 |
requested_url |
来源或目标 URL，保留最终跳转前后的差异 |
final_url |
来源或目标 URL，保留最终跳转前后的差异 |
captured_at |
带时区的采样或生成时间，判断数据新鲜度 |
html_hash |
内容哈希，用于完整性校验、版本识别和去重 |
snapshot_hash |
内容哈希，用于完整性校验、版本识别和去重 |
pdf_hash |
内容哈希，用于完整性校验、版本识别和去重 |
domain_evidence |
业务数据字段，保存时记录来源、口径和缺失状态 |
所有派生结果都应带生成时间和输入版本。发生重试时新增尝试记录，不要覆盖最后一次失败，以免排查时只剩“最终成功”而看不到中间问题。
验收清单
- [ ] 所有产物都有哈希和时间
- [ ] 同一 URL 的多次归档不会相互覆盖
- [ ] 失败和权限缺口能在清单中明确识别
能力边界
技术归档不自动具备法律证据效力，也不能绕过登录、验证码、付费墙、robots 或访问控制。
示例中的 YOUR_APPKEY 仅为占位符。真实密钥只能放在服务端环境变量或密钥管理系统中，不应进入前端、文章、日志或版本库。
–EOF–
转载须以超链接形式标明文章原始出处和作者信息
