简介爬虫不仅是数据采集工具更是理解Web结构的关键实践。垂直爬虫专注于特定领域通过列表页与详情页分层抓取结构化数据requests结合BeautifulSoup是中小规模项目的经典选型。增量爬虫通过主键去重机制利用SQLite的INSERT OR IGNORE实现高效更新避免重复请求带来的封禁风险。工程实践中还需关注User-Agent伪装、随机延时等反爬策略。当项目以zip压缩包分发时常见如“file is not a zip file”或“EOCD缺失”的解压故障往往源于下载不完整或编码混乱可通过zip -FF修复或指定编码解决。本文从爬虫技术选型到压缩包排错系统梳理了这套技术链路的完整细节帮助开发者少走弯路。 说句实话我第一眼看到“JAVBus 老司机爬虫.zip”这个压缩包的时候脑子里冒出来的不是这个站点本身而是三个日常会反反复复折腾人的技术点垂直型爬虫怎么搭、增量更新怎么去重、以及——这样一个打包好的zip为什么总是一解压就出幺蛾子。如果你手上也拿到了类似的压缩包或者你正准备写一个针对番号类影视数据库的采集工具这篇文章可以帮你省掉不少弯路。我会把这个压缩包背后的完整技术链路拆开讲为什么用 requests 而不是 Scrapy列表页和详情页怎么配合增量爬虫怎么做去重以及 zip 解压时报错“file is not a zip file”“could not find EOCD”到底怎么修。全程基于真实项目经验代码可以直接抄坑也帮你提前踩平。1. 从压缩包说起这个爬虫到底是什么1.1 先把这个“老司机爬虫”拆开看“JAVBus 老司机爬虫.zip”这名字取得挺随意但拆开之后它的本质其实非常清晰一个标准的垂直型爬虫目标站点是番号类影视数据库站。这类站点的核心特征就是页面结构规整列表页和详情页分离字段固定非常适合用来做爬虫练手项目。那“垂直型爬虫”是什么概念你可以把它理解成捕鱼里的“单点下网”——只针对某一特定领域采集结构化数据比如只爬电影、只爬图书、只爬商品价格。与之相对的搜索引擎那类爬虫是广撒网今天爬新闻明天爬论坛啥都往仓库里收。垂直爬虫的好处是目标明确、字段可控、逻辑简单坏处是目标站点一改版你的解析逻辑可能就全废了。这个项目具体要采集的字段无非就是这几样番号也就是作品的唯一编号相当于商品的SKU标题发布日期演员列表封面图片链接详情页URL拿到这些字段后保存成 CSV 或 SQLite后续不管是做数据分析、做个人资料库、还是搭个简单的查询界面都够用了。所以你看它虽然叫“老司机”但本质上就是一个非常正经的 requests BeautifulSoup 采集脚本。1.2 为什么这类网站适合新手练手我经常被问到“第一个爬虫项目选什么练手”我的答案往往不是豆瓣、不是链家而是这种番号数据库站。为什么四个字结构规整。这类站点的 URL 规律非常明显翻页基本就是/page/1、/page/2这样的固定模式列表页里的详情链接也集中在某个容器内详情页的标题、日期、演员信息通常都挂在固定的 HTML 标签结构下。相比电商平台那种复杂的参数签名、字体反爬、滑块验证这种站点基本就是“裸奔”状态——不是说它没反爬而是反爬强度适合入门者一点一点去适应。当然我也要提醒一句这类站点内容特殊本文只聊技术实现代码仅用于学习爬虫原理和数据处理。你在实际使用时务必遵守目标网站的 robots 协议和服务条款控制好请求频率不要做大规模抓取更不要将数据用于商业用途。技术本身是工具怎么用取决于人。1.3 压缩包分发这个动作本身就值得聊一聊很多爬虫作者习惯把整个项目打包成 zip 发出来这合情合理——代码、虚拟环境依赖、说明文档、甚至爬取结果一个包全部带走。zip 是跨平台最通用的压缩格式比 rar 在 mac 和 linux 上的兼容性好得多所以“xxx爬虫.zip”成了项目分发的默认形态。但问题也出在这个 zip 上。我见过太多人拿到压缩包后第一步就卡在解压上有的报file is not a zip file有的报invalid zip archive: could not find EOCD还有的解压出来中文文件名全是乱码满屏“锟斤拷”。这些坑我在后面第 4 节专门展开讲这里先卖个关子。你只要记住这些坑基本都和爬虫代码无关但如果不解决你连代码长什么样都看不到。2. 整体设计思路requests BeautifulSoup 为什么够用2.1 选型对比requestsBS4 vs Scrapy很多新手一上来就纠结“我是不是该用 Scrapy”我的建议是先看项目体量。Scrapy 是一个完整的爬虫框架自带调度器、中间件、Pipeline、图片下载、数据导出等一堆能力但它对应的学习成本也高。你要先搞懂 Item、Spider、Middleware、Pipeline 这几个概念还要习惯它的异步机制——对于一个字段固定、单机单站的垂直爬虫来说这多少有点杀鸡用牛刀。requests BeautifulSoup 的组合则完全是另一套逻辑你写一个循环发请求拿 HTML用选择器抽数据存文件。整个过程完全在你的掌控中出了 bug 一眼就能看出来。我做了个简单的对比对比项requests BeautifulSoupScrapy上手难度低基础语法即可中高需要理解框架概念调试体验简单直接print 就行需要借助 shell 和日志适合场景单站点、中小规模、快速实现大型分布式、多站点、需要Pipeline并发能力靠线程/协程内置异步效率高扩展性需要自己设计架构框架内置中间件机制我个人建议如果你跑了几次就发现“这个站变了”或者你需要维护多个同类站点再考虑迁移到 Scrapy。第一版需求requests 足够。2.2 抓取策略列表页 详情页 两层模型这类站点普遍是“列表页 详情页”的经典模型。列表页一般每页几十个条目每个条目有一个详情链接详情页则包含你真正需要的完整字段。所以整体抓取流程就是从列表页开始解析页码逐页抓取从每个列表条目中提取详情页 URL请求详情页抽取完整字段判断该条数据是否已采集过去重逻辑存入本地文件或数据库这里最容易犯的错误是只爬到列表页就完事或者解析详情页时图省事只取列表页上那几个片段的字段。列表页的数据往往是被截断的比如简介只有前几十个字演员列表不全日期格式混乱。真正要到详情页你才能拿到干净的完整数据。2.3 数据存储设计CSV 和 SQLite 为什么并存我见过很多初学爬虫的人把数据往 Excel 里一存就完事。Excel 作为结果展示没问题但作为爬虫的“存储层”很痛苦——你得手动打开、手动保存、处理重复还得写公式。我的习惯是CSV 和 SQLite 同时维护。CSV 是给“人看的”导入 Excel、做报表、发邮件附件都方便SQLite 是给“程序用的”增量去重、条件查询、按日期筛选都高效。字段结构建议这样设计字段名类型说明idTEXT作品唯一编号番号用作主键titleTEXT完整标题dateTEXT发布日期统一格式为 YYYY-MM-DDactorsTEXT演员列表用竖线分隔cover_urlTEXT封面图链接page_urlTEXT详情页链接crawl_timeTEXT抓取时间戳用于增量判断SQLite 在这里最大的价值是天然的 UNIQUE 约束你可以在建表时把id设为主键后续插入时用INSERT OR IGNORE重复的自然被丢弃去重逻辑都不用自己写数据库帮你搞定了。3. 核心代码实现从零写一个能跑的爬虫3.1 环境准备先准备好 Python 3.9 以上的环境建议用虚拟环境别图省事装到全局后面依赖冲突会很难受。我用的是 venvpython -m venv venv source venv/bin/activate # Windows 是 venv\Scripts\activate pip install requests beautifulsoup4 lxmllxml 比默认的 html.parser 快不少解析大页面时差别明显强烈建议装上。至于 pandas如果你只是存 CSV用 Python 自带的 csv 模块就够了pandas 反而显得重。3.2 第一步会话和请求头写爬虫第一步不是写循环而是先把“身份”确认好。很多网站对裸的requests.get是直接 403 的因为默认的 User-Agent 是python-requests/x.x.x服务器一眼就识破了。这里要用到requests.Session它比直接用 requests.get 的两个好处一是能自动维持 Cookie二是复用底层 TCP 连接请求多个页面时效率更高。import requests import random HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Referer: https://www.example.com/, } session requests.Session() session.headers.update(HEADERS) def safe_get(url, retries3): for i in range(retries): try: r session.get(url, timeout10) r.raise_for_status() return r except requests.RequestException as e: wait 2 * (i 1) random.random() print(f第 {i1} 次请求失败: {e}, 等待 {wait:.2f}s) time.sleep(wait) return None这里我设置了重试机制单次请求失败不会让整个爬虫崩掉。timeout10是必须写的否则某个请求卡住你的任务就挂在那一整天。3.3 第二步列表页解析列表页的核心任务只有一个提取详情页的 URL。假设列表页的结构是每个条目都在div.item里详情链接是a[href*page]from bs4 import BeautifulSoup def parse_list_page(html): soup BeautifulSoup(html, lxml) links [] for a in soup.select(div.item a[href]): href a.get(href) if href and /page/ in href: links.append(href) return list(set(links)) # 去重注意这里我用了个小技巧list(set(links))。列表页偶尔会同一个链接出现两次重复请求纯属浪费先去重再入队。翻页的逻辑也很简单拼 URL 就行BASE_URL https://www.example.com all_detail_urls [] for page_num in range(1, 11): # 先爬前 10 页 page_url f{BASE_URL}/page/{page_num} r safe_get(page_url) if r is None: continue urls parse_list_page(r.text) all_detail_urls.extend(urls) time.sleep(random.uniform(1, 2)) # 随机延时稳字当头3.4 第三步详情页字段抽取详情页的解析是整个爬虫的核心字段能不能抽准直接决定数据质量。上代码def parse_detail_page(html): soup BeautifulSoup(html, lxml) data {} # 假设标题在 h3 标签内 title_tag soup.find(h3) data[title] title_tag.get_text(stripTrue) if title_tag else # 假设详情信息都堆在一个 div.info 里用正则或选择器逐行匹配 info_box soup.select_one(div.info) if info_box: rows info_box.find_all(p) for row in rows: text row.get_text(stripTrue) if text.startswith(番号): data[id] text.split(:)[-1].strip() elif text.startswith(日期): data[date] text.split(:)[-1].strip() elif text.startswith(演员): actor_tags row.find_all(a) actors [a.get_text(stripTrue) for a in actor_tags] data[actors] |.join(actors) # 封面图 cover soup.find(img, {class: cover}) data[cover_url] cover.get(src) if cover else return data这里有个很关键的细节演员列表我用了竖线|分隔绝对不用逗号。为什么因为 CSV 默认用逗号分隔列如果演员本身带逗号比如英文姓名中间有逗号你的 CSV 就会错位。竖线基本不会冲突安全。另一个细节是“字段缺失”的处理。永远不要假设页面结构百分百一样任何字段都可能为空。所以我全部给了默认值宁可存空字符串也不能让程序崩。3.5 第四步增量爬取与去重很多爬虫跑着跑着就“挂了”不是因为代码错而是因为每次重跑都从头抓一遍不仅浪费时间还会因为请求量太大触发封禁。增量爬虫的核心思路是记住你上次爬到哪了这次只抓新增的、或者内容有变化的那部分。最简单的增量实现方式import os import sqlite3 def get_existing_ids(): if not os.path.exists(data.db): return set() conn sqlite3.connect(data.db) cur conn.execute(SELECT id FROM items) ids {row[0] for row in cur.fetchall()} conn.close() return ids然后在主循环里判断existing_ids get_existing_ids() for url in all_detail_urls: # 这里通过 URL 里的番号判断或者先请求详情页拿 id 再判断 # 更省事的方式拿详情页 id 后用 INSERT OR IGNORE ...如果你用的是 SQLite可以更进一步省掉“先判断再插入”的两步操作INSERT OR IGNORE INTO items (id, title, date, actors, cover_url, page_url, crawl_time) VALUES (?, ?, ?, ?, ?, ?, ?)INSERT OR IGNORE会在主键冲突时自动忽略插入这样你连繁琐的判断代码都不用写数据库直接帮你干了去重的活。这是我自己踩过坑之后最喜欢用的方案——简单、可靠、性能好。3.6 第五步控制频率避免被反爬封禁爬虫写得再漂亮如果一秒钟发几十个请求照样被封。这不是技术问题是礼貌问题。所以限速必须做import time import random # 随机延时 0.8 ~ 2.5 秒模拟人工操作 time.sleep(random.uniform(0.8, 2.5))这种随机延时看起来很简单但效果立竿见影。你还可以加一个“全局请求计数器”每请求 100 次后强制多睡 10 秒给服务器一个喘息窗口。我见过很多爬虫写手在这些细节上偷懒结果跑了个把小时就被封 IP然后跑来找我哭诉。我的建议是限速的代码永远不要删它花费的 1 毫秒时间换来的是爬虫活得更久。4. 关于那个 zip解压与修复的硬核踩坑4.1 “file is not a zip file”到底是什么问题标题里的“JAVBus 老司机爬虫.zip”它本身是个 zip 文件但你从各种渠道下载或者别人转发给你的 zip往往一下来就不是“正常的 zip”了。最常见的报错就是file is not a zip file。这个报错其实包含多种可能文件根本不是 zip可能被人改过后缀实际是 rar 或者 7z。你用file命令一看便知file suspicious.zip # 输出如果是 RAR archive data那这就不是 zip文件下载不完整zip 文件头部是PK\x03\x04尾部是PK\x05\x06EOCD 记录。如果文件被截断尾部的 EOCD 找不到就会报错。这类问题多见于网盘下载没下完、或者下载过程中断。加密 zip 被误判有些加了密码的 zip在部分老旧的解压工具下会直接报错提示不是 zip。这时候换用 7-Zip 或 Python 的 zipfile 模块测一下可能就能识别。排查方法很简单用 Python 自带的 zipfile 模块import zipfile try: with zipfile.ZipFile(爬虫.zip) as zf: zf.namelist() print(zip 文件正常) except zipfile.BadZipFile as e: print(f无法识别为 zip错误: {e})想知道文件真实类型用file命令比任何工具都准。4.2 “invalid zip archive: could not find EOCD” 的修复invalid zip archive: could not find EOCD这句报错在安卓 Studio 导入项目、IDEA 加载依赖、甚至部分 Python 包安装过程中都很常见。EOCD 是 End Of Central Directory 的缩写也就是 zip 文件最末尾那一段“中央目录结束标记”它记录了压缩包里有多少个文件、目录结构起始位置等关键信息。如果这个标记缺失所有解压工具都会懵。这种问题通常是“文件被截断”或者“文件被拼接污染”导致的。比如你从网盘下载的文件实际上只有 90%剩下的 10% 没下完就被强制停了。修复的思路是尝试重建中央目录。Linux/Mac 下用自带的zip命令# -FF 表示修复损坏的 zip输出到新文件 zip -FF damaged.zip repaired.zip如果修复成功你会得到一个repaired.zip再解压试试。如果文件确实缺失太多修复也只能救出其中一部分文件至少比全丢好。Windows 用户可以直接用 WinRAR 或者 7-Zip 打开这个损坏的 zip看看它能不能强制列出文件列表。7-Zip 在这方面经常有奇效文件虽然报错但它能自动跳过坏区域把能读的文件拉出来。4.3 中文乱码与“锟斤拷”解压 zip 最常见的翻车现场之一就是文件名乱码。比如 Windows 上用压缩软件打包的 zip文件名用的是 GBK 编码拿到 Linux 上解压系统默认按 UTF-8 解码结果就成了下面这副德性锟斤拷锟斤拷锟斤拷爬虫.py“锟斤拷”这个梗在程序员圈子里流传很多年它的本质就是 GBK 的字节流被当成 UTF-8 解码时产生的替换字符。解决办法是在 Linux 下指定文件名编码# -O 参数指定使用 CP936GBK编码解析文件名 unzip -O CP936 file.zip对于 macOS 用户系统的 unzip 可能不支持-O参数建议直接用ditto或者安装unar工具前者是 macOS 自带的分包解压工具对中文编码的兼容性比 unzip 好得多。更根本的解决方案是在打包的时候就不要用中文文件名。我一个常年发爬虫项目的朋友现在所有的文件名、目录名、甚至 README 文档名一律用英文或者拼音绝不用中文。看起来土但没有兼容性问题。压缩包内出现乱码直接影响别人对你第一印象——这一点技术再牛也没用。4.4 zip 密码移除只适合你自己的压缩包有些作者会给自己发的包加一层密码比如解压密码藏在网盘链接旁边结果你拿到的是加密 zip 却找不到密码或者是你自己打包时设了密码半年后忘了。这时候怎么办如果你确定这个压缩包是你自己的密码忘了可以用工具暴力恢复。两种常见思路zip2john把 zip 的哈希提取出来再用john做字典或暴力爆破zip2john backup.zip hash.txt john --wordlistrockyou.txt hash.txtfcrackzip简单粗暴fcrackzip -D -p rockyou.txt backup.zip需要说明的是这种做法只能对“弱密码”有效复杂密码基本无解所以与其事后破解不如在打包时就不加密或者用没有加密的压缩方式。另外这个动作只适用于你自己的压缩包破解他人加密压缩包是违法行为我不展开也请你在合法范围内使用这些技巧。4.5 z01 分卷压缩包怎么处理有读者问下载完一个包发现里面有.zip和一堆.z01这东西怎么解压这是分卷压缩的产物比如大文件被拆成了多个卷.z01是第一卷.zip是最后一卷缺一个都解不开。Linux 下的处理方式是把分卷合并成一个完整的 zipzip -s 0 part.zip combined.zip-s 0表示关闭分卷直接把各卷合并。合并之后你能得到一个完整的combined.zip再用正常的解压工具打开。Windows 下用 7-Zip 也可以直接打开.z01所在目录的第一个文件它会自动识别其他分卷。这个场景看着很杂但你在网上下载大体积爬虫项目、数据集的时候真会碰到。会了就是省事。5. 常见问题与排查技巧实录5.1 Cookie 失效与登录态这个爬虫如果需要登录才能访问详情页那你就必须处理 Cookie。直接从浏览器复制 Cookie 是最快的办法打开开发者工具F12切到 Network 面板刷新页面找到任意一个请求头里的Cookie:字段整段复制出来放到代码里。但这些 Cookie 会过期短的一两天长的也就一两周。过期后爬虫就不再返回正常页面而是跳到登录页。排查时你就发现 HTML 解析出来全是空字段或者拿到的是登录框。我的经验是把 Cookie 放到一个单独的配置文件里爬虫启动时读取而不是硬编码在代码里。这样过期了只需改配置不用动代码。同时在异常情况下打个日志如果连续 N 个页面解析出来字段都为空立刻发个提醒而不是让它默默跑一晚上。5.2 碰到百度安全验证怎么办这个情况在很多搜索类站点的抓取中都会冒出来。爬虫请求频率一高网站的 WAF 就会把你的请求挡下来返回一个“百度安全验证”的页面脚本解析不到任何有效数据。如果你碰到这种情况先别急着上 Selenium 这种重型工具第一步是降低频率、检查请求头把Referer、Accept-Language、User-Agent这些补全让自己看起来更像一个真实浏览器。第二步是加一个简单的验证页识别逻辑一旦检测到“请输入验证码”“安全验证”之类的关键词立刻停止抓取并通知你。技术上的终极方案是 Selenium 或 Playwright 接管浏览器但这属于用自重武器不仅效率低还容易引起更强反爬。真正能解决问题的永远是控制请求节奏而不是硬刚。5.3 反爬策略对照速查表我在实际项目里整理过一份反爬应对表不少朋友说挺好用也放到这反爬手段常见表现应对思路校验 User-Agent请求直接 403 或返回空页伪造主流浏览器 UA且定期更换校验 Referer请求被拒不带 Referer 就报错补充页面来源作为 Referer校验 Cookie需要登录或返回登录页从浏览器复制 Cookie并做好过期更新高频 IP 封禁连续请求后被限流随机延时 分批抓取 控制总请求量页面加密或混淆解析不出字段分析前端 JS或换用无头浏览器最后手段记住一个原则爬虫和反爬的对抗本质是成本和收益的对抗。你让网站付出的识别成本越低你被处理得越惨。最有效的反反爬策略其实是“慢”。5.4 数据质量CSV 用 Excel 打开乱码你以为数据抓下来就万事大吉No坑还在后头。用 Python 默认的csv模块写入文件时编码是 UTF-8Excel 打开时默认按 GBK 解码结果就是中文全乱。解决的办法是写 CSV 时指定编码为utf-8-sig它会自动在文件开头加上 BOM字节序标记Excel 就能正确识别了import csv with open(items.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([id, title, date, actors, cover_url, page_url]) ...这个utf-8-sig是很多中文爬虫项目都会踩的坑我第一次写的时候也困惑了半天“为什么 Python 写出来的 CSV 在 Excel 里全乱码”后来才发现就是差了这一个编码参数。5.5 部署到服务器定时更新爬虫不可能每次都手动跑尤其是增量爬虫最好每天定时跑一遍。Linux 下用 crontab 就够了# 每天凌晨 2 点执行一次 0 2 * * * cd /path/to/project /usr/bin/python3 crawler.py logs/crawler.log 21日志很重要我建议在代码里把关键操作都打印出来开始爬取、抓到多少条、新增多少条、出错在哪个 URL。这样第二天起来看一眼日志就知道昨晚跑得正不正常。日志是我排查问题最依赖的手段没有日志的爬虫项目出 bug 时你只能干瞪眼。5.6 导入 IDE 时“invalid zip archive”问题除了爬虫本身我还要提一个在 Android Studio、IntelliJ IDEA 这类 IDE 里配置依赖时常见的报错failed to copy spatial iop zip或导入失败 caused by: invalid zip archive: could not find eocd。这个跟你的爬虫项目关系不大但它经常出现在大家去“安装别人的项目”、导入依赖包的时候。本质原因依然是你手头那个 zip 文件不完整或者某个 jar 包损坏。解决方式就是回到 4.2 节说的修复流程用zip -FF修复或者干脆重新下载。IDE 里那个报错看起来高高在上其实底层和你在命令行解压失败是同一个逻辑知道原理之后就不慌了。6. 最后分享一点实操体会爬虫项目我写了不少从小型脚本到多线程采集都碰过。如果你问我对“JAVBus 老司机爬虫”这类项目有什么最深的感觉我的答案是它最难的部分从来不是代码而是“克制”。克制意味着你要控制请求频率别把目标服务器当自己家后花园意味着你要克制抓取范围只采必要字段别顺手把整个站都拖下来还意味着你要想清楚这个数据拿来做什么技术练习就止于技术练习。在你动手写代码之前一定先在浏览器里手动访问目标页面用 F12 看一下 HTML 结构。我见过太多人一上来就写 BeautifulSoup 选择器结果选择器跟真实页面结构根本不匹配重复调试的时间都够手动搞一遍了。另外如果后续你想把这个爬虫项目扩展得再深一点两个方向可以参考一是把数据接到 Flask 或者 FastAPI 上做一个简单的查询接口对着数据库跑 SQL 就行二是给爬虫加一个“变更检测”对已采集过的详情页定期重爬看标题、演员这种字段有没有更新这样你的数据就不是一锤子买卖。至于那个 zip 压缩包真正让他不闹心的方法说起来也就三个字多备份。你辛苦写出来的爬虫代码千万别只留一个压缩包本地放一份、Git 仓库放一份、云盘放一份。万一哪天下载文件损坏了还能从别的地方捞回来。这是我踩过好多次坑后最想让你先记住的一句话。本文还有配套的精品资源点击获取 JAVBus老司机爬虫zip拆解：架构设计、增量去重与zip修复实战
简介爬虫不仅是数据采集工具更是理解Web结构的关键实践。垂直爬虫专注于特定领域通过列表页与详情页分层抓取结构化数据requests结合BeautifulSoup是中小规模项目的经典选型。增量爬虫通过主键去重机制利用SQLite的INSERT OR IGNORE实现高效更新避免重复请求带来的封禁风险。工程实践中还需关注User-Agent伪装、随机延时等反爬策略。当项目以zip压缩包分发时常见如“file is not a zip file”或“EOCD缺失”的解压故障往往源于下载不完整或编码混乱可通过zip -FF修复或指定编码解决。本文从爬虫技术选型到压缩包排错系统梳理了这套技术链路的完整细节帮助开发者少走弯路。 说句实话我第一眼看到“JAVBus 老司机爬虫.zip”这个压缩包的时候脑子里冒出来的不是这个站点本身而是三个日常会反反复复折腾人的技术点垂直型爬虫怎么搭、增量更新怎么去重、以及——这样一个打包好的zip为什么总是一解压就出幺蛾子。如果你手上也拿到了类似的压缩包或者你正准备写一个针对番号类影视数据库的采集工具这篇文章可以帮你省掉不少弯路。我会把这个压缩包背后的完整技术链路拆开讲为什么用 requests 而不是 Scrapy列表页和详情页怎么配合增量爬虫怎么做去重以及 zip 解压时报错“file is not a zip file”“could not find EOCD”到底怎么修。全程基于真实项目经验代码可以直接抄坑也帮你提前踩平。1. 从压缩包说起这个爬虫到底是什么1.1 先把这个“老司机爬虫”拆开看“JAVBus 老司机爬虫.zip”这名字取得挺随意但拆开之后它的本质其实非常清晰一个标准的垂直型爬虫目标站点是番号类影视数据库站。这类站点的核心特征就是页面结构规整列表页和详情页分离字段固定非常适合用来做爬虫练手项目。那“垂直型爬虫”是什么概念你可以把它理解成捕鱼里的“单点下网”——只针对某一特定领域采集结构化数据比如只爬电影、只爬图书、只爬商品价格。与之相对的搜索引擎那类爬虫是广撒网今天爬新闻明天爬论坛啥都往仓库里收。垂直爬虫的好处是目标明确、字段可控、逻辑简单坏处是目标站点一改版你的解析逻辑可能就全废了。这个项目具体要采集的字段无非就是这几样番号也就是作品的唯一编号相当于商品的SKU标题发布日期演员列表封面图片链接详情页URL拿到这些字段后保存成 CSV 或 SQLite后续不管是做数据分析、做个人资料库、还是搭个简单的查询界面都够用了。所以你看它虽然叫“老司机”但本质上就是一个非常正经的 requests BeautifulSoup 采集脚本。1.2 为什么这类网站适合新手练手我经常被问到“第一个爬虫项目选什么练手”我的答案往往不是豆瓣、不是链家而是这种番号数据库站。为什么四个字结构规整。这类站点的 URL 规律非常明显翻页基本就是/page/1、/page/2这样的固定模式列表页里的详情链接也集中在某个容器内详情页的标题、日期、演员信息通常都挂在固定的 HTML 标签结构下。相比电商平台那种复杂的参数签名、字体反爬、滑块验证这种站点基本就是“裸奔”状态——不是说它没反爬而是反爬强度适合入门者一点一点去适应。当然我也要提醒一句这类站点内容特殊本文只聊技术实现代码仅用于学习爬虫原理和数据处理。你在实际使用时务必遵守目标网站的 robots 协议和服务条款控制好请求频率不要做大规模抓取更不要将数据用于商业用途。技术本身是工具怎么用取决于人。1.3 压缩包分发这个动作本身就值得聊一聊很多爬虫作者习惯把整个项目打包成 zip 发出来这合情合理——代码、虚拟环境依赖、说明文档、甚至爬取结果一个包全部带走。zip 是跨平台最通用的压缩格式比 rar 在 mac 和 linux 上的兼容性好得多所以“xxx爬虫.zip”成了项目分发的默认形态。但问题也出在这个 zip 上。我见过太多人拿到压缩包后第一步就卡在解压上有的报file is not a zip file有的报invalid zip archive: could not find EOCD还有的解压出来中文文件名全是乱码满屏“锟斤拷”。这些坑我在后面第 4 节专门展开讲这里先卖个关子。你只要记住这些坑基本都和爬虫代码无关但如果不解决你连代码长什么样都看不到。2. 整体设计思路requests BeautifulSoup 为什么够用2.1 选型对比requestsBS4 vs Scrapy很多新手一上来就纠结“我是不是该用 Scrapy”我的建议是先看项目体量。Scrapy 是一个完整的爬虫框架自带调度器、中间件、Pipeline、图片下载、数据导出等一堆能力但它对应的学习成本也高。你要先搞懂 Item、Spider、Middleware、Pipeline 这几个概念还要习惯它的异步机制——对于一个字段固定、单机单站的垂直爬虫来说这多少有点杀鸡用牛刀。requests BeautifulSoup 的组合则完全是另一套逻辑你写一个循环发请求拿 HTML用选择器抽数据存文件。整个过程完全在你的掌控中出了 bug 一眼就能看出来。我做了个简单的对比对比项requests BeautifulSoupScrapy上手难度低基础语法即可中高需要理解框架概念调试体验简单直接print 就行需要借助 shell 和日志适合场景单站点、中小规模、快速实现大型分布式、多站点、需要Pipeline并发能力靠线程/协程内置异步效率高扩展性需要自己设计架构框架内置中间件机制我个人建议如果你跑了几次就发现“这个站变了”或者你需要维护多个同类站点再考虑迁移到 Scrapy。第一版需求requests 足够。2.2 抓取策略列表页 详情页 两层模型这类站点普遍是“列表页 详情页”的经典模型。列表页一般每页几十个条目每个条目有一个详情链接详情页则包含你真正需要的完整字段。所以整体抓取流程就是从列表页开始解析页码逐页抓取从每个列表条目中提取详情页 URL请求详情页抽取完整字段判断该条数据是否已采集过去重逻辑存入本地文件或数据库这里最容易犯的错误是只爬到列表页就完事或者解析详情页时图省事只取列表页上那几个片段的字段。列表页的数据往往是被截断的比如简介只有前几十个字演员列表不全日期格式混乱。真正要到详情页你才能拿到干净的完整数据。2.3 数据存储设计CSV 和 SQLite 为什么并存我见过很多初学爬虫的人把数据往 Excel 里一存就完事。Excel 作为结果展示没问题但作为爬虫的“存储层”很痛苦——你得手动打开、手动保存、处理重复还得写公式。我的习惯是CSV 和 SQLite 同时维护。CSV 是给“人看的”导入 Excel、做报表、发邮件附件都方便SQLite 是给“程序用的”增量去重、条件查询、按日期筛选都高效。字段结构建议这样设计字段名类型说明idTEXT作品唯一编号番号用作主键titleTEXT完整标题dateTEXT发布日期统一格式为 YYYY-MM-DDactorsTEXT演员列表用竖线分隔cover_urlTEXT封面图链接page_urlTEXT详情页链接crawl_timeTEXT抓取时间戳用于增量判断SQLite 在这里最大的价值是天然的 UNIQUE 约束你可以在建表时把id设为主键后续插入时用INSERT OR IGNORE重复的自然被丢弃去重逻辑都不用自己写数据库帮你搞定了。3. 核心代码实现从零写一个能跑的爬虫3.1 环境准备先准备好 Python 3.9 以上的环境建议用虚拟环境别图省事装到全局后面依赖冲突会很难受。我用的是 venvpython -m venv venv source venv/bin/activate # Windows 是 venv\Scripts\activate pip install requests beautifulsoup4 lxmllxml 比默认的 html.parser 快不少解析大页面时差别明显强烈建议装上。至于 pandas如果你只是存 CSV用 Python 自带的 csv 模块就够了pandas 反而显得重。3.2 第一步会话和请求头写爬虫第一步不是写循环而是先把“身份”确认好。很多网站对裸的requests.get是直接 403 的因为默认的 User-Agent 是python-requests/x.x.x服务器一眼就识破了。这里要用到requests.Session它比直接用 requests.get 的两个好处一是能自动维持 Cookie二是复用底层 TCP 连接请求多个页面时效率更高。import requests import random HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Referer: https://www.example.com/, } session requests.Session() session.headers.update(HEADERS) def safe_get(url, retries3): for i in range(retries): try: r session.get(url, timeout10) r.raise_for_status() return r except requests.RequestException as e: wait 2 * (i 1) random.random() print(f第 {i1} 次请求失败: {e}, 等待 {wait:.2f}s) time.sleep(wait) return None这里我设置了重试机制单次请求失败不会让整个爬虫崩掉。timeout10是必须写的否则某个请求卡住你的任务就挂在那一整天。3.3 第二步列表页解析列表页的核心任务只有一个提取详情页的 URL。假设列表页的结构是每个条目都在div.item里详情链接是a[href*page]from bs4 import BeautifulSoup def parse_list_page(html): soup BeautifulSoup(html, lxml) links [] for a in soup.select(div.item a[href]): href a.get(href) if href and /page/ in href: links.append(href) return list(set(links)) # 去重注意这里我用了个小技巧list(set(links))。列表页偶尔会同一个链接出现两次重复请求纯属浪费先去重再入队。翻页的逻辑也很简单拼 URL 就行BASE_URL https://www.example.com all_detail_urls [] for page_num in range(1, 11): # 先爬前 10 页 page_url f{BASE_URL}/page/{page_num} r safe_get(page_url) if r is None: continue urls parse_list_page(r.text) all_detail_urls.extend(urls) time.sleep(random.uniform(1, 2)) # 随机延时稳字当头3.4 第三步详情页字段抽取详情页的解析是整个爬虫的核心字段能不能抽准直接决定数据质量。上代码def parse_detail_page(html): soup BeautifulSoup(html, lxml) data {} # 假设标题在 h3 标签内 title_tag soup.find(h3) data[title] title_tag.get_text(stripTrue) if title_tag else # 假设详情信息都堆在一个 div.info 里用正则或选择器逐行匹配 info_box soup.select_one(div.info) if info_box: rows info_box.find_all(p) for row in rows: text row.get_text(stripTrue) if text.startswith(番号): data[id] text.split(:)[-1].strip() elif text.startswith(日期): data[date] text.split(:)[-1].strip() elif text.startswith(演员): actor_tags row.find_all(a) actors [a.get_text(stripTrue) for a in actor_tags] data[actors] |.join(actors) # 封面图 cover soup.find(img, {class: cover}) data[cover_url] cover.get(src) if cover else return data这里有个很关键的细节演员列表我用了竖线|分隔绝对不用逗号。为什么因为 CSV 默认用逗号分隔列如果演员本身带逗号比如英文姓名中间有逗号你的 CSV 就会错位。竖线基本不会冲突安全。另一个细节是“字段缺失”的处理。永远不要假设页面结构百分百一样任何字段都可能为空。所以我全部给了默认值宁可存空字符串也不能让程序崩。3.5 第四步增量爬取与去重很多爬虫跑着跑着就“挂了”不是因为代码错而是因为每次重跑都从头抓一遍不仅浪费时间还会因为请求量太大触发封禁。增量爬虫的核心思路是记住你上次爬到哪了这次只抓新增的、或者内容有变化的那部分。最简单的增量实现方式import os import sqlite3 def get_existing_ids(): if not os.path.exists(data.db): return set() conn sqlite3.connect(data.db) cur conn.execute(SELECT id FROM items) ids {row[0] for row in cur.fetchall()} conn.close() return ids然后在主循环里判断existing_ids get_existing_ids() for url in all_detail_urls: # 这里通过 URL 里的番号判断或者先请求详情页拿 id 再判断 # 更省事的方式拿详情页 id 后用 INSERT OR IGNORE ...如果你用的是 SQLite可以更进一步省掉“先判断再插入”的两步操作INSERT OR IGNORE INTO items (id, title, date, actors, cover_url, page_url, crawl_time) VALUES (?, ?, ?, ?, ?, ?, ?)INSERT OR IGNORE会在主键冲突时自动忽略插入这样你连繁琐的判断代码都不用写数据库直接帮你干了去重的活。这是我自己踩过坑之后最喜欢用的方案——简单、可靠、性能好。3.6 第五步控制频率避免被反爬封禁爬虫写得再漂亮如果一秒钟发几十个请求照样被封。这不是技术问题是礼貌问题。所以限速必须做import time import random # 随机延时 0.8 ~ 2.5 秒模拟人工操作 time.sleep(random.uniform(0.8, 2.5))这种随机延时看起来很简单但效果立竿见影。你还可以加一个“全局请求计数器”每请求 100 次后强制多睡 10 秒给服务器一个喘息窗口。我见过很多爬虫写手在这些细节上偷懒结果跑了个把小时就被封 IP然后跑来找我哭诉。我的建议是限速的代码永远不要删它花费的 1 毫秒时间换来的是爬虫活得更久。4. 关于那个 zip解压与修复的硬核踩坑4.1 “file is not a zip file”到底是什么问题标题里的“JAVBus 老司机爬虫.zip”它本身是个 zip 文件但你从各种渠道下载或者别人转发给你的 zip往往一下来就不是“正常的 zip”了。最常见的报错就是file is not a zip file。这个报错其实包含多种可能文件根本不是 zip可能被人改过后缀实际是 rar 或者 7z。你用file命令一看便知file suspicious.zip # 输出如果是 RAR archive data那这就不是 zip文件下载不完整zip 文件头部是PK\x03\x04尾部是PK\x05\x06EOCD 记录。如果文件被截断尾部的 EOCD 找不到就会报错。这类问题多见于网盘下载没下完、或者下载过程中断。加密 zip 被误判有些加了密码的 zip在部分老旧的解压工具下会直接报错提示不是 zip。这时候换用 7-Zip 或 Python 的 zipfile 模块测一下可能就能识别。排查方法很简单用 Python 自带的 zipfile 模块import zipfile try: with zipfile.ZipFile(爬虫.zip) as zf: zf.namelist() print(zip 文件正常) except zipfile.BadZipFile as e: print(f无法识别为 zip错误: {e})想知道文件真实类型用file命令比任何工具都准。4.2 “invalid zip archive: could not find EOCD” 的修复invalid zip archive: could not find EOCD这句报错在安卓 Studio 导入项目、IDEA 加载依赖、甚至部分 Python 包安装过程中都很常见。EOCD 是 End Of Central Directory 的缩写也就是 zip 文件最末尾那一段“中央目录结束标记”它记录了压缩包里有多少个文件、目录结构起始位置等关键信息。如果这个标记缺失所有解压工具都会懵。这种问题通常是“文件被截断”或者“文件被拼接污染”导致的。比如你从网盘下载的文件实际上只有 90%剩下的 10% 没下完就被强制停了。修复的思路是尝试重建中央目录。Linux/Mac 下用自带的zip命令# -FF 表示修复损坏的 zip输出到新文件 zip -FF damaged.zip repaired.zip如果修复成功你会得到一个repaired.zip再解压试试。如果文件确实缺失太多修复也只能救出其中一部分文件至少比全丢好。Windows 用户可以直接用 WinRAR 或者 7-Zip 打开这个损坏的 zip看看它能不能强制列出文件列表。7-Zip 在这方面经常有奇效文件虽然报错但它能自动跳过坏区域把能读的文件拉出来。4.3 中文乱码与“锟斤拷”解压 zip 最常见的翻车现场之一就是文件名乱码。比如 Windows 上用压缩软件打包的 zip文件名用的是 GBK 编码拿到 Linux 上解压系统默认按 UTF-8 解码结果就成了下面这副德性锟斤拷锟斤拷锟斤拷爬虫.py“锟斤拷”这个梗在程序员圈子里流传很多年它的本质就是 GBK 的字节流被当成 UTF-8 解码时产生的替换字符。解决办法是在 Linux 下指定文件名编码# -O 参数指定使用 CP936GBK编码解析文件名 unzip -O CP936 file.zip对于 macOS 用户系统的 unzip 可能不支持-O参数建议直接用ditto或者安装unar工具前者是 macOS 自带的分包解压工具对中文编码的兼容性比 unzip 好得多。更根本的解决方案是在打包的时候就不要用中文文件名。我一个常年发爬虫项目的朋友现在所有的文件名、目录名、甚至 README 文档名一律用英文或者拼音绝不用中文。看起来土但没有兼容性问题。压缩包内出现乱码直接影响别人对你第一印象——这一点技术再牛也没用。4.4 zip 密码移除只适合你自己的压缩包有些作者会给自己发的包加一层密码比如解压密码藏在网盘链接旁边结果你拿到的是加密 zip 却找不到密码或者是你自己打包时设了密码半年后忘了。这时候怎么办如果你确定这个压缩包是你自己的密码忘了可以用工具暴力恢复。两种常见思路zip2john把 zip 的哈希提取出来再用john做字典或暴力爆破zip2john backup.zip hash.txt john --wordlistrockyou.txt hash.txtfcrackzip简单粗暴fcrackzip -D -p rockyou.txt backup.zip需要说明的是这种做法只能对“弱密码”有效复杂密码基本无解所以与其事后破解不如在打包时就不加密或者用没有加密的压缩方式。另外这个动作只适用于你自己的压缩包破解他人加密压缩包是违法行为我不展开也请你在合法范围内使用这些技巧。4.5 z01 分卷压缩包怎么处理有读者问下载完一个包发现里面有.zip和一堆.z01这东西怎么解压这是分卷压缩的产物比如大文件被拆成了多个卷.z01是第一卷.zip是最后一卷缺一个都解不开。Linux 下的处理方式是把分卷合并成一个完整的 zipzip -s 0 part.zip combined.zip-s 0表示关闭分卷直接把各卷合并。合并之后你能得到一个完整的combined.zip再用正常的解压工具打开。Windows 下用 7-Zip 也可以直接打开.z01所在目录的第一个文件它会自动识别其他分卷。这个场景看着很杂但你在网上下载大体积爬虫项目、数据集的时候真会碰到。会了就是省事。5. 常见问题与排查技巧实录5.1 Cookie 失效与登录态这个爬虫如果需要登录才能访问详情页那你就必须处理 Cookie。直接从浏览器复制 Cookie 是最快的办法打开开发者工具F12切到 Network 面板刷新页面找到任意一个请求头里的Cookie:字段整段复制出来放到代码里。但这些 Cookie 会过期短的一两天长的也就一两周。过期后爬虫就不再返回正常页面而是跳到登录页。排查时你就发现 HTML 解析出来全是空字段或者拿到的是登录框。我的经验是把 Cookie 放到一个单独的配置文件里爬虫启动时读取而不是硬编码在代码里。这样过期了只需改配置不用动代码。同时在异常情况下打个日志如果连续 N 个页面解析出来字段都为空立刻发个提醒而不是让它默默跑一晚上。5.2 碰到百度安全验证怎么办这个情况在很多搜索类站点的抓取中都会冒出来。爬虫请求频率一高网站的 WAF 就会把你的请求挡下来返回一个“百度安全验证”的页面脚本解析不到任何有效数据。如果你碰到这种情况先别急着上 Selenium 这种重型工具第一步是降低频率、检查请求头把Referer、Accept-Language、User-Agent这些补全让自己看起来更像一个真实浏览器。第二步是加一个简单的验证页识别逻辑一旦检测到“请输入验证码”“安全验证”之类的关键词立刻停止抓取并通知你。技术上的终极方案是 Selenium 或 Playwright 接管浏览器但这属于用自重武器不仅效率低还容易引起更强反爬。真正能解决问题的永远是控制请求节奏而不是硬刚。5.3 反爬策略对照速查表我在实际项目里整理过一份反爬应对表不少朋友说挺好用也放到这反爬手段常见表现应对思路校验 User-Agent请求直接 403 或返回空页伪造主流浏览器 UA且定期更换校验 Referer请求被拒不带 Referer 就报错补充页面来源作为 Referer校验 Cookie需要登录或返回登录页从浏览器复制 Cookie并做好过期更新高频 IP 封禁连续请求后被限流随机延时 分批抓取 控制总请求量页面加密或混淆解析不出字段分析前端 JS或换用无头浏览器最后手段记住一个原则爬虫和反爬的对抗本质是成本和收益的对抗。你让网站付出的识别成本越低你被处理得越惨。最有效的反反爬策略其实是“慢”。5.4 数据质量CSV 用 Excel 打开乱码你以为数据抓下来就万事大吉No坑还在后头。用 Python 默认的csv模块写入文件时编码是 UTF-8Excel 打开时默认按 GBK 解码结果就是中文全乱。解决的办法是写 CSV 时指定编码为utf-8-sig它会自动在文件开头加上 BOM字节序标记Excel 就能正确识别了import csv with open(items.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([id, title, date, actors, cover_url, page_url]) ...这个utf-8-sig是很多中文爬虫项目都会踩的坑我第一次写的时候也困惑了半天“为什么 Python 写出来的 CSV 在 Excel 里全乱码”后来才发现就是差了这一个编码参数。5.5 部署到服务器定时更新爬虫不可能每次都手动跑尤其是增量爬虫最好每天定时跑一遍。Linux 下用 crontab 就够了# 每天凌晨 2 点执行一次 0 2 * * * cd /path/to/project /usr/bin/python3 crawler.py logs/crawler.log 21日志很重要我建议在代码里把关键操作都打印出来开始爬取、抓到多少条、新增多少条、出错在哪个 URL。这样第二天起来看一眼日志就知道昨晚跑得正不正常。日志是我排查问题最依赖的手段没有日志的爬虫项目出 bug 时你只能干瞪眼。5.6 导入 IDE 时“invalid zip archive”问题除了爬虫本身我还要提一个在 Android Studio、IntelliJ IDEA 这类 IDE 里配置依赖时常见的报错failed to copy spatial iop zip或导入失败 caused by: invalid zip archive: could not find eocd。这个跟你的爬虫项目关系不大但它经常出现在大家去“安装别人的项目”、导入依赖包的时候。本质原因依然是你手头那个 zip 文件不完整或者某个 jar 包损坏。解决方式就是回到 4.2 节说的修复流程用zip -FF修复或者干脆重新下载。IDE 里那个报错看起来高高在上其实底层和你在命令行解压失败是同一个逻辑知道原理之后就不慌了。6. 最后分享一点实操体会爬虫项目我写了不少从小型脚本到多线程采集都碰过。如果你问我对“JAVBus 老司机爬虫”这类项目有什么最深的感觉我的答案是它最难的部分从来不是代码而是“克制”。克制意味着你要控制请求频率别把目标服务器当自己家后花园意味着你要克制抓取范围只采必要字段别顺手把整个站都拖下来还意味着你要想清楚这个数据拿来做什么技术练习就止于技术练习。在你动手写代码之前一定先在浏览器里手动访问目标页面用 F12 看一下 HTML 结构。我见过太多人一上来就写 BeautifulSoup 选择器结果选择器跟真实页面结构根本不匹配重复调试的时间都够手动搞一遍了。另外如果后续你想把这个爬虫项目扩展得再深一点两个方向可以参考一是把数据接到 Flask 或者 FastAPI 上做一个简单的查询接口对着数据库跑 SQL 就行二是给爬虫加一个“变更检测”对已采集过的详情页定期重爬看标题、演员这种字段有没有更新这样你的数据就不是一锤子买卖。至于那个 zip 压缩包真正让他不闹心的方法说起来也就三个字多备份。你辛苦写出来的爬虫代码千万别只留一个压缩包本地放一份、Git 仓库放一份、云盘放一份。万一哪天下载文件损坏了还能从别的地方捞回来。这是我踩过好多次坑后最想让你先记住的一句话。本文还有配套的精品资源点击获取