Comicbook 开发记录

目前开发大致经历了三个阶段:

  1. 爬虫核心
  2. Web Server
  3. 多线程

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>

(未完成)


  1. http://t.me/moeoverflow_comic_bot ↩︎