拆解国家市场监管总局法规库：iframe、.do 接口与文档链接导出实战

发布于 9 小时前  12 次阅读

目标站点：https://sjfg.samr.gov.cn/law/pageInfo/main.main

目标结果：定位真实列表接口、详情接口，以及可直接复用的 Word / PDF 文档链接导出路径。

拆解国家市场监管总局法规库：iframe、.do 接口与文档链接导出实战

一、任务背景

很多政务站点表面上看只有一个搜索页，实际数据层却藏在 iframe、.do 接口、旧式表单提交和详情页包装层之后。国家市场监督管理总局法规库就是一个典型案例：

  • 首页不是最终数据入口
  • 标题链接不是在首屏 HTML 中直接给出
  • 列表页与详情页分离
  • 附件地址需要经过二次查询才能稳定拿到

这类站点如果只做静态 HTML 抓取，通常会遇到以下问题：

  1. 首页抓不到真实列表数据
  2. 标题链接缺失，无法直接进入详情页
  3. PDF / Word 文件地址不在首层页面中
  4. 翻页后数据结构不稳定，难以批量导出

因此，更稳的路径不是“硬解析首页”，而是先拆清页面层级，再找真正返回结构化数据的接口。

二、站点结构判断

目标页：

https://sjfg.samr.gov.cn/law/pageInfo/main.main

实际验证后，可以把页面结构拆成三层。

1. 外层壳页

/law/pageInfo/main.main

这一层主要负责：

  • 放置搜索表单
  • 承载 mainIframe
  • 承载 detailIframe
  • 处理页面布局与跳转

这一层并不直接提供完整法规列表。

2. 列表壳页 / 首页内容区

/law/pageInfo/law_search_new.index

以及检索结果页：

/law/pageInfo/law_search_new.law

这里能看到列表外观，但仍然不是最适合批量提取的数据入口。

3. 真实数据接口层

核心接口包括：

/law/law_search/infoShow.do
/law/law_search/infoviewOrder.do
/law/law_search/getLawStore.do
/law/law_search/queryLawByLawId.do

其中最重要的是两个：

  • getLawStore.do：负责返回检索列表
  • queryLawByLawId.do：负责返回单条法规详情与附件路径

三、核心思路：两阶段提取

这个站点最稳的抓法是“两阶段提取”。

阶段一：先抓列表

通过 getLawStore.do 拿到：

  • lawId
  • 标题
  • 效力级别
  • 时效性
  • 类别
  • 发布日期

其中 lawId 是后续所有详情查询与文件链接拼接的核心键。

阶段二：再补详情

对每个 lawId 调用 queryLawByLawId.do，再补齐：

  • lawName
  • filePath（PDF 路径）
  • fileUrl（Word / doc / docx 路径）
  • originFilePath（原始文件路径，部分记录存在）

这样做的好处是：

  • 列表页抓取稳定
  • 附件链接来源明确
  • 详情与文件可批量导出
  • 后续做 CSV / JSON / 数据落库都方便

四、列表接口确认

列表接口：

POST /law/law_search/getLawStore.do

这是一个典型的旧式表单接口，请求体使用表单字段提交，而不是 JSON。

已验证的关键字段

pageNo
pageSize
searchScope
searchType
timeValid
lawType
validLevel
departDuty
valid
lawName
startTime
pubTime

这些字段即使留空，接口通常也要求保持同一套表单结构，否则容易出现结果异常或默认条件变化。

这一层拿到什么

getLawStore.do 返回的是标准化列表数据，核心价值在于：

  • 可以稳定翻页
  • 每条记录都有 lawId
  • 标题不需要再从 HTML 里硬抠
  • 不必依赖前端脚本拼接链接

五、详情接口确认

详情接口：

POST /law/law_search/queryLawByLawId.do

请求只需要围绕 id=<lawId> 发送。

这一层拿到什么

详情返回对象中，最有价值的字段通常包括：

  • lawName
  • filePath
  • fileUrl
  • originFilePath

其中：

  • filePath 常用于 PDF 文件
  • fileUrl 常用于 Word / DOC / DOCX 文件
  • originFilePath 并非每条都有，但遇到特殊材料时很有用

也就是说，详情页本身很多时候只是展示包装层，真正决定“能不能下载附件”的是这个接口返回值。

六、页面与接口的对应关系

完整关系可以概括为：

