水果弟做爬虫这几年，我最大的体感是：真正费劲的不是把一页网页抓下来，而是面对一堆“不是为机器设计”的公开资料时，还能把它拆成规则化的结构化结果。无线电频率划分总表就是一个特别典型的练手目标。它数据量不算大，页面几乎没什么反爬强度，更新频率也很低，但它的 HTML 排版完全继承了纸质文件的习惯：合并单元格、跨行频段、各种上标脚注、一条单元格里塞三种含义。这种情况下，爬虫只是最后一段路，规则化采集和结构化转换才是真正决定项目成败的地方。如果你正想找一类“爬下来容易、处理好难”的实战场景，这个表能帮你把解析思路整体拉高一个台阶。
1. 这轮爬虫的难点不在封IP，而在一张表格塞了太多“附加信息”
1.1 频率划分总表到底长什么样
无线电频率划分总表，本质上是公开频谱资源的一份大台账。它把从低频到高频的无线频段，逐段列出来，再标注这些频段被分配给哪些业务使用。普通人脑子里可能想的是：第几行、第几列、频段多少到多少、业务是什么，完了。
实际打开页面你就会发现，它完全不是干净二维表。一个典型的表格行里，可能同时出现这些东西：
- 某一栏写“135.7-137.8 MHz”，这只是最基础的频率范围；
- 紧跟着的业务栏里，可能同时列出多个业务，比如“固定”“移动（航空移动除外）”“无线电导航”混在一起；
- 业务后面还带着脚注引用，形如“5.155”“5.155A”这种编号，有的在单元格里就是一行普通文字，有的藏在上标标签里；
- 表格里还分主要业务、次要业务，不同语义之间的分隔可能是换行、空格，也可能是字体样式差异；
- 还有“地对空”“空对地”“上行”“下行”这类方向性描述，一并揉在同一个格子里。
真正做过的人都知道，这种数据如果直接按 <tr> 一行行读出来，你会得到一堆“看起来是人话，但机器完全没法用”的字段。这也是这类规则化采集项目最核心的矛盾：数据已经公开在网页上了，可它的表达方式还是给人眼看的，不是给数据库看的。我们要做的，就是先把这个物理排版转成逻辑记录。
1.2 为什么这个目标适合练“规则化采集”
我见过不少新手练爬虫，一上来就抓新闻标题、抓商品价格，那种页面结构太规整了，用选择器点一下就完事，做完之后除了知道 requests 会发请求，其他什么都没学到。频率划分总表反而是个很不错的工程训练场，原因有几个：
第一，数据公开、稳定、低频更新。你不用应付高强度反爬，可以把精力全部放在解析和转换上。第二，它有明确的“物理页面”和“逻辑记录”的区别，非常适合练习从脏排版中恢复字段。第三，它会影响好几代版本，每隔几年会有新版本发布，意味着你的结构化引擎以后还可以做版本对比和增量抓取。第四，它本质上是一个“多级归属”问题：频段归属业务，业务归属主要/次要分类，同时还有脚注引用，这是很多企业级数据治理场景的缩小版。
所以别把这个标题理解成“爬一个政府表格”，把它理解成“把一个排版随意、附带脚注层级、还有跨行的表格，变成可查询可对比的数据集”，价值就出来了。后面的方案，也能迁到其他任何需要规则化采集的领域。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 采前侦察：先摸清网页的脾气，再决定写不写解析器
2.1 默认编码很可能就是第一个坑
这种公告性质的页面，尤其是一些老站点，常常不是标准 UTF-8。直接 requests.get(url).text 去解，经常出现一半中文乱码一半标签正常，很多人的爬虫第一步就死在这里。
我习惯先不看正文，先看响应头里的字符集声明，再用 apparent_encoding 做一次兜底：
python复制import requests
url = "YOUR_TARGET_URL" # 替换成你实际拿到的公开页面地址
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}
resp = requests.get(url, headers=headers, timeout=20)
print(resp.status_code)
print(resp.apparent_encoding)
print(len(resp.text))
如果 resp.text 已经乱码，最简单的处理是：
python复制resp.encoding = resp.apparent_encoding
html_text = resp.text
有极少情况 apparent_encoding 也会判断错，那么就用 resp.encoding = "gbk" 试一次，再不行试 utf-8。这里没有万能银弹，但先把编码确认清楚，后面能少掉一大半冤枉时间。
另外，很多老站对没有 User-Agent 的请求直接回 403。我上面代码里带了 UA，这属于最基本的礼貌。别一遇到 403 就想到代理和伪装，很多时候只是差一个请求头。
2.2 先定位主表，不要急着写字段选择器
拿到 HTML 之后，不要立刻写解析器。先做一次清点：页面里到底有多少个 table，哪个才是真正承载频率划分总表的主表。很多旧站页面上会塞导航、侧栏、推荐阅读，这些都会生成 table。我一般先按“文本指纹 + 行数”两层过滤：
python复制from bs4 import BeautifulSoup
soup = BeautifulSoup(html_text, "lxml")
candidates = []
for table in soup.find_all("table"):
text = table.get_text(" ", strip=True)
if "频率划分" in text or "业务" in text:
rows = table.find_all("tr")
if len(rows) > 20:
candidates.append(table)
print("candidate table:", len(rows), len(text))
main_table = candidates[0]
为什么先定位主表而不是直接用 .select("table tr td")？因为这个表可能有嵌套表格，如果直接全局取 tr，会把内层无关表格的行也抓进来。先找到主表对象，后面所有解析都限定在 main_table.find_all("tr") 范围内，才不会被杂散节点干扰。
2.3 HTML 版和 PDF 版的取舍
很多这种频率划分文件会同时提供 PDF 版和网页版。我的建议是优先解析 HTML 版，除非你确实拿不到。原因不是你写不了 PDF 解析，而是 PDF 的文本流是“排版顺序”，不是“阅读顺序”。表格在 PDF 里可能被切成无数个文本块，你需要根据坐标去拼行，工程量大很多。
HTML 版虽然也是给浏览器排版看的，但它好歹保留了行、单元格、上标这些语义边界。你要做的只是把单元格内的“人话”继续拆细。两个版本的难度对比很直观：
| 对比维度 | HTML 版 | PDF 版 |
|---|---|---|
| 文本顺序 | 相对可靠 | 可能被打散 |
| 单元格边界 | 有 table 结构 | 需要坐标推断 |
| 脚注引用 | 能定位到 sup/文本 | 常混在文本流里 |
| 初版解析难度 | 中 | 高 |
| 多版本对照 | 方便 | 一般 |
HTML 版本就够你练习规则化采集了。PDF 可以留着以后做交叉校验，不要一开始就啃硬骨头。
3. 规则化解析的核心：把跨行、跨列、脚注混排拍平成数据行
3.1 第一个硬骨头：rowspan 和 colspan 导致的行错位
频率划分总表在浏览器里是规整的，但 DOM 在表达合并单元格时，是用 rowspan 和 colspan 把相邻格子合并起来渲染的。如果你直接遍历每一行再 find_all("td")，合并单元格带来的后果就是：有些行比其他行少一个格子；某个“行”里实际上写的是上一行频段下的延续业务；如果你按行索引去取业务列，下标会错位。
解决这个问题的通用办法，是把 HTML 表格先展开成一个二维矩阵。每个被 rowspan 合并的单元格，我们要在后面几行继续填充同一个文本；每个被 colspan 合并的单元格，我们要在同一行横向复制多列。完成这一步之后，每一行的列数一致，后续解析才能稳定。
我给一个可以直接跑通核心逻辑的矩阵展开函数：
python复制from bs4 import BeautifulSoup
def table_to_matrix(table):
rows = table.find_all("tr")
# 先统计最大列数
max_cols = 0
for tr in rows:
col_count = 0
for cell in tr.find_all(["td", "th"], recursive=False):
col_count += int(cell.get("colspan", 1) or 1)
max_cols = max(max_cols, col_count)
matrix = []
hold = {} # 上一行遗留的 rowspan: col_index -> (text, remaining_rows)
for tr in rows:
row = [""] * max_cols
next_hold = {}
# 继承上一行跨下来的内容
for col_index, (text, remain) in hold.items():
row[col_index] = text
if remain > 1:
next_hold[col_index] = (text, remain - 1)
col_index = 0
cells = tr.find_all(["td", "th"], recursive=False)
for cell in cells:
# 如果这列已经被 rowspan 占用，就往右找空位
while col_index < max_cols and row[col_index] != "":
col_index += 1
text = " ".join(cell.get_text(" ", strip=True).split())
rowspan = int(cell.get("rowspan", 1) or 1)
colspan = int(cell.get("colspan", 1) or 1)
for offset in range(colspan):
if col_index + offset < max_cols:
row[col_index + offset] = text
if rowspan > 1:
for offset in range(colspan):
next_hold[col_index + offset] = (text, rowspan)
col_index += colspan
matrix.append(row)
hold = next_hold
return matrix
这个函数有一个需要留意的前提：只处理不含嵌套表格的“平铺表格”。如果某一行里藏了复杂的内嵌结构，建议先用 recursive=False 只抓直接单元格，避免把内层节点带进来。得到二维矩阵之后，每一行就能用统一的 row[0]、row[1] 去取字段了。
3.2 识别“真正的频率记录行”，并且做上下文延续
表格矩阵化之后，下一步是行分类。你会发现不是每一行都是有效数据行。这里面至少有三种情况：
- 表头行，比如“频段(MHz) / 业务 / 脚注”，需要丢弃；
- 重复的页眉行，某些长表格打印到一半会在中间重复出现表头，需要丢弃；
- 真正的数据行，特征是第一列或第二列包含频率范围，例如“135.7-137.8MHz”；
- 延续行，第一列没有频率范围，但业务列还有内容。这种行在视觉上属于上一条频率记录，因为上一条记录的频段可能跨了几行、对应了多个业务。
频率列的正则可以用得很简单：
python复制import re
FREQ_PATTERN = re.compile(
r"(\d+\.?\d*)\s*[-–—~]\s*(\d+\.?\d*)\s*(GHz|MHz|kHz)?",
re.I,
)
def is_freq_row(row):
return bool(FREQ_PATTERN.search(row[0]))
延续行的处理策略是维护一个“当前频率上下文”。如果当前行第一列不匹配频率模式，但第二列或业务列有文本，就说明它还在补充上一段频段的业务内容，那么要把它归属到上一条频率范围内处理。我不建议直接把这种行丢弃，因为频率划分总表里，一个频段配多组业务的情况非常常见。
判断逻辑可以是一段循环：
python复制records = []
current_freq_record = None
for row in matrix:
if is_freq_row(row):
if current_freq_record:
records.append(current_freq_record)
current_freq_record = {
"raw_freq": row[0],
"raw_service_col": row[1],
"raw_footnote_col": row[2] if len(row) > 2 else "",
}
else:
if current_freq_record and row[1].strip():
current_freq_record["raw_service_col"] += " " + row[1]
if current_freq_record:
records.append(current_freq_record)
这里的核心思想是：不要让频率段重复出现多次，而是把后续行都“吸”到前一条频率记录的原始文本里。后面再做单元格文本切分时，才有机会把一个频段下的所有业务合并分析。
3.3 单元格里的“三层内容”怎么剥离
频率记录行里最麻烦的字段，通常不是频率本身，而是业务列和脚注列往往混在一起。一个单元格内可能出现这种形态：
text复制固定 5.441
移动 5.552
卫星（地对空）5.441
你要把它拆成三层：业务名称、业务方向描述、脚注引用编号。HTML 里如果脚注用 <sup> 标签，你还能利用标签边界；但如果它只是普通文本，那就只能用正则规则去切。
频率脚注有一个比较好的文本特征：大部分国际脚注编号形如“5.155”“5.155A”“5.441”这类。真正属于业务描述的文字里很少出现这种纯数字 + 点号 + 可选字母的段落。于是可以先用正则把引用编号摘出来，再从业务文本里移除这些编号：
python复制FOOTNOTE_PATTERN = re.compile(r"\b5(?:\.\d{1,3}[A-Z]?|[A-Z]?\b)")
def split_business_and_footnote(raw_text):
refs = FOOTNOTE_PATTERN.findall(raw_text)
service_text = FOOTNOTE_PATTERN.sub(" ", raw_text)
service_text = " ".join(service_text.split())
return service_text, refs
要注意，这类正则不是放之四海皆准。不同版本的频率划分总表，脚注编号前缀可能是“5.”也可能是“9.”，有些版本还会有“5.155A”这种带字母的变体。最好在动手之前，先把页面里的脚注样本打印 20 条出来看一眼，再调整正则。这就是采集过程中的“规则调优”，没有谁能一次性写对。
另外，如果页面上同一个脚注编号出现了多次，我不建议直接去重后放进程里，因为后面做质量核对时你可能需要知道“这条脚注被哪几个频段引用了”。所以这个阶段保留重复项反而有用。
3.4 频率范围要正确归一化
频率范围列常常会出现千位空格。比如页面里写的是“1 350-1 400 MHz”，直接当成字符串存进数据库，以后没法做数值区间查询。建议先清洗掉空格和逗号，再统一匹配：
python复制def parse_freq_range(raw):
raw_clean = raw.replace(" ", "").replace(",", "").strip()
m = FREQ_PATTERN.search(raw_clean)
if not m:
return None
start = float(m.group(1))
end = float(m.group(2))
unit = (m.group(3) or "MHz").upper()
if unit == "GHZ":
start *= 1000
end *= 1000
elif unit == "KHZ":
start /= 1000
end /= 1000
return start, end # 统一成 MHz
这个函数的处理逻辑是：如果单位是 GHz，就乘 1000 转成 MHz；如果是 kHz，就除以 1000 转成 MHz。如果原始文本没写单位，默认沿用表格表头的单位，这也是为什么我推荐先认真看表头，因为很多频率行里确实不会重复写“MHz”。
解析完之后顺手做一次数值校验：start < end 必须成立。如果出现起点大于终点，多半是正则匹配到单位后字段错位了，或者单元格文本里包含“GHz”与“MHz”的复合写法，这种行应该单独告警，而不是静默入库。
4. 从“抓到数据”到“结构化引擎”：用模板化的转换逻辑替代硬编码
4.1 抽取层和转换层为什么要分开
很多爬虫代码写到后面会变成一个大函数：发请求、解析表格、提取字段、写文件，全堆在一起。一次性跑通没问题，但频率总表一旦换版本或换个页面布局，你就要在一大堆代码里重新梳理“哪里是在管网页，哪里是在管业务字段”。
所以我会把项目拆成两层。抽取层只负责一件事：从 HTML 里取出二维矩阵，再把“物理行”聚合成“有频率上下文的原始记录”。转换层只负责另一件事：把原始记录里的字符串，切成结构化的 Python 字典。
这样做最大的好处是，换了页面结构，你只改抽取层；换了字段规则，你只改转换层。结构化转换引擎的本质，不是写一个万能类，而是把这层边界划清楚。
4.2 用统一 Record 结构承载数据
我给每条记录定一个很明确的结构：
python复制{
"freq_start_mhz": 135.7,
"freq_end_mhz": 137.8,
"service_primary": ["固定", "移动"],
"service_secondary": ["业余"],
"footnote_refs": ["5.155"],
"source_version": "2023_edition",
"source_url": "YOUR_TARGET_URL",
"crawl_time": "2024-01-01T12:00:00"
}
说明几点。第一，频率字段用数值型，不要用字符串，否则后面没法做范围重叠检测。第二，业务字段用列表，而不是用“/”拼接的长字符串，因为一条频率记录可以有多个主要业务、多个次要业务，列表后续更容易做统计和筛选。第三，脚注引用单独放一个列表，将来如果你要真正去解析每一条脚注的完整文本，可以用这个字段做关联。第四，crawl_time 和 source_version 必须带上，不然哪天页面更新了，你连自己手里这批数据是哪一版都不知道。
转换层代码可以这样写：
python复制def raw_record_to_structured(raw, source_version, source_url):
freq = parse_freq_range(raw["raw_freq"])
if not freq:
return None
service_text, footnote_refs = split_business_and_footnote(raw["raw_service_col"])
primary, secondary = split_primary_secondary(service_text)
return {
"freq_start_mhz": freq[0],
"freq_end_mhz": freq[1],
"service_primary": primary,
"service_secondary": secondary,
"footnote_refs": footnote_refs,
"source_version": source_version,
"source_url": source_url,
"crawl_time": datetime.now().isoformat(timespec="seconds"),
}
4.3 主要业务和次要业务的拆分
不同版本的页面在“主要业务”和“次要业务”的展示方式上差别很大。有的页面用两列分开，有的页面在同一列里用“主要业务：”“次要业务：”这种文字前缀区分，有的页面干脆不写这五个字，而是用字体大小或颜色区分。HTML 转换成人眼看是没问题的，机器看就有点麻烦。
我常用的做法是分三层处理。第一层，如果页面本身有“主要业务”和“次要业务”两列，那我就按列直接拆。第二层，如果是在同一格文本里带文字提示，那就用“主要业务”“次要业务”作为切分关键词，把文本切成两段。第三层，如果没有任何显式标识，只靠样式区分，那就需要看 HTML 的 class 或内联样式，比如 <span class="primary">。这一层不通用，必须针对实际页面做定制。
在跑流程前，先抽样打印几十个原始单元格文本，比直接写代码试错要高效得多。很多爬虫问题都不是“方法不对”，而是“没看清楚数据长什么样”。
4.4 先说清楚校验规则，再谈批量入库
我工作里见过太多项目，代码能跑起来、数据能存进 MySQL，结果隔天做统计时发现频率范围换算错了，或者重复行多了一倍。原因就是解析完以后没有校验。频率划分总表这种数据，非常适合在入库之前做一次自动检查。
每条结构化记录至少应该满足：
freq_start_mhz和freq_end_mhz都大于 0；freq_start_mhz < freq_end_mhz；- 主要业务或次要业务至少有一个非空；
- 如果主要业务为空但脚注引用非空，需要人工确认，可能有解析遗漏；
- 同一版本里，不允许存在“起止频率完全相同 + 业务内容完全相同”的两条记录。
校验代码不需要多复杂，关键是让它跑在入库之前，而不是入库之后：
python复制def validate_records(records):
seen = set()
errors = []
for index, record in enumerate(records):
if record is None:
errors.append(f"line {index}: converter returned None")
continue
if record["freq_start_mhz"] >= record["freq_end_mhz"]:
errors.append(f"line {index}: invalid freq range")
if not record["