拼多多字体加密逆向：Python静态解密方案详解

1. 解密思路与项目背景

1.1 我们先搞清楚拼多多前端到底做了什么

现在的电商网页反爬，早就不是简单地去识别UA、加个验证码这么基础了。拼多多的PC端网页，在商品详情页、搜索结果页这些带着价格和销量信息的关键位置，用了一套很有意思的字体加密方案。你打开浏览器开发者工具，看到DOM里的价格是一个长得像乱码的实体编码，但是页面上渲染出来却是正常的数字。那会儿我第一次扒它的HTML时，还以为是页面加载了JS动态渲染，后来追了一下请求才发现——问题出在字体文件上。

具体点说，拼多多网页会在运行时动态加载一个woff格式的字体文件，这个字体文件里定义了一套自定义映射关系：把阿拉伯数字0到9，以及小数点、可能还有加号、减号、百分之这种符号，重新映射成了一个私有的Unicode码位。浏览器拿到HTML之后，再配合这个字体文件渲染，于是普通用户肉眼看到的是一个正常的价格，比如199.90元，但是你在HTML源码里看到的，是类似这种鬼东西。

这里有一个很关键的方向，就是我们后面整个项目的主心骨：字体加密的实现原理，本质上不是“加密”，而是“替换”——换了一套编码映射规则。既然是替换，那就意味着信息没有丢失，它只是被“翻译”成了另一种形式。只要我们能拿到那套字体文件，把映射关系还原出来，我们就能把DOM里的乱码字符翻译回真实数字。

这个思路落到代码上，就是我们常说的静态解密方案，也是我这次想重点分享的一条实现路径。什么叫静态？就是不去动态运行浏览器里面的JS逻辑，也不打算用Selenium、Playwright这类重型浏览器自动化工具去等页面渲染完再抓渲染后的文本。而是用Python直接去拿HTML原始源码，拿到字体文件，然后把字体文件里定义的字形映射关系逆向出来，在本地做一次“解码”。

这个方案和当前比较热门的“拼多多订单导出工具”或者“拼多多API”这类以接口对接为主的做法不一样，它属于纯前端逆向加爬虫工程结合的活儿，好处是相对轻量、部署简单，坏处是会随着前端调整而失效，需要维护映射表。所以这也引出了本文的定位：针对静态状态下、字体文件可获取的场景，给出一个可落地、可复现的Python实现。

1.2 静态方案与动态方案的分界线

在实际做爬虫或者网页数据采集的时候，我们通常会把反爬策略分成两类来考虑，一类叫静态应对，另一类叫动态应对。静态应对的特点是：不需要执行JavaScript、不需要模拟用户操作，只通过分析静态资源和HTTP响应来还原数据；动态应对则是用无头浏览器去把整个页面跑起来，等JS执行完、字体也加载完之后，直接获取渲染后的文本。

字体加密这种场景，如果你用动态方案去解决，本质上是在“绕”，因为浏览器已经帮你完成了字体映射这个动作，你拿到的文本是正常的。但是动态方案有几个绕不开的问题：第一，性能和资源开销大，开一个无头浏览器吃几百兆内存很常见，要并发就得堆机器；第二，稳定性差一些，页面加载慢、网络抖动、验证码弹出、滑块出现，都会影响采集的成功率；第三，容易被检测，无头浏览器虽然越来越像真人操作，但在特征检测面前还是有暴露的风险。

而静态方案，只要能把字体文件稳定地下载下来，映射关系稳定地建立起来，整个流程就非常轻快。一次请求拿HTML，再根据HTML里引用的字体文件路径去拿woff文件，解析woff得到映射表，最后用映射表把HTML里所有加密字符替换回明文。整个过程不走浏览器、不跑JS、不渲染页面，理论上可以做到很高的并发。

当然，静态方案也有它脆弱的地方。比如拼多多现在很多时候字体文件路径是动态生成的，HTML和字体文件的关联不是写死的一个静态路径，而可能是带时间戳、随机参数的。再比如字体映射表不是永远只有一套，它可能隔一阵子就变。这些不确定性决定了，我们的静态方案不能只做一次就不管了，而是要把它设计成一个可持续迭代的工具链。

