Python漫画爬虫实战：接口解析、并发下载与zip打包全攻略

简介：这是一套基于Java开发的漫画网站数据采集工具，面向有一定Java基础的开发者或数据采集初学者，用于学习网页爬虫原理与实战开发。资源聚焦拷贝漫画（copymanga）站点，涵盖URL调度、HTTP请求、HTML解析、数据持久化等完整爬虫流程实现，可辅助理解反爬应对、robots协议遵守等工程实践要点。压缩包共57个文件，含22个编译后class文件、20个核心Java源码（如SpiderMain、PageParser等）、7个XML配置文件（含Maven依赖与Spring Bean定义），以及README说明、IDE配置和构建相关文件，整体仅61KB，轻量易读。目前已有410人学习下载，代码结构清晰，模块职责分明，附带完整项目配置与可运行入口，适合直接导入IDE调试学习，是理解Java Web爬虫从设计到落地的典型教学级案例。 花了一晚上写了个漫画爬虫工具，把整部漫画批量下载打包成zip压缩包。趁热把整个实现思路和踩坑过程整理出来，给需要的人参考。

1. 为什么漫画站的爬虫比普通网站难写

先说结论：漫画站的爬虫难度不在“爬”本身，而在“还原阅读体验”。普通新闻爬虫抓到正文文字就算完事，漫画爬虫要处理的是图片流。一部漫画动辄几百话，每话几十张图，你要把这一层一层的数据结构理顺——站点下面是漫画，漫画下面是章节，章节下面是图片，图片还得按顺序拼接才能看。

我最早接触这个需求是被一个朋友问的，他说想把自己追的一部小众漫画存到本地，方便通勤路上离线看。我一开始以为这事很简单，requests请求一下HTML，正则抽几个图片链接就完事。真正动手才发现，现在正规一点的漫画平台基本都不做纯服务端渲染了，页面框架是JS动态加载的，直接拿requests拿不到任何章节数据。

如果你也是第一次写漫画爬虫，建议先建立一个认知：漫画平台的数据层级通常是四层结构，任何一层没打通，后面全白搭。

漫画站首页 -> 漫画详情页 -> 章节列表 -> 章节内图片序列

后面所有的代码逻辑，本质上都是围绕这四层展开的。你的爬虫能不能稳定跑完一整部漫画，取决于每一层的数据解析是否可靠。

另外一个容易被忽视的问题是存储组织。图片下载下来不是终点，你要让用户能离线看，必须打包成zip或者pdf。zip格式通用性强，手机电脑都能直接解压看，所以我最终选了zip。

2. 动手前先摸清目标站的请求协议

写爬虫最忌讳上来就写代码。先花半小时搞清楚目标站的前端是怎么请求数据的，后面能省半天调试时间。

2.1 用开发者工具看请求，而不是看页面源码

打开目标漫画站的某个漫画详情页，按F12进入开发者工具，切到Network面板，刷新页面，过滤XHR请求。这个时候你会看到页面在加载过程中发起的所有Ajax请求。

核心要关注的是三类接口：

• 详情页接口：返回漫画名称、封面、简介等元信息
• 章节列表接口：返回该漫画的所有章节ID和章节名称
• 图片列表接口：返回某一章节内所有图片的URL列表

如果你在XHR请求里找不到明显的图片列表接口，大概率是用了JS加密或混淆，这时候就需要分析JS逻辑了。但绝大多数站点，图片列表接口都是明文的，只是接口路径有一定的规则。

2.2 requests模拟请求的三个关键头

拿到接口后，先用requests试着请求一下。只带一个普通User-Agent就请求，往往会被拦下来。我实际测试下来，有三个请求头基本是必须的：

有些平台的接口会校验Referer是否来自本站域名，请求头里没有Referer，接口直接返回{"code": -1}之类的错误。这个坑非常隐蔽，因为单独看文档根本不会有人提醒你。

Cookie的问题更麻烦。如果你要爬的漫画需要登录才能看，那第一步就得先用浏览器登录一次，然后把浏览器Cookie复制到爬虫的请求头里。Cookie获取方式：浏览器开发者工具 -> Network -> 随便点一个请求 -> Request Headers -> 复制Cookie整段字符串。

