记某站字体混淆解析方案
因需,需定期抓取某网站数据进行分析。
近期该网站HTTP POST
获取的数据采用字体加密,以避免被简单的抓取。
具体而言,返回的关键数据被套上:#MI35nElclt_1721813502875otltag䓡䑱#FontTag
其中括号内#(MI35nElclt_1721813502875)otltag(䓡䑱)#FontTag
分别是字体文件名称和字体加密后的数据。
难点:
- 字体文件是动态的,无法“一次识别,一直使用”;
- 字体直接 OCR 识别,效率低、费用高、准确率低(存在生僻字)。
解决思路
分析字体文件后发现,所用字体文件中,字体并不多,仅 1k+个。
在综合采用 OCR 等思路后,最后得到基于 imagehash 的方案如下:
- OCR 识别:下载字体文件,采用
Windows
的PowerToys
对字体文件进行识别解析,并人工校正; - 建立字典:采用
footTools
和PIL
将ttf
字体文件中的每个字渲染为 64*64 的图片,并采用imagehash
计算其hash
值,并根据 OCR 识别结果,建立hash:char
字典; - 字体文件解析:每次抓取数据后,针对字体文件的每个字符,计算其
imagehash
,并从hash:char
字典中找到相似度最高的 char 作为对应字符,得到字体文件unicode:char
字典; - 数据解析:根据字体文件
unicode:char
字典,解析返回的数据。
核心代码
1 | import imagehash |
优劣分析
优势
- 可动态解析字体文件,无需畏惧网站动态改变字体文件所涵字体数量;
- 单个网站的多个页面,构建单个
hash:char
即可,后续若有新字体加入,适当追加即可; - 当字体存在细微修改,其所构建的
hash
计算相似度时依旧有效; - 相较于 OCR 方式,准确性更有保障;
劣势
- 由于每次需要解析整个字体文件,耗时略长(
1k字符/5s
),不过在可接受范围; - 当网站更新字体时,可能无法继续工作;
参考
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 遐说!
评论