网页证据如何长期复核:快照、静态 HTML 与 PDF 归档链路

网页证据如何长期复核,真正困难的通常不是完成一次 API 调用,而是让结果可以校验、失败可以定位、后续能够回到原始证据。本文围绕“如何保存网页快照、静态 HTML、PDF 和域名状态,建立可复核的网页归档证据链”给出一套可以直接落到任务状态和数据契约上的实现方式。

网页证据如何长期复核,真正困难的通常不是完成一次 API 调用,而是让结果可以校验、失败可以定位、后续能够回到原始证据。本文围绕“如何保存网页快照、静态 HTML、PDF 和域名状态,建立可复核的网页归档证据链”给出一套可以直接落到任务状态和数据契约上的实现方式。

问题与结果

抓取时间、原 URL、HTML、截图、PDF 和文件哈希统一入档,后续能证明归档内容来自哪次采样。

最终交付不是一段不可追溯的模型回答,而是一组带来源、版本、状态和失败记录的数据。这样既方便接入后续系统,也能在接口、页面或模型输出变化时定位问题。

适用场景

  • 公开网页定期归档
  • 活动与政策页面留痕
  • 站点变更前后对比

实现前先确定边界

  1. 归档任务必须记录采样时间和最终跳转 URL
  2. HTML、截图和 PDF 是不同证据形态
  3. 访问受限或抓取失败时只记录失败状态,不尝试绕过

可验证工作流

网页证据如何长期复核工作流架构图

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 仅为占位符。真实密钥只能放在服务端环境变量或密钥管理系统中,不应进入前端、文章、日志或版本库。