自动将字体文件(woff\woff2\ttf)映射为结果字典,主要用于中文字体反爬虫的破解,包括css字体映射和图片文字反爬虫.

具体的思路见如下几篇

• 字体反爬虫解决方案-自动化通过字体文件生成映射字典
• Poirot开发记录(1) -- 基于websocket的进度条实现方案
• Poirot 开发记录(2) - 字体抽取和OCR的优化方案

DEMO ps. DEMO的版本为 最初的fontforge版本

• 升级为多线程
• 添加本地的文字识别
• 使用socketio优化使用体验
• 添加进度条优化使用体验
• 扩展文字识别途径(腾讯)
• 扩展文字识别途径(百度)
• 对空白图片添加过滤
• 解除fontforge的依赖
• 简化本地OCR
• 添加测试项

• 部署样例网站
• Docker
• 使用Redis管理api访问次数
• 解决socket通信混乱的问题

windows 无法直接使用 flask run 启动,这会导致功能的缺失.
在mac或者linux下，可以在安装了 requirements.txt 中的依赖和 fontforge 之后使用 flask run 启动. docker 启动则没有这些烦恼, 真正意义上的傻瓜式使用.

在1.x之后的版本中,解除了对fontforge的依赖,所以能够直接在windows上面使用了😀

poetry install --no-dev

flask run

pip install -r requirements.txt

flask run

之后访问 "http://127.0.0.1:5000" 即可使用

1. 可以直接使用docker启动

docker build . -t poirot
docker run -d poirot

ps. 国内使用可以先修改 Dockerfile 中的注释加快构建速度

2. 如果按照 docker-compose.yml 启动，需要创建在宿主机对应的文件夹

• /logs/gunicorn/poirot 存放日志
• /root/data/poirot/font_collection 存放分析文件

mkdir -p /logs/gunicorn/poirot && mkdir -p /root/data/poirot/font_collection
docker up

测试用的文件见 ./static/test_files

提供web和api两类服务.

web: 如DEMO所示,发送字体文件到后端,解析完毕之后返回序列化结果到前端,再由前端序列化为json字符串 . 后端识别的结果会有误差，这个误差可以通过前端的人工校验抹除。

api: 出于功能拓展和使用方式多样化的角度考虑,在开发伊始特意将部分功能设计为api的形式. 目前总共有3个.

• 普通字体文件识别(/api/font_file_cracker): 并不推荐直接使用api, 中文文字识别的成功率只在 70%~80% , 需要配合人工审核, 所以对于中文, 建议使用web服务
• 数字特化(/api/special_for_printed_digits/): 与中文识别不同，数字的识别率在使用 自训练的模型(./models/clf_model) 之后能够无限接近100% (至少目前没有遇到识别错误的案例)
• 单张图片识别(/api/img_cracker_via_local_ocr/): 针对单张图片进行识别, 这是开发过程中的副产物, 可以用于进行一些验证

默认情况下，使用本地破解为主，第三方OCR服务为辅的破解方案.

本地OCR基于chineseocr_lite.

1. 将 config.py 中 use_baidu_ocr 的值改为 True.

2. 创建 secure.py 文件,文件中需要有一个 access_token 变量,其中存放百度OCR的token。

待开发

由于使用了 TTFont 依赖包来处理字体文件，而 TTFont 不提供文件数据流的加载方式，所以默认会将文件保存在本地。

另外保存在本地的另一个原因就是让 OCR 失败的时候能够方便地寻找到失败的原因。

不过在大规模爬取的时候，保存文件是一个很占用存储空间的事情，所以重写了 TTFont 中读取文件的逻辑，保存在 myFony.py 中， 需要使用的可以用这个类去改写原来的服务。