Comicbook 开发记录

Comicbook Mar 4, 2017

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

  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 ↩︎

Tags

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.