一句话总结我的建议：如果你的采集场景允许跑重量级工具、追求极致稳定，动态方案是你的保底手段；但如果你想做高频、轻量、分布式的数据采集，静态解密方案的性价比要高得多。本文后面的内容，就围绕静态方案展开。

2. 字体加密的核心原理与解密思路

2.1 从woff字体文件里能挖出什么

在正式写代码之前，我强烈建议大家先把woff字体文件的内部结构搞清楚。这个知识点是整个项目的基石，不然后面写代码就是在抄模板，遇到问题根本不知道怎么排查。

woff（Web Open Font Format）本质上是一个容器格式，它里面包着的是TrueType或者OpenType字体数据。而TrueType字体文件里，有几个表（Table）特别关键，其中对我们解密最有价值的是cmap表和glyf表。

cmap表的中文名叫“字符到字形映射表”，它的作用是把一个字符编码（也就是我们平时说的Unicode码点）映射到一个字形ID（glyph ID）。举个例子：假设在标准的字体文件里，字符“1”的Unicode码点是U+0031，它在cmap表里会被映射到某一个glyph ID；而在加密的字体文件里，同一个视觉上的“1”，可能被塞到了一个私有区段的码位上，比如U+EA17，这个码位也会在cmap表里映射到某个glyph ID。

glyf表存储的是真实的字形轮廓数据，也就是每个字形长什么样——每个轮廓的坐标点、曲线的控制点、路径的填充方式等等。字形ID通过cmap表的映射定位到glyf表里的具体记录，进而告诉渲染引擎“这个字符该画成什么形状”。

到这里，解密思路实际上就出来了。正常情况下，我们会有一个“标准数字字体”，比如系统自带的Arial，它里面的字符编码和字形是一对一的、有序的。比如0到9这十个数字，它们的码位是连续的U+0030到U+0039，字形也是一个递增的序列。而在加密字体里，码位虽然变了，但是——字形轮廓本身没有变。数字“1”就是“1”，不管它被映射到哪个码位，它的字形坐标数据在几何形状上和标准字体里的“1”是相同的。

所以我们的解密算法核心可以归结为一个“找相似”的过程：解析加密字体文件，提取出每个码位对应的字形轮廓；再拿这些轮廓和我们手头的一套标准数字字形做形状相似度比对；比对上了，就反推出“加密码位U+EA17对应的其实是数字1”。

这个比对过程，既可以用图像处理来做（把字形渲染成图片，然后用像素相似度比对），也可以用几何信息来做（提取字形的路径范围、坐标分布、特征点，做矢量比对）。在实际工程里，我更推荐后一种方式，原因主要有两点：一是矢量比对不受渲染分辨率影响，精度更高；二是Python生态里 fontTools 这个库可以直接拿到字形的坐标数据，配合 numpy 做计算，效率很高。

2.2 一套映射表吃遍所有场景？没那么简单

很多入门者在看到这套方案的第一反应是：那我写好一次解析，把映射表保存下来，以后直接用不就行了？这个想法方向是对的，但有一个坑：拼多多的字体加密，映射关系不是一成不变的。

我在实际抓取中遇到过几种情况。有时候隔几天重新抓，发现字体文件变了，数字对应的码位全部重新打乱了；有时候同一天内，不同接口下发的字体文件也是不同的。这说明服务端的加密策略很可能是有轮换机制的，可能是一段时间换一次，也可能是每个用户会话或者每次请求都动态生成。

因此，我在设计这个静态方案时，采用了一个更稳妥的思路：不依赖一劳永逸的固定映射表，而是在每次采集任务中动态解析当前页面引用的字体文件，实时构建映射关系。当然，为了减少重复计算，我们可以把解析结果缓存下来，以字体文件的URL或者文件内容的哈希值作为缓存key。如果下一次遇到的字体文件和缓存的某个一致，直接用缓存；否则重新解析并更新缓存。