2.3 接口返回的数据结构要留个心眼

我遇到的情况是，章节列表接口返回的是一个JSON数组，每个元素包含chapter_id、chapter_title、chapter_order三个字段。图片列表接口返回的是一个JSON对象，里面是一个URL数组。

注意一个细节：很多平台的JSON返回是经过一层封装的，比如{"code":0, "data": {...}}这种格式。要解析数据，必须先定位到data字段，不要直接去顶层取数据，否则会拿到一堆空值。

还要留意接口返回的图片URL有时是相对路径，需要拼接域名；有时是webp格式，需要转换成jpg，这些都会影响最终打包效果。实际写代码的时候，建议加一个统一的URL标准化处理逻辑。

3. 核心实现：一个可复用的漫画爬虫骨架

搞清楚请求协议之后，写代码就顺理成章了。我把核心逻辑分成三块：目录解析、图片下载、打包输出。下面用Python + requests + BeautifulSoup实现一套完整的骨架，你可以根据自己的目标站替换选择器。

3.1 目录解析与章节遍历

第一步是从漫画详情页拿到所有章节信息。这里有一个经验：不要在前端页面里找章节列表，而是去找章节列表接口。页面HTML里渲染的章节列表通常被截断（尤其是几百话的长篇漫画），接口返回才是全量。

import requests from bs4 import BeautifulSoup import json HEADERS = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", "Referer": "https://example.com/" } def get_chapters(comic_url): resp = requests.get(comic_url, headers=HEADERS, timeout=10) resp.raise_for_status() # 假设章节列表在接口 /api/chapters 中，把 comic_id 拼上去 comic_id = extract_comic_id(comic_url) api_url = f"https://api.example.com/api/chapters?comic_id={comic_id}" data = requests.get(api_url, headers=HEADERS, timeout=10).json() chapters = [] for item in data["data"]["list"]: chapters.append({ "id": item["chapter_id"], "title": item["chapter_title"], "order": item["chapter_order"] }) # 按章节顺序排序 chapters.sort(key=lambda x: x["order"]) return chapters

注意我加了timeout=10，这是必须的。网络请求不可控，不设置超时会导致爬虫卡死在一个请求上，整个任务都要重启。

3.2 图片链接提取与并发下载

拿到章节ID后，请求图片列表接口，得到该章节所有图片的URL。下载图片时建议用线程池做并发，但并发数别太大。我实测ThreadPoolExecutor(max_workers=4)最稳妥，再高会被站点限流。

from concurrent.futures import ThreadPoolExecutor def download_chapter_images(chapter, save_dir): api_url = f"https://api.example.com/api/images?chapter_id={chapter['id']}" data = requests.get(api_url, headers=HEADERS, timeout=10).json() img_urls = data["data"]["images"] img_objs = [] for idx, url in enumerate(img_urls): img_objs.append({ "url": normalize_url(url), "path": f"{idx+1:03d}.jpg" }) def fetch_one(img_obj): path = f"{save_dir}/{img_obj['path']}" for retry in range(3): try: r = requests.get(img_obj["url"], headers=HEADERS, timeout=15) if r.status_code == 200: with open(path, "wb") as f: f.write(r.content) return True except Exception: continue return False with ThreadPoolExecutor(max_workers=4) as executor: results = list(executor.map(fetch_one, img_objs)) failed = sum(1 for r in results if not r) return failed

文件名用001.jpg、002.jpg这种零填充的格式，是为了保证解压后按文件名排序就是正确的阅读顺序。这是很多新手容易忽略的细节，如果文件名是1.jpg、2.jpg、10.jpg，排序结果会是1、10、2，阅读顺序直接乱掉。

重试机制也要做。图片下载过程中网络抖动很正常，一次失败就放弃会导致缺图。我写了3次重试，每次重试间隔1秒，实测能把失败率降到几乎为零。

3.3 汇总为zip包的组织逻辑

单章下载完成后，把目录下所有图片压缩成zip格式。Python自带的zipfile模块就能搞定，不用装第三方库。

