Comicbook 开发记录
目前开发大致经历了三个阶段：
- 爬虫核心
- Web Server
- 多线程
Comicbook 的核心爬虫运行流程是：
-> parser url
-> one of spiders
-> fetch comic info and origin comic image urls
-> epub generator
-> download all images and write into epub file
爬虫核心
爬虫核心部分的代码写进了一个 Crawler 类，调用方法 def crawl(cls, url, callback): 来获取漫画基本信息和图片链接。爬虫核心代码借鉴了 Scrapy 的一些设计思想，沿用了 Scrapy 的爬取流程 URL -> Spiders -> Pipelines -> Done。
Spiders
目前只针对同人漫画进行爬取作业，所以最终需要获取的信息都是一致，可以约定每个 spider 有一个函数接受特定参数，返回特定结果，这样，如果有其他的人扩展更多网站爬取功能就方便了。这里每个 Spider 类并没有像 Scrapy 那样，先提供一个基类，然后强制继承类，是因为这里并不是写的一个框架，所以没有比较弄得这么正式。只要输入输出能对接就行。
Web Server
使用 flask 这个 Python 的轻量网页服务器框架，没有太多好说的。
现改用 flask-socketio 来获取文件生成进度。
from flask import Flask
from flask_socketio import SocketIO
app = Flask(__name__)
socketio = SocketIO(app)
# ...
@socketio.on('check-status')
def handle_json(json):
# ...
这样就不必再像以前那样轮询发送传统 GET/POST 请求了。
多线程
因为最终做成了在线网页的形式，那么考虑到多人同时使用的情况，需要多线程来同时运行多个爬虫。
Scrapy
Scrapy 算是一套比较完善的一般性爬虫方案。
Scrapy 有一套几乎通用的处理流程，这套流程是被定死了的。基本流程 Spiders -> Spider Middleware -> Pipelines -> Download Middleware，我不想具体的讲 Scrapy 的原理实现，网络上一搜索一大堆的这类信息。
想要讲的是我在 Comicbook 这个项目中尝试了很久，为何最后还是放弃使用了这套框架。
Scrapy 有预置的一个图片爬虫类，甚至还已经写好了图片存储的相关代码。但是我在开发 Comicbook 的时候，想的是每下载一张漫画图片，就直接写入到 epub 文件（实际上就是一个 zip）里面。而 如果使用 Scrapy 会先将图片存在磁盘里，再生成 epub 的时候将存储的图片写入 epub，这样，在这套流程未结束之前，会占用双倍的磁盘空间。
Telegram Bot
因为自己日常使用 Telegram，前段时间又正好特别想写代码，于是就做了一个简陋的 bot 出来。为了快速开发，直接使用了 python-telegram-bot 框架。在做这个 bot 的过程中，顺便修改了一下代码的结构，以求方便同时为 web 和 bot 两个前端提供接口。
Comicbook Bot[1] 使用方法：
/comic <nhentai/e-hentai/wnacg url>
（未完成）