这就要回到开头提到的“静态”二字了。我们说的静态不是指“固定不变”，而是指“不靠浏览器环境、只靠静态资源就能完成还原”。每一次拿到的页面和字体文件都是状态性的，但我们处理流程是静态的、确定性的，输入HTML和woff文件，输出明文文本。

3. 从零搭建Python解密工具链

3.1 准备开发环境与依赖库

这一部分我直接给出我实测下来最顺手的工具组合。项目基于Python 3.8+，如果你还在用Python 2.x，建议先升级，后面的很多库都已经不再兼容旧版本了。

需要用到的核心依赖有这些：

• requests：负责请求HTML页面和下载字体文件。虽然现在有很多异步HTTP客户端，但字体文件下载这种场景接口不多、频率不高，用同步的requests最直观、最容易排查问题。
• fontTools：字体解析的事实标准库，Python界的瑞士军刀。它能解析woff、woff2、ttf等格式，还可以直接读取cmap表、glyf表、CFF表等内部结构。
• numpy：做字形坐标数据的处理和相似度计算。处理大量坐标点的时候，用numpy的数组操作比纯Python循环快一个数量级。
• Pillow（可选）：如果后续想做基于图像像素的相似度比对，可以用它把字形渲染成图片。但作为主方案，我其实不太建议，只有在矢量比对遇到困难的时候才作为备选方案。

安装指令很简单：

pip install requests fonttools numpy Pillow

这里额外提醒一个坑：fontTools在处理woff2格式的时候，需要依赖brotli库。如果你下载下来的是woff2文件，直接解析可能会报ModuleNotFoundError: No module named 'brotli'，这时候只需要再执行一次pip install brotli就能解决。

3.2 字体文件下载与本地化

解密的第一步，是确定字体文件的下载地址。这个地址通常藏在HTML源码里，最常见的位置是<style>标签中的@font-face规则，形如：

@font-face { font-family: "PingFang SC"; src: url('//xx.pinduoduo.com/xxxxx/xxx.woff') format('woff'); }

有时候字体文件地址是绝对路径，有时候是协议相对路径（以//开头），需要自己拼上https:前缀。还有极少数情况，字体文件不是以@font-face引用的，而是通过JS动态注入的，这种情况下静态方案就会比较吃力，你需要在HTML或JS里找线索。但大多数场景下，直接在HTML源码的正则匹配里就能找到。

我写了一个专门用于提取字体文件URL的小工具函数：

import re import requests def extract_font_url(html_text): """ 从HTML文本中提取@font-face规则里的字体文件URL。 优先匹配woff/woff2格式。 """ # 匹配 @font-face 中的 src 属性里的 url(...) pattern = r"@font-face\s*\{[^}]*?src:\s*url\(['\"]?(.*?\.woff2?)['\"]?\)" matches = re.findall(pattern, html_text, re.S | re.I) if not matches: # 退而求其次，直接匹配所有字体文件后缀的URL pattern = r"url\(['\"]?(https?://[^'\"]+\.woff2?)['\"]?\)" matches = re.findall(pattern, html_text, re.I) for url in matches: if url.startswith('//'): url = 'https:' + url return url return None

拿到URL之后，下载就没什么好说的了。注意一点：下载字体文件时的请求头一定要带上Referer，目标页面URL或者站点根域名都行，否则有些环境会返回403。

def download_font(url, save_path, referer_url): headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Referer": referer_url, } resp = requests.get(url, headers=headers, timeout=10) resp.raise_for_status() with open(save_path, "wb") as fp: fp.write(resp.content) return save_path

3.3 解构woff文件：从码位到字形ID

下载好字体文件之后，我们先用fontTools把它读进来。这里要注意，fontTools对woff和woff2都做了封装，加载方式和ttf完全一样，不需要自己解压，非常省心。

from fontTools.ttLib import TTFont font = TTFont("encrypted.woff")

读进来之后，我们第一件事就是提取cmap表。需要注意的是，一个字体文件里可能有多个cmap子表，分别对应不同的平台和编码方式（Windows平台通常是Unicode BMP，也就是platformID=3, encodingID=1）。fontTools为我们提供了一个便捷的getBestCmap()方法，它会在多个子表中自动选择最适合的那一个。

