拓冰网站定制 
1. 解密思路与项目背景1.1 我们先搞清楚拼多多前端到底做了什么现在的电商网页反爬早就不是简单地去识别UA、加个验证码这么基础了。拼多多的PC端网页在商品详情页、搜索结果页这些带着价格和销量信息的关键位置用了一套很有意思的字体加密方案。你打开浏览器开发者工具看到DOM里的价格是一个长得像乱码的实体编码但是页面上渲染出来却是正常的数字。那会儿我第一次扒它的HTML时还以为是页面加载了JS动态渲染后来追了一下请求才发现——问题出在字体文件上。具体点说拼多多网页会在运行时动态加载一个woff格式的字体文件这个字体文件里定义了一套自定义映射关系把阿拉伯数字0到9以及小数点、可能还有加号、减号、百分之这种符号重新映射成了一个私有的Unicode码位。浏览器拿到HTML之后再配合这个字体文件渲染于是普通用户肉眼看到的是一个正常的价格比如199.90元但是你在HTML源码里看到的是类似#xea17;这种鬼东西。这里有一个很关键的方向就是我们后面整个项目的主心骨字体加密的实现原理本质上不是“加密”而是“替换”——换了一套编码映射规则。既然是替换那就意味着信息没有丢失它只是被“翻译”成了另一种形式。只要我们能拿到那套字体文件把映射关系还原出来我们就能把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字体文件的内部结构搞清楚。这个知识点是整个项目的基石不然后面写代码就是在抄模板遇到问题根本不知道怎么排查。woffWeb Open Font Format本质上是一个容器格式它里面包着的是TrueType或者OpenType字体数据。而TrueType字体文件里有几个表Table特别关键其中对我们解密最有价值的是cmap表和glyf表。cmap表的中文名叫“字符到字形映射表”它的作用是把一个字符编码也就是我们平时说的Unicode码点映射到一个字形IDglyph ID。举个例子假设在标准的字体文件里字符“1”的Unicode码点是U0031它在cmap表里会被映射到某一个glyph ID而在加密的字体文件里同一个视觉上的“1”可能被塞到了一个私有区段的码位上比如UEA17这个码位也会在cmap表里映射到某个glyph ID。glyf表存储的是真实的字形轮廓数据也就是每个字形长什么样——每个轮廓的坐标点、曲线的控制点、路径的填充方式等等。字形ID通过cmap表的映射定位到glyf表里的具体记录进而告诉渲染引擎“这个字符该画成什么形状”。到这里解密思路实际上就出来了。正常情况下我们会有一个“标准数字字体”比如系统自带的Arial它里面的字符编码和字形是一对一的、有序的。比如0到9这十个数字它们的码位是连续的U0030到U0039字形也是一个递增的序列。而在加密字体里码位虽然变了但是——字形轮廓本身没有变。数字“1”就是“1”不管它被映射到哪个码位它的字形坐标数据在几何形状上和标准字体里的“1”是相同的。所以我们的解密算法核心可以归结为一个“找相似”的过程解析加密字体文件提取出每个码位对应的字形轮廓再拿这些轮廓和我们手头的一套标准数字字形做形状相似度比对比对上了就反推出“加密码位UEA17对应的其实是数字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 rfont-face\s*\{[^}]*?src:\s*url\([\]?(.*?\.woff2?)[\]?\) matches re.findall(pattern, html_text, re.S | re.I) if not matches: # 退而求其次直接匹配所有字体文件后缀的URL pattern rurl\([\]?(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, headersheaders, timeout10) resp.raise_for_status() with open(save_path, wb) as fp: fp.write(resp.content) return save_path3.3 解构woff文件从码位到字形ID下载好字体文件之后我们先用fontTools把它读进来。这里要注意fontTools对woff和woff2都做了封装加载方式和ttf完全一样不需要自己解压非常省心。from fontTools.ttLib import TTFont font TTFont(encrypted.woff)读进来之后我们第一件事就是提取cmap表。需要注意的是一个字体文件里可能有多个cmap子表分别对应不同的平台和编码方式Windows平台通常是Unicode BMP也就是platformID3, encodingID1。fontTools为我们提供了一个便捷的getBestCmap()方法它会在多个子表中自动选择最适合的那一个。cmap font.getBestCmap()得到cmap之后它是一个字典key是十进制形式的Unicode码点value是对应的字形IDglyph 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, dtypenp.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(axis0) max_x, max_y arr.max(axis0) 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 arr3.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, replaceFalse) idx_b np.random.choice(len(points_b), n_samples, replaceFalse) 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_digit4. 构建完整的解密流程与实操细节4.1 主流程从HTML到明文价格前面把每个模块都拆开了现在把它们串成一个完整的解密主流程。整个流程大概是这样的请求目标页面获取HTML源码从HTML中提取字体文件URL下载字体文件到本地临时目录用fontTools解析字体文件提取私有码位与字形坐标加载标准字体库逐个比对字形得到“私有码位 - 数字”的映射表回到HTML源码用映射表把所有的加密字符替换为明文对替换后的HTML做进一步解析提取价格等目标数据。其中第6步是很多人容易忽略的细节。HTML里的加密字符在源码中是以#xE7A7;这种实体形式存在的也就是#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_dirfont_cache): os.makedirs(cache_dir, exist_okTrue) 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, encodingutf-8) as fp: return json.load(fp) # 解析字体构建映射表 mapping parse_font_mapping(font_bytes, standard_fonts) with open(cache_path, w, encodingutf-8) as fp: json.dump(mapping, fp, ensure_asciiFalse, indent2) 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(stripTrue), price: price.get_text(stripTrue), }) 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;q0.9, } resp requests.get(target_url, headersheaders, timeout10) 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, headersheaders, timeout10).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 问题速查表现象原因解决方案字体文件下载返回403缺少Referer或UA补全请求头保持会话fontTools解析woff报错缺少brotli库pip install brotli识别结果“7”与“1”混淆标准字体风格不匹配增加标准字体库的样式覆盖HTML替换后仍有乱码码位超出4位或实体格式异常调整正则表达式兼容5位十六进制私有码位提取为空字体加密可能用了CFF表检查字体表类型改用CFF解析同一页面价格同一码位对应不同数字页面使用了多套字体遍历所有font-face规则建立多张映射表6. 静态解密之外工作流优化与合规边界6.1 从单次解密到稳定服务如果只是写一个脚本跑一两次前面的内容已经足够。但在真实的数据采集场景里解密只是一个环节更重要的是把它稳定地嵌入到整个工作流中。我的建议是把解密模块抽成一个独立的服务对外暴露一套简单的HTTP接口。采集脚本只需要把HTML文本和字体文件URL传给接口接口返回解密后的明文文本。这样做的好处有三个一是解密逻辑和采集逻辑解耦一方变更不影响另一方二是解密结果可以共享缓存多个采集任务复用同一套映射表三是便于后续切换到更复杂的解密策略比如动态方案而不用改动采集端的代码。接口层实现起来不复杂用Flask或者FastAPI都能轻松搞定。核心就是接收HTML内部完成字体下载、映射构建、替换最后返回明文HTML。需要注意的一点是服务要做好并发控制尤其是字体下载和字形比对这两类操作如果并发放大可能会给目标站点带来不必要的压力需要限速。6.2 关于合规说几句实在话聊到网页数据采集无论如何都绕不开合规这个话题。我这里不想讲太多空泛的大道理就说几点实际从业者心里有数但容易忽略的地方。第一公开数据的抓取和商业化的数据滥用是完全不同的性质。如果你只是做个人研究、技术学习或者在自己的产品里用到少量公开信息那问题不大但如果你要把抓到的数据规模化、商业化一定要评估法律风险最好请专业人士把关。第二本文提到的解密方案核心在于“还原被字体替换的字符”。这种技术本身是中性的它可以用来做数据采集也可以用来做前端可访问性优化比如帮助读屏工具识别被加密的文字。所以我在文中尽可能把重点放在技术原理和工程实现上希望大家也抱着技术研究的心态来阅读而不是把它当作某个特定网站的攻击工具。第三不管做什么都要尊重目标网站的robots协议、ets服务条款设置合理的抓取频率不要给对方服务器造成压力。技术上“能做到”和“应该去做”之间永远有一条线这条线只有自己能把控。 拼多多字体加密逆向：Python静态解密方案详解
1. 解密思路与项目背景1.1 我们先搞清楚拼多多前端到底做了什么现在的电商网页反爬早就不是简单地去识别UA、加个验证码这么基础了。拼多多的PC端网页在商品详情页、搜索结果页这些带着价格和销量信息的关键位置用了一套很有意思的字体加密方案。你打开浏览器开发者工具看到DOM里的价格是一个长得像乱码的实体编码但是页面上渲染出来却是正常的数字。那会儿我第一次扒它的HTML时还以为是页面加载了JS动态渲染后来追了一下请求才发现——问题出在字体文件上。具体点说拼多多网页会在运行时动态加载一个woff格式的字体文件这个字体文件里定义了一套自定义映射关系把阿拉伯数字0到9以及小数点、可能还有加号、减号、百分之这种符号重新映射成了一个私有的Unicode码位。浏览器拿到HTML之后再配合这个字体文件渲染于是普通用户肉眼看到的是一个正常的价格比如199.90元但是你在HTML源码里看到的是类似#xea17;这种鬼东西。这里有一个很关键的方向就是我们后面整个项目的主心骨字体加密的实现原理本质上不是“加密”而是“替换”——换了一套编码映射规则。既然是替换那就意味着信息没有丢失它只是被“翻译”成了另一种形式。只要我们能拿到那套字体文件把映射关系还原出来我们就能把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字体文件的内部结构搞清楚。这个知识点是整个项目的基石不然后面写代码就是在抄模板遇到问题根本不知道怎么排查。woffWeb Open Font Format本质上是一个容器格式它里面包着的是TrueType或者OpenType字体数据。而TrueType字体文件里有几个表Table特别关键其中对我们解密最有价值的是cmap表和glyf表。cmap表的中文名叫“字符到字形映射表”它的作用是把一个字符编码也就是我们平时说的Unicode码点映射到一个字形IDglyph ID。举个例子假设在标准的字体文件里字符“1”的Unicode码点是U0031它在cmap表里会被映射到某一个glyph ID而在加密的字体文件里同一个视觉上的“1”可能被塞到了一个私有区段的码位上比如UEA17这个码位也会在cmap表里映射到某个glyph ID。glyf表存储的是真实的字形轮廓数据也就是每个字形长什么样——每个轮廓的坐标点、曲线的控制点、路径的填充方式等等。字形ID通过cmap表的映射定位到glyf表里的具体记录进而告诉渲染引擎“这个字符该画成什么形状”。到这里解密思路实际上就出来了。正常情况下我们会有一个“标准数字字体”比如系统自带的Arial它里面的字符编码和字形是一对一的、有序的。比如0到9这十个数字它们的码位是连续的U0030到U0039字形也是一个递增的序列。而在加密字体里码位虽然变了但是——字形轮廓本身没有变。数字“1”就是“1”不管它被映射到哪个码位它的字形坐标数据在几何形状上和标准字体里的“1”是相同的。所以我们的解密算法核心可以归结为一个“找相似”的过程解析加密字体文件提取出每个码位对应的字形轮廓再拿这些轮廓和我们手头的一套标准数字字形做形状相似度比对比对上了就反推出“加密码位UEA17对应的其实是数字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 rfont-face\s*\{[^}]*?src:\s*url\([\]?(.*?\.woff2?)[\]?\) matches re.findall(pattern, html_text, re.S | re.I) if not matches: # 退而求其次直接匹配所有字体文件后缀的URL pattern rurl\([\]?(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, headersheaders, timeout10) resp.raise_for_status() with open(save_path, wb) as fp: fp.write(resp.content) return save_path3.3 解构woff文件从码位到字形ID下载好字体文件之后我们先用fontTools把它读进来。这里要注意fontTools对woff和woff2都做了封装加载方式和ttf完全一样不需要自己解压非常省心。from fontTools.ttLib import TTFont font TTFont(encrypted.woff)读进来之后我们第一件事就是提取cmap表。需要注意的是一个字体文件里可能有多个cmap子表分别对应不同的平台和编码方式Windows平台通常是Unicode BMP也就是platformID3, encodingID1。fontTools为我们提供了一个便捷的getBestCmap()方法它会在多个子表中自动选择最适合的那一个。cmap font.getBestCmap()得到cmap之后它是一个字典key是十进制形式的Unicode码点value是对应的字形IDglyph 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, dtypenp.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(axis0) max_x, max_y arr.max(axis0) 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 arr3.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, replaceFalse) idx_b np.random.choice(len(points_b), n_samples, replaceFalse) 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_digit4. 构建完整的解密流程与实操细节4.1 主流程从HTML到明文价格前面把每个模块都拆开了现在把它们串成一个完整的解密主流程。整个流程大概是这样的请求目标页面获取HTML源码从HTML中提取字体文件URL下载字体文件到本地临时目录用fontTools解析字体文件提取私有码位与字形坐标加载标准字体库逐个比对字形得到“私有码位 - 数字”的映射表回到HTML源码用映射表把所有的加密字符替换为明文对替换后的HTML做进一步解析提取价格等目标数据。其中第6步是很多人容易忽略的细节。HTML里的加密字符在源码中是以#xE7A7;这种实体形式存在的也就是#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_dirfont_cache): os.makedirs(cache_dir, exist_okTrue) 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, encodingutf-8) as fp: return json.load(fp) # 解析字体构建映射表 mapping parse_font_mapping(font_bytes, standard_fonts) with open(cache_path, w, encodingutf-8) as fp: json.dump(mapping, fp, ensure_asciiFalse, indent2) 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(stripTrue), price: price.get_text(stripTrue), }) 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;q0.9, } resp requests.get(target_url, headersheaders, timeout10) 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, headersheaders, timeout10).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 问题速查表现象原因解决方案字体文件下载返回403缺少Referer或UA补全请求头保持会话fontTools解析woff报错缺少brotli库pip install brotli识别结果“7”与“1”混淆标准字体风格不匹配增加标准字体库的样式覆盖HTML替换后仍有乱码码位超出4位或实体格式异常调整正则表达式兼容5位十六进制私有码位提取为空字体加密可能用了CFF表检查字体表类型改用CFF解析同一页面价格同一码位对应不同数字页面使用了多套字体遍历所有font-face规则建立多张映射表6. 静态解密之外工作流优化与合规边界6.1 从单次解密到稳定服务如果只是写一个脚本跑一两次前面的内容已经足够。但在真实的数据采集场景里解密只是一个环节更重要的是把它稳定地嵌入到整个工作流中。我的建议是把解密模块抽成一个独立的服务对外暴露一套简单的HTTP接口。采集脚本只需要把HTML文本和字体文件URL传给接口接口返回解密后的明文文本。这样做的好处有三个一是解密逻辑和采集逻辑解耦一方变更不影响另一方二是解密结果可以共享缓存多个采集任务复用同一套映射表三是便于后续切换到更复杂的解密策略比如动态方案而不用改动采集端的代码。接口层实现起来不复杂用Flask或者FastAPI都能轻松搞定。核心就是接收HTML内部完成字体下载、映射构建、替换最后返回明文HTML。需要注意的一点是服务要做好并发控制尤其是字体下载和字形比对这两类操作如果并发放大可能会给目标站点带来不必要的压力需要限速。6.2 关于合规说几句实在话聊到网页数据采集无论如何都绕不开合规这个话题。我这里不想讲太多空泛的大道理就说几点实际从业者心里有数但容易忽略的地方。第一公开数据的抓取和商业化的数据滥用是完全不同的性质。如果你只是做个人研究、技术学习或者在自己的产品里用到少量公开信息那问题不大但如果你要把抓到的数据规模化、商业化一定要评估法律风险最好请专业人士把关。第二本文提到的解密方案核心在于“还原被字体替换的字符”。这种技术本身是中性的它可以用来做数据采集也可以用来做前端可访问性优化比如帮助读屏工具识别被加密的文字。所以我在文中尽可能把重点放在技术原理和工程实现上希望大家也抱着技术研究的心态来阅读而不是把它当作某个特定网站的攻击工具。第三不管做什么都要尊重目标网站的robots协议、ets服务条款设置合理的抓取频率不要给对方服务器造成压力。技术上“能做到”和“应该去做”之间永远有一条线这条线只有自己能把控。