import zipfile import os def pack_chapter_to_zip(chapter_dir, zip_path): with zipfile.ZipFile(zip_path, "w", zipfile.ZIP_STORED) as zf: for root, _, files in os.walk(chapter_dir): for file in sorted(files): if file.endswith(".jpg"): file_path = os.path.join(root, file) arcname = f"{chapter_title}/{file}" zf.write(file_path, arcname)

压缩格式建议用ZIP_STORED而不是ZIP_DEFLATED。原因很实在：图片本身就是压缩过的格式，再用DEFLATE压缩一遍体积基本不会变小，反而会拖慢压缩速度。用STORED模式是直接存储，速度快，文件也不会变大。

4. 打包和下载环节最容易翻车的几个坑

工具写完不是结束，能跑通才是开始。我在实际使用过程中，遇到过好几个让人抓狂的坑。这里单独列一节，希望你别再踩一遍。

4.1 下载了一半，zip却说“file is not a zip file”

第一次完整跑完工具后，我满心欢喜地解压看效果。结果Windows资源管理器直接弹窗：file is not a zip file。

排查了半天，最后发现问题出在下载过程被中断过。下载脚本跑到一半断网了，我直接重新跑了一遍，但脚本的逻辑是“覆盖写文件”，之前的下载记录全丢了。中途断掉的任务，最终产出了一个残缺的zip包，文件头还在但文件尾不完整，解压工具自然不认。

解决思路有两个：

• 断点续传：每张图片下载后记录状态，下次启动时跳过已下载的文件
• 完整性校验：打包前检查图片数量和字节大小是否与预期一致

简单实现断点续传其实不难，就是下载前先看一眼本地文件是否存在且大小不为0：

def fetch_one_with_skip(img_obj): path = f"{save_dir}/{img_obj['path']}" if os.path.exists(path) and os.path.getsize(path) > 0: return True for retry in range(3): try: r = requests.get(img_obj["url"], headers=HEADERS, timeout=15) if r.status_code == 200: with open(path, "wb") as f: f.write(r.content) return True except Exception: time.sleep(1) return False

这样即使中途断了，重启脚本也会从失败的地方继续，而不是从头再来。

4.2 zip -ff 是修复命令，但治标不治本

Linux用户可能听说过zip -FF damaged.zip --out repaired.zip可以用来修复zip文件。这个命令在某些场景下确实能救回部分数据，但它不是银弹。

-ff的完整逻辑是“通过文件头信息重建目录结构”，如果文件尾部损坏不严重，还有救；如果文件头部本身就损坏了，基本无解。我在踩了file is not a zip file的坑之后试过用zip -ff修复，效果一般，还是重写代码做断点续传更靠谱。

建议把精力花在防止文件损坏上，而不是事后修复。

4.3 中文文件名乱码与编码问题

漫画章节名是中文，打包成zip后，在Windows上解压可能会出现乱码。原因是zipfile模块默认用UTF-8写文件名，但老版本Windows解压工具默认按GBK解码。

解决方法是设置压缩包标志位，强制使用UTF-8：

def pack_chapter_to_zip(chapter_dir, zip_path, chapter_title): with zipfile.ZipFile(zip_path, "w", zipfile.ZIP_STORED) as zf: for root, _, files in os.walk(chapter_dir): for file in sorted(files): if file.endswith(".jpg"): file_path = os.path.join(root, file) arcname = f"{chapter_title}/{file}" # 强制UTF-8编码文件名 zf.write(file_path, arcname.encode("utf-8").decode("utf-8"))

但注意，某些国产压缩软件对UTF-8标志位支持不完善，遇到这类报错可以换用7-Zip重新压缩，或者直接用Python脚本解压（Python对编码处理更规范）。

4.4 分卷压缩文件z01的处理

如果你下载的zip资源是分卷压缩的（比如.zip文件旁边还有.z01、.z02文件），别直接用解压工具去解压.zip文件，会报“需要下一卷”的错误。

正确的操作方式是把所有分卷文件放到同一个目录，然后用7-Zip打开.zip的最后一个卷（一般是最后一个数字结尾的文件），或者直接双击.zip文件，7-Zip会自动识别相邻分卷。

我一开始不知道，傻乎乎地把.zip复制到别的目录去解压，结果一直报错。后来才反应过来，分卷压缩的所有切片必须放在一起，完整了才能解压。