cmap = font.getBestCmap()

得到cmap之后，它是一个字典，key是十进制形式的Unicode码点，value是对应的字形ID（glyph name）。举个例子：

# 假设解析出来长这样 # { 59303: "glyph00001", 59304: "glyph00002", ... } # 59303 就是十六进制的 0xE7A7

我们关心的是那些落在私有使用区的码位，也就是从 0xE000 到 0xF8FF 这一段（十进制是 57344 到 63871）。正常文字字符的码位不会出现在这个区间，所以如果看到字体文件里有大量私有区码位，基本可以确定这就是加密数字的藏身之处。

private_codepoints = { cp: glyph_name for cp, glyph_name in cmap.items() if 0xE000 <= cp <= 0xF8FF }

3.4 坐标提取与归一化

拿到了私有码位对应的字形ID之后，我们需要去glyf表里取每个字形的轮廓坐标数据。这里有一个很关键的分支：如果字体文件是TrueType格式（outline数据在glyf表），fontTools可以直接通过font["glyf"][glyph_name]取到坐标；但如果字体是PostScript格式（CFF表），坐标数据就不在glyf里，而是在CFF表里，处理起来要稍微绕一些。

拼多多用的字体文件，我目前遇到的基本都是TrueType格式，所以下面的代码以glyf表为主。

glyf_table = font["glyf"] def extract_glyph_coordinates(font, glyph_name): """ 提取一个字形所有的轮廓坐标点，返回一个numpy数组。 这里把每个轮廓的所有点都收集起来，不区分主轮廓和子轮廓， 因为在形状比对阶段，我们关注的是整体几何分布的相似度。 """ glyf = font["glyf"] if glyph_name not in glyf: return None glyph = glyf[glyph_name] if glyph.isComposite(): # 复合字形，暂时先展开处理，实际项目中遇到较少 coords = glyph.getCoordinates(glyf)[0] else: coords = glyph.coordinates points = [] if coords: coords_array = coords.array # coords_array 是 array.array 类型，转成numpy数组方便计算 import numpy as np pts = np.array(coords_array, dtype=np.float64).reshape(-1, 2) points.append(pts) return points

这里有个细节需要注意：原始坐标是字体设计空间里的坐标，单位是“font units”，不同字体的单位不一样，所以直接拿原始坐标比对是不科学的。我们需要做一次归一化，把所有坐标都映射到一个统一尺度上，比如整体平移到原点、缩放到边长为1的包围盒内。

def normalize_coordinates(point_set): """ 对一组坐标做平移到原点+缩放归一化。 point_set 是 (N, 2) 的numpy数组。 """ if point_set is None or len(point_set) == 0: return None arr = np.vstack(point_set) min_x, min_y = arr.min(axis=0) max_x, max_y = arr.max(axis=0) width = max_x - min_x height = max_y - min_y if width == 0 or height == 0: return None arr[:, 0] = (arr[:, 0] - min_x) / width arr[:, 1] = (arr[:, 1] - min_y) / height return arr

3.5 建立标准字形库与形状比对

现在我们已经把加密字体的每个私有码位对应的字形坐标提取出来了。下一步，就是要用一个“标准”字体作为参照物，把每个字形和0到9这10个数字做相似度比对。

标准字体的选择其实有讲究。最好的状态是选一个字形风格和目标字体相似的字体，比如拼多多网页正文用的字体，大概率是苹方或者微软雅黑这类的黑体风格。但实际操作中我们没法保证每一次都能选到100%匹配的字体。这时候怎么办？我实测下来比较有效的办法是：同时准备两到三套标准字体，比如“微软雅黑”、“苹方”、“Arial”，分别计算待识别字形和每套字体里数字字形的相似度，取最大相似度对应的数字作为最终识别结果。