main.main
  └─ iframe -> law_search_new.index / law_search_new.law
       └─ 列表数据 -> getLawStore.do
            └─ lawId -> queryLawByLawId.do
                 ├─ filePath       -> PDF
                 ├─ fileUrl        -> Word / DOC / DOCX
                 └─ originFilePath -> 原始文件

这也是很多老站最常见的模式：

  • HTML 只是壳
  • 真数据在 .do
  • 点击标题只是把 lawId 带到另一个包装页
  • 文件地址最终还是要从详情接口里取

七、为什么首页抓取不可靠

直接抓首页通常会失败，原因主要有四类。

1. 首屏 HTML 并不完整

页面初始返回的 HTML 只负责结构，不负责把所有标题与链接直接写死。

2. 标题点击链接是后拼的

很多标题点击逻辑是前端根据 lawId 动态拼接出来的，首屏源码里未必直接可见。

3. 附件地址在详情层

即便进入详情页，PDF / Word 地址也未必直出在静态源码里，仍可能来自后续接口。

4. 翻页抓取不稳定

如果只模拟点击分页而不理解底层参数，批量导出时很容易漏页、重复或错位。

八、实测导出策略

针对这个站点，最实用的做法是：

  1. 先循环请求 getLawStore.do
  2. 收集每条记录的 lawId
  3. 再逐条请求 queryLawByLawId.do
  4. 将标题、详情页地址、Word 地址、PDF 地址统一落表
  5. 最终导出为 CSV / JSON

这类流程特别适合以下目标：

  • 法规标题清单导出
  • Word / PDF 下载链接批量提取
  • 建立法规索引库
  • 后续做检索、标签、知识库入库

九、已验证的本地成果

本地已经走通并留存了对应导出结果，包含：

  • 标题与 PDF 链接导出
  • 标题与 Word / PDF 双链接导出
  • 可复用的脚本入口
  • 对应的站点分析说明

相关路径示例：

skills/gov-site-analyzer/references/samr-law-db-example.md
skills/gov-site-analyzer/scripts/export_samr_law_links.py
tmp/samr_law_export/
tmp/samr_law_word_export/

如果目标是“再次复用同类型方法分析别的政府站点”，这套路径已经具有很高的参考价值。

十、适合沉淀成固定流程的部分

这一案例非常适合抽象成通用分析模板，至少可以固定出以下步骤：

1. 先拆页面壳层级

判断是否存在：

  • 入口壳页
  • iframe 列表页
  • 详情壳页
  • 真正数据接口

2. 再区分列表接口与详情接口

重点确认：

  • 列表接口是否返回稳定主键
  • 详情接口是否返回附件路径
  • 点击行为是否只是包装跳转

3. 最后做两阶段导出

统一采用：

  • 列表采集
  • 详情补全
  • 文件链接标准化
  • CSV / JSON 导出

这种模式并不只适用于市场监管总局法规库，很多老式政府站点、协会站点、院校制度库都能套用。

十一、结论

这次拆解说明了一件很重要的事：面对旧式政务站点，真正高效的方法往往不是继续和页面 HTML 缠斗，而是尽快识别出“壳页、iframe、列表接口、详情接口、附件路径”之间的关系。

对于国家市场监督管理总局法规库，当前已经可以明确得出以下结论：

  • 真实列表入口：getLawStore.do
  • 真实详情入口：queryLawByLawId.do
  • 稳定主键：lawId
  • 文档导出关键字段：filePath、fileUrl、originFilePath
  • 最稳抓法：两阶段提取，而不是首页硬解析

一旦这套关系被拆清，后续无论是做法规归档、附件批量下载、全文索引还是知识库整理，都会顺得多。

十二、附：关键路径速查

入口页：
https://sjfg.samr.gov.cn/law/pageInfo/main.main

列表壳页：
https://sjfg.samr.gov.cn/law/pageInfo/law_search_new.index
https://sjfg.samr.gov.cn/law/pageInfo/law_search_new.law

列表接口：
https://sjfg.samr.gov.cn/law/law_search/getLawStore.do

详情接口：
https://sjfg.samr.gov.cn/law/law_search/queryLawByLawId.do

如需进一步扩展，下一步最适合补上的内容通常有两类：

  1. 完整请求示例（含 requests 版代码）
  2. 批量导出脚本的参数化封装与异常重试

或许明日太阳西下倦鸟已归时