4.5 Cookie过期导致越爬越少

漫画爬虫如果带了Cookie，运行时间一长就会遇到Cookie过期的问题。表现是：前面几十个章节正常下载，突然开始大面积失败。这是因为站点登录态失效后，接口不再返回付费章节数据。

处理方案有三种，按推荐度排序：

• 定期刷新Cookie：手动从浏览器复制新的Cookie，更新到配置里
• 用Session保持会话：requests.Session可以自动维持会话，配合登录接口做自动续期
• 抓取前做一次可用性检查：请求第一个API后检查返回码，发现失效就立即中止，避免浪费时间

我最终用了第三种方案，简单可靠，成本最低。

5. 请求频率控制与封IP应对

写爬虫第一课就是“别把对方服务器搞挂了”。漫画平台对请求频率的敏感度比普通网站高，因为图片请求非常占用带宽。

5.1 压测出来的合理请求间隔

我刚开始跑工具的时候，没做任何限速，4线程并发跑全速下载，跑了两百多话之后，突然所有请求都开始返回403。一开始以为是代码写错了，后来发现是IP被临时封禁了。解封等了一个小时才恢复。

后面我把策略调整为：每请求10次，主动sleep 1-2秒，图片并发数降到2。这个频率跑下来，整部漫画爬完也没有再触发封禁。

建议你在自己写工具的时候，先在目标站用小量请求测试出发封阈值。一般漫画站的防守策略是滑动窗口计数，比如1分钟内超过60次请求就封IP，那你的请求间隔至少得压到1秒以上。

5.2 设置随机延时比固定延时更有效

固定延时毕竟有规律，容易被识别。我在实际代码里加了个随机延时函数：

import random import time def random_delay(): time.sleep(random.uniform(0.5, 2.0))

每个请求之间随机延迟0.5-2秒，模拟真实用户的访问节奏。这样既不会触发封IP，也不会因为延时太长导致整体效率太低。

5.3 真正要做好的是数据校验

很多新手犯的错是只关心请求是否成功，忽略了数据正确性。比如图片接口返回的成功码是200，但下载下来的图片实际是一张403错误页；或者下载的图片只有几KB大小，明显不是正常图片。

我在代码里加了两个校验点：

• Content-Length校验：响应头声明的长度与实际下载字节数是否一致
• 文件头校验：检查图片文件的前几个字节是否是JPEG或PNG魔数

def is_valid_image(file_path): try: with open(file_path, "rb") as f: header = f.read(3) if header == b"\xff\xd8\xff": # JPEG return True if header == b"\x89PN": # PNG return True return False except Exception: return False

这两道校验几乎能拦截掉90%的下载异常，防止你花了几个小时跑出来的结果不能用。

6. 实战中关于合法使用的几点提醒

爬虫工具写出来不难，但用在哪里、怎么用，边界要想清楚。这里不是念教条，是几个很现实的问题。

6.1 这个工具适合谁，不适合谁

漫画爬虫工具适合的是：自己购买/有权限阅读的漫画做本地备份。比如你买了某个平台的会员，平台不提供离线下载功能，你写脚本把自己买的内容存到本地，完全没有问题。

不适合的是：把爬虫工具用于大规模抓取、二次分发、商业售卖。这类行为既违反平台服务条款，也可能触及法律红线。特别是某些漫画平台有独家版权内容，批量抓取后传播，风险极高。

我的建议是：自己在本地用、自己看，绝不要公开分享抓取的内容。

6.2 robots.txt 和站点访问协议

动手写爬虫前，花一分钟看一眼目标站的robots.txt，路径一般是https://域名/robots.txt。这个文件声明了哪些路径允许抓取、哪些路径禁止抓取。

虽然robots.txt没有强制执行力，但尊重它既是职业道德，也能帮你规避很多不必要的麻烦。大部分平台的robots.txt都会注明Disallow: /api/，说明接口数据不欢迎爬虫，建议只抓取前端页面展示的数据，不要触碰后端接口。

6.3 站点改版后的维护成本