字形相似度的计算，我推荐用“坐标点的最近邻匹配距离”来衡量。具体做法是：从加密字形的归一化坐标点集A中，随机采样固定数量（比如256个）的点；同样从标准数字字形的归一化坐标点集B中，也采样固定数量的点；然后对A中的每个点，找到B中欧氏距离最近的点，计算这些距离的均方根误差。误差越小，说明两个字形越相似。

from scipy.spatial import cKDTree def shape_similarity(points_a, points_b): """ 计算两组坐标点的形状相似度，返回均方根误差（越小越相似）。 points_a / points_b 都是 (N, 2) 的numpy数组。 """ if points_a is None or points_b is None: return float("inf") # 统一采样点数量，避免数量不同导致偏差 n_samples = min(256, len(points_a), len(points_b)) idx_a = np.random.choice(len(points_a), n_samples, replace=False) idx_b = np.random.choice(len(points_b), n_samples, replace=False) sample_a = points_a[idx_a] sample_b = points_b[idx_b] # 用KDTree做最近邻搜索 tree = cKDTree(sample_b) distances, _ = tree.query(sample_a) rms = np.sqrt(np.mean(np.square(distances))) return rms

有一个点必须提醒：最近邻距离方法的缺点是，如果字形本身的细节差异大，或者采样点落在轮廓内部的空洞区域，距离度量可能会失效。所以我实际上会在比对前先过滤掉一些“异常点”，比如离所有其他点都特别远的孤立点。当然，如果你对图像处理更熟悉，也可以用Pillow把字形渲染成二进制图片，再用IoU指标做相似度度量，那个思路也可以，只是性能会差一些。

形状比对整体流程如下：

def match_digit_from_glyph(font, glyph_name, standard_fonts): """ 给定一个字形名和标准字体列表，返回对应的数字（0-9）。 """ encrypted_pts = extract_glyph_coordinates(font, glyph_name) if encrypted_pts is None: return None norm_encrypted = normalize_coordinates(encrypted_pts) best_digit = None best_score = float("inf") for std_font, std_cmap in standard_fonts: for digit in range(10): # 找到标准字体中数字digit对应的字形 cp = ord(str(digit)) std_glyph_name = std_cmap.get(cp) if std_glyph_name is None: continue std_pts = extract_glyph_coordinates(std_font, std_glyph_name) norm_std = normalize_coordinates(std_pts) score = shape_similarity(norm_encrypted, norm_std) if score < best_score: best_score = score best_digit = digit return best_digit

4. 构建完整的解密流程与实操细节

4.1 主流程：从HTML到明文价格

前面把每个模块都拆开了，现在把它们串成一个完整的解密主流程。整个流程大概是这样的：

1. 请求目标页面，获取HTML源码；
2. 从HTML中提取字体文件URL；
3. 下载字体文件到本地临时目录；
4. 用fontTools解析字体文件，提取私有码位与字形坐标；
5. 加载标准字体库，逐个比对字形，得到“私有码位 -> 数字”的映射表；
6. 回到HTML源码，用映射表把所有的加密字符替换为明文；
7. 对替换后的HTML做进一步解析，提取价格等目标数据。

其中第6步是很多人容易忽略的细节。HTML里的加密字符，在源码中是以这种实体形式存在的，也就是&#x加上十六进制码位再加一个分号。我们解析出来的映射表key是十进制整数，所以替换时要先把实体转成码位再查表，或者反过来，先把映射表的key转成十六进制字符串再配合正则做替换。

我一般用下面这种方式做替换，一步到位：

import re def decode_encrypted_text(html_text, mapping): """ mapping: { 十进制码位: 明文数字字符 } html_text: 原始HTML文本 返回值：替换后的HTML文本 """ def _replace(match): hex_str = match.group(1) cp = int(hex_str, 16) return mapping.get(cp, match.group(0)) pattern = re.compile(r'&#x([0-9A-Fa-f]{4});') return pattern.sub(_replace, html_text)

注意这里的{4}表示匹配四位十六进制数。如果码位范围可能超过四位（比如到了BMP之外），可以改成{4,6}，但就我目前观察到的情况，拼多多的加密码位一般不会超出四位。

4.2 动态轮换与缓存策略

在前面我提到过，字体文件可能会定期轮换。如果每次请求都重新下载字体文件、重新比对字形，虽然准确率没问题，但效率比较低。尤其是当你需要批量采集大量商品数据的时候，字体下载和字形比对这两个环节会成为瓶颈。

我的做法是引入两层缓存：

第一层是内存缓存，以字体文件的URL作为key，解析结果映射表作为value，脚本运行期间复用；第二层是磁盘缓存，把映射表以JSON格式保存到本地，以字体文件内容的MD5作为文件名。这样下次运行脚本时，如果遇到同样的字体文件，直接读JSON，连下载都省了。

import hashlib import json import os def build_mapping_with_cache(font_url, font_bytes, standard_fonts, cache_dir="font_cache"): os.makedirs(cache_dir, exist_ok=True) md5 = hashlib.md5(font_bytes).hexdigest() cache_path = os.path.join(cache_dir, f"{md5}.json") if os.path.exists(cache_path): with open(cache_path, "r", encoding="utf-8") as fp: return json.load(fp) # 解析字体，构建映射表 mapping = parse_font_mapping(font_bytes, standard_fonts) with open(cache_path, "w", encoding="utf-8") as fp: json.dump(mapping, fp, ensure_ascii=False, indent=2) return mapping

这里parse_font_mapping就是我们前面写的字形比对逻辑的封装。我没有把完整的解析函数贴出来，因为它在不同环境下可能有细节差异，但是核心逻辑就是我们在3.5节里讲的那段。

4.3 数据提取：拿到明文之后的下一步

解密只是手段，拿数据才是目的。替换完HTML之后，页面里价格和销量已经是明文了。接下来的数据提取比较简单，直接用BeautifulSoup或者lxml解析即可。

from bs4 import BeautifulSoup def parse_prices(decoded_html): soup = BeautifulSoup(decoded_html, "lxml") results = [] for item in soup.select(".goods-item"): # 这里的选择器需要根据实际页面结构调整 title = item.select_one(".goods-name") price = item.select_one(".goods-price") if title and price: results.append({ "title": title.get_text(strip=True), "price": price.get_text(strip=True), }) return results

我没有把选择器写死，因为页面结构会有调整，实战中需要用开发者工具看一眼具体的class或者data属性。这个部分没什么高深的技术，纯粹是细心活。

4.4 模拟一次完整的解密过程

为了让大家对整体流程有一个直观的认知，我模拟一次完整的解密调用，把前面所有模块串起来。

def main(target_url): # 1. 请求页面 headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Accept-Language": "zh-CN,zh;q=0.9", } resp = requests.get(target_url, headers=headers, timeout=10) html_text = resp.text # 2. 提取字体文件URL font_url = extract_font_url(html_text) if not font_url: print("未找到字体文件URL，页面可能未启用字体加密") return # 3. 下载字体文件 font_data = requests.get(font_url, headers=headers, timeout=10).content # 4. 加载标准字体库 standard_fonts = load_standard_fonts(["msyh.ttc", "PingFang.ttf", "Arial.ttf"]) # 5. 构建映射表 mapping = build_mapping_with_cache(font_url, font_data, standard_fonts) # 6. 解密HTML decoded_html = decode_encrypted_text(html_text, mapping) # 7. 提取数据 products = parse_prices(decoded_html) for p in products: print(p)

实际运行这个流程，从请求页面到输出结构化数据，正常情况下在几百毫秒到几秒之间，瓶颈主要在字体下载和初次比对。如果命中磁盘缓存，速度会更快。

5. 常见问题与排查技巧实录

5.1 字形比对结果错误率高怎么办

我在调试过程中遇到最多的问题就是，部分数字识别错误，比如把“7”认成了“1”、把“5”认成了“6”。排查下来，原因主要集中在三个地方。

第一个原因，标准字体风格和加密字体风格差异过大。如果加密字体使用的是较粗的字体风格，而标准字体用的是细体，那么“1”和“7”这类字形差异不大的字符就很容易混淆。解决办法是增加标准字体库的覆盖范围，把不同字重、不同风格的标准字体都加进去，比对的时候取多个标准字体里分数最高（误差最小）的那个作为参考。