很多自用爬虫工具都有一个“通病”：站方一改版，工具就废。漫画平台的页面结构、接口参数、图片URL规则都会定期调整。今天跑得好好的脚本，可能下个月就完全不可用了。

真正能长期运行的工具，设计时就要注意把“易变部分”独立出来。我在代码里把接口URL、请求头、解析逻辑分成独立模块，改版时只需要替换对应模块，不用动主流程。这个结构后面维护起来很省心。

7. 完整工具的可视化思路与后续扩展

上面这套骨架能跑通基本流程，但离“好用”还有距离。下面聊几个可以继续扩展的方向。

7.1 增量更新机制

漫画会持续更新，每次跑全量爬虫太浪费时间。可以做一个增量更新：记录上次爬到的章节ID，下次只抓取大于该ID的章节。实现上只需要在章节列表里加个判断：

def filter_new_chapters(chapters, last_chapter_id): return [c for c in chapters if c["id"] > last_chapter_id]

增量更新最大的好处是省流量、省时间，也减少了对目标站的请求压力。

7.2 多漫画批量管理

如果一个脚本只能爬一部漫画，管理成本太高。更好的设计是做成“任务队列”：一个配置文件里定义多个任务，每个任务包含漫画URL和输出目录，脚本按顺序执行。

CONFIG = [ {"comic_url": "https://example.com/comic/1", "save_dir": "./downloads/comic1"}, {"comic_url": "https://example.com/comic/2", "save_dir": "./downloads/comic2"}, ]

这就是批量型爬虫的典型应用场景。对于漫画这类数据量大的站点，批量型爬虫比增量型爬虫更适合用在首次全量抓取，增量型适合后续日常更新。

还有一个容易忽略的点：垂直型爬虫。针对漫画这个垂直领域，你可以把爬虫做得更“专业”一些，比如自动解析章节名、自动生成目录索引、自动生成mht或pdf电子书。垂直型爬虫的精髓在于深度优化某个特定领域的数据处理流程，而不是贪多求全。

7.3 生成PDF还是ZIP

ZIP适合手机相册直接看图，PDF适合电脑/平板阅读器。各有优劣：

我个人更倾向于ZIP，因为保留原始图片画质很重要。漫画的画面细节多，压缩成PDF后，网点、线条细节都会有一定损伤。如果真想要PDF，可以用img2pdf库直接封装图片，不做二次压缩，画质损失小。

7.4 给工具加日志和监控

自用的爬虫工具最怕静默失败。跑了两小时，结果全是403，你不看日志根本发现不了。所以我给工具加了一个简单的日志模块：

import logging logging.basicConfig( level=logging.INFO, format="%(asctime)s [%(levelname)s] %(message)s", handlers=[ logging.FileHandler("crawler.log", encoding="utf-8"), logging.StreamHandler() ] )

每次请求成功或失败，都输出一条日志。这样即使工具跑到一半挂掉，也能通过日志定位是哪一步出的问题。

最后再分享一个实用的小技巧

写这类下载工具，调试阶段最怕的就是反复下载同一部漫画来测试代码。我的做法是：先做一个--test参数，只下载第一章图片，快速验证整个流程是否跑通。测试通过后再全量跑，效率高很多。

逻辑很简单，就是在入口加个判定：

import sys if "--test" in sys.argv: chapters = chapters[:1]

一个很小的改动，能省下大量调试时间。

另外，如果你在解压zip时遇到“file is not a zip file”或者could not find EOCD这种报错，先别急着用修复工具。用你的Python环境直接测试一下zip包是否完整：

import zipfile with zipfile.ZipFile("output.zip", "r") as zf: bad_file = zf.testzip() if bad_file: print(f"损坏文件: {bad_file}") else: print("zip完整")

如果提示损坏，优先重新下载对应章节，而不是死磕修复工具。

这个工具我目前已经稳定跑了好几部漫画，单部两三百章的体量，配合限速和断点续传，大概两三个小时跑完，中途基本不需要人工干预。把它分享出来的价值在于，漫画爬虫的完整链路——从接口分析、请求伪装、并发下载、zip打包到异常处理——每一个环节都有值得注意的细节。希望这篇内容能帮你少走点弯路。

本文还有配套的精品资源，点击获取