第二个原因，字形归一化方式不够鲁棒。当字形中有部分轮廓的点特别密集，而其他轮廓点特别稀疏的时候，平均采样策略会导致采样点集中在密集区域，形状相似度的判别力下降。解决办法是做等间隔采样，或者在采样前对坐标密度做一次均匀化处理。

第三个原因，坐标数据里混入了复合字形没有正确展开。有些字形是由多个子字形组合而成的（复合字形），直接用glyph.coordinates取坐标可能会拿到不完整的轮廓。这时候必须调用glyph.getCoordinates(glyf)来获取完整坐标，不能偷懒。

5.2 字体文件下载失败、返回403

这个问题常见于没有携带正确的请求头。除了User-Agent之外，很多服务端会校验Referer。如果你的下载脚本返回403，第一反应就补上Referer。另外，建议在请求之间加一个极短的随机延时（0.1到0.3秒），避免触发频率限制。

还有一个可能：字体文件URL是动态签名的，URL过了有效期就失效。这种情况下，你必须保证“下载字体文件”和“获取页面”的时间间隔足够短，最好在同一个会话中完成。我的做法是使用requests.Session()，保持会话中的Cookie和连接状态。

5.3 页面里没有@font-face规则

偶尔会碰到的场景：HTML源码里找不到@font-face规则，但页面上的数字依然是加密的。这种情况大概率是字体文件通过JS动态注入的。因为我们的方案是静态的，不做JS执行，所以碰到这种情况需要退回到“半静态”的策略：把JS文件也下载下来，从JS里找字体文件的URL模式。

我曾经遇到过一次，字体URL隐藏在JS代码的变量赋值语句中，通过正则从JS源码里把URL抠出来后，后续流程就和普通情况完全一致了。

5.4 问题速查表

6. 静态解密之外：工作流优化与合规边界

6.1 从单次解密到稳定服务

如果只是写一个脚本跑一两次，前面的内容已经足够。但在真实的数据采集场景里，解密只是一个环节，更重要的是把它稳定地嵌入到整个工作流中。

我的建议是，把解密模块抽成一个独立的服务，对外暴露一套简单的HTTP接口。采集脚本只需要把HTML文本和字体文件URL传给接口，接口返回解密后的明文文本。这样做的好处有三个：一是解密逻辑和采集逻辑解耦，一方变更不影响另一方；二是解密结果可以共享缓存，多个采集任务复用同一套映射表；三是便于后续切换到更复杂的解密策略，比如动态方案，而不用改动采集端的代码。

接口层实现起来不复杂，用Flask或者FastAPI都能轻松搞定。核心就是接收HTML，内部完成字体下载、映射构建、替换，最后返回明文HTML。需要注意的一点是，服务要做好并发控制，尤其是字体下载和字形比对这两类操作，如果并发放大，可能会给目标站点带来不必要的压力，需要限速。

6.2 关于合规，说几句实在话

聊到网页数据采集，无论如何都绕不开合规这个话题。我这里不想讲太多空泛的大道理，就说几点实际从业者心里有数但容易忽略的地方。

第一，公开数据的抓取和商业化的数据滥用，是完全不同的性质。如果你只是做个人研究、技术学习，或者在自己的产品里用到少量公开信息，那问题不大；但如果你要把抓到的数据规模化、商业化，一定要评估法律风险，最好请专业人士把关。

第二，本文提到的解密方案，核心在于“还原被字体替换的字符”。这种技术本身是中性的，它可以用来做数据采集，也可以用来做前端可访问性优化（比如帮助读屏工具识别被加密的文字）。所以我在文中尽可能把重点放在技术原理和工程实现上，希望大家也抱着技术研究的心态来阅读，而不是把它当作某个特定网站的攻击工具。

第三，不管做什么，都要尊重目标网站的robots协议、ets服务条款，设置合理的抓取频率，不要给对方服务器造成压力。技术上“能做到”和“应该去做”之间，永远有一条线，这条线只有自己能把控。