做影视数据分析的朋友基本都绕不开国际电影节的入围名单。每年戛纳、柏林、威尼斯三大影展的入围名单一公布紧接着就是各种版本的片单整理。最笨的办法是一个一个官网去复制粘贴费时间不说片名中英文对照、制作国家/地区、竞赛单元、导演信息这些字段还特别容易漏。这份指南里我用 Python 爬虫把三家官网的采集逻辑彻底跑通了一遍哪些页面可以直接解析 HTML哪些数据其实藏在接口返回的 JSON 里中英文片名怎么对齐最后怎么导出成干净的 CSV 文件都会一步步拆开讲清楚。这个项目适合三类人一是需要定期追踪电影节片单的影评人、选片人、策展助理二是做影视数据库或文化数据分析的开发者三是刚学完 requests 和 BeautifulSoup、想找个真实项目练手的爬虫新手。文章按“需求拆解 → 页面分析 → 代码实现 → 问题排查”的顺序展开你可以直接照着操作也可以只挑自己关心的部分看。1. 需求拆解这份名单数据到底该从哪儿下手1.1 明确字段与数据来源先把需求讲清楚。我们要采集的核心字段有四个片名中英文、制作国家/地区、竞赛单元、导演信息。看起来简单真去官网翻一圈就会发现有很多坑。先说片名。三大影展的官网通常只提供原始片名和英文译名中文名基本不会出现在官网上。比如一部法语影片官网给出的是法文原名 Le Voyage 和英文名 The Journey中文名叫什么需要自己想办法处理。这是整个项目里最耗精力的部分后面我会单独讲对齐策略。再说制作国家/地区。合拍片非常常见一部影片可能同时标注法国、比利时、卢森堡三个国家采集的时候要考虑是用短横线分隔还是用逗号连接否则后面做统计时会很痛苦。竞赛单元字段相对明确但不同影展的单元名称差异很大。戛纳有“主竞赛”“一种关注”“午夜展映”柏林有“主竞赛”“遇见”威尼斯有“主竞赛”“地平线”“威尼斯日”。同一个单元在不同官网上的分类层级也不同有的在列表页直接可见有的需要点进详情页才能确认。采集结构设计时必须把这个层级差异考虑进去。导演信息同样不省心。导演姓名在官网里可能是“Jean Dupont”这种格式也可能在接口里拆成 first_name 和 last_name 两个字段甚至遇到双导演时会以数组形式返回。解析的时候要统一成“导演A / 导演B”的格式避免一条数据多个导演时把字段撑破。数据来源锁定在两个语言体系、三种页面结构上戛纳以法语内容为主柏林以德语为主威尼斯以意大利语为主。三家官网的页面语言、渲染方式、数据结构各有不同这正是这个项目最有价值的地方——你不是在写一个只适配某个网站的爬虫而是在练习一套能快速迁移到任意多语言官网的方法论。1.2 技术选型为什么先用 requests 而不是 Scrapy很多新手一看要抓三个网站第一反应是上 Scrapy。我的建议是这个量级完全没必要。Scrapy 的优势在于分布式、并发调度、中间件生态适合大规模、持续性、需要增量更新的爬虫项目。而电影节入围名单一年就公布几次数据量撑死几百条用 Scrapy 属于杀鸡用牛刀光配置 Item Pipeline 和中间件的时间就够把整个项目写完了。我的技术路线是分层的第一优先级requests BeautifulSoup 直接解析静态 HTML。结构规整的页面用这种方式最直接代码可读性也最好。第二优先级寻找页面背后的 XHR 接口用 requests 直接请求 JSON。很多动态渲染的官网底层数据接口反而是最稳定的入口比解析渲染后的 DOM 更可靠。第三优先级Playwright 做浏览器渲染兜底。只有接口有签名校验、或者页面结构过于复杂时才上这种重型方案。这个优先级设计的核心逻辑是能用简单方法解决的绝不上复杂工具。我见过不少爬虫项目最后死在过度设计上——用 Scrapy 写了大量中间件结果目标网站改一次版整套配置就要重写。用 requests 加 BeautifulSoup碰到改版时改几行选择器就能恢复工作。1.3 这份数据抓下来能做什么这个项目看起来只是抓一份名单但它真正能延伸的应用场景很多。历年入围名单做趋势分析是最直接的玩法。把 2015 年到最近一届的数据全部采集下来按国家/地区、竞赛单元做透视能直观看到各国影片的入围数量变化。比如某一年某个国家的入围数量突然增加背后可能反映的是当地电影工业的活跃度提升或者电影节策展方向的调整。还可以做多语言片名数据库。把原文片名、英文片名、中文译名对齐后建一张表做成公开的影展数据库后续做影评分析、影片关联推荐、搜索匹配都有用。很多影视社区的片单功能底层数据就是这么积累起来的。对影评人来说完整的入围名单配合导演过往作品信息能快速生成一篇带数据分析的选片观察文章。这也是一份名单数据最有价值的地方——它不只是几十个片名而是一个可以进行多维度分析的结构化数据集。2. 页面结构分析三家官网的数据定位实战2.1 用浏览器开发者工具找到数据的真实位置拿到一个官网页面第一件事不是写代码而是打开浏览器开发者工具先搞清楚数据到底以什么形式存在。判断逻辑很简单右键查看网页源代码搜索页面上一眼能看到的文字。如果源码里能搜到说明是服务端渲染的静态 HTML直接用 requests 请求再解析即可。如果源码里搜不到但页面上能看到说明数据是 JavaScript 动态加载的这时就要切到 Network 面板筛选 Fetch/XHR 请求刷新页面观察哪个接口返回的数据里包含了目标字段。这个判断动作很关键。我见过有人对着一个纯动态页面硬写 CSS 选择器折腾了半天拿不到数据最后发现页面元素是 JS 渲染的真正的数据在一个返回 JSON 的接口里。用生活化类比来说静态页面相当于把菜直接摆在货架上你拿着购物篮去挑就行动态页面相当于货架是空的但仓库管理员手上有完整的库存清单你得找到沟通窗口去问。定位接口时重点看三类请求返回 JSON 的 XHR 请求、返回 JSONP 的脚本请求、以及静态资源里引用的数据文件。找到可疑的接口后直接在浏览器新标签打开看返回的数据结构里有没有目标字段。如果有记录下来备用如果没有继续往下翻其他请求。2.2 戛纳官网静态列表页的解析套路戛纳官网的入围名单页结构上更接近传统门户风格。以法语为主但很多栏目有英文切换链接。页面 HTML 里能看到规整的条目容器每个入围影片通常对应一个带有统一 class 名称的区块。我用一个结构示意来说明div classfilm-item h3 classfilm-titleLe Voyage/h3 p classfilm-title-enThe Journey/p p classdirectorJean Dupont/p p classcountryFrance, Belgium/p span classsectionCompetition/span /div实际页面里标签结构会有差异但核心思路是一致的先定位条目容器再从容器内部提取各字段。这种页面的优势是直观麻烦在于官网经常对 HTML 结构调整每次改版都要重新确认选择器。我在后面会给出一套配置化选择器的解决方案避免每次都改代码。戛纳官网的反爬策略相对温和只要 User-Agent 设置正确请求频率控制在 1 秒以上基本不会触发拦截。但要注意 Accept-Language 请求头如果你的请求头声明的是 zh-CN而页面内容以法语为主有些 CDN 节点可能返回异常的响应。建议把 Accept-Language 设为 fr-FR 或 en-US与目标页面语言保持一致。2.3 柏林官网动态渲染页面的接口挖掘柏林官网是我在三个网站里踩坑最多的一个。页面本身是典型的动态渲染架构列表区域的内容是通过 JavaScript 从后端接口拉取后渲染出来的。直接请求页面 URL 拿到的 HTML 里根本找不到影片条目信息。解决办法是切到 Network 面板筛选 Fetch/XHR刷新入围名单页面。这时能看到一个返回 JSON 的接口响应数据里包含了完整的影片数组。每个影片对象里有原文片名、英文片名、导演数组、制作国家数组、竞赛单元字段甚至还有影片海报链接。这个接口的价值在于它比渲染后的 DOM 结构更稳定字段命名更规范数据量也更完整。用 requests 直接请求这个 JSON 接口解析效率远高于处理 HTML。柏林官网还有一个特点接口的请求头里需要带 Referer 字段否则服务器会直接拒绝响应。这在动态页面里很常见因为接口设计时通常会校验来源页面。实操中我见过不少初学者UA 设置了Accept 设置了唯独忘了 Referer结果请求返回 403。这个问题我会在第四章的排查表里重点写。2.4 威尼斯官网多语言页面的字段识别威尼斯官网的难度不在反爬而在语言。页面默认意大利语字段名称全是意语缩写Titolo 指片名Regista 指导演Paese 指制片国家Sezione 指竞赛单元。这里有一个很实用的小技巧威尼斯官网的 URL 通常支持语言切换把路径中的 it 替换为 en页面就会切换到英文版。但接口返回的 JSON 字段名未必会跟着语言切换可能是因为底层数据模型统一用意大利语命名也可能是因为接口只返回固定字段名。所以要在代码里做一层字段映射而不是指望官网帮你翻译好。威尼斯官网的页面结构改动比较频繁像是在持续重构。去年能用的一批选择器今年可能就失效了。这种情况下接口方案比 HTML 解析方案更有优势——官网改版通常不会动底层接口就算动了JSON 字段的调整也往往比 HTML 结构调整更容易适配。3. 核心代码实现从请求到 CSV 导出的全流程3.1 项目初始化与请求模块先建立项目结构。我的习惯是分成三个文件spider.py 放主流程逻辑parsers.py 放各网站的解析函数output.py 负责清洗和导出。如果你的项目规模不大也可以全部写在一个文件里但至少要把请求函数、解析函数、导出函数分开定义方便后续单独维护。依赖安装只需要四个库pip install requests beautifulsoup4 pandas lxml其中 lxml 不是必须的但它的解析速度比 Python 标准库解析器快不少处理大页面时体感差异明显建议顺手装上。请求模块的核心是请求头设置这段代码是每个爬虫项目的地基import random import requests UA_POOL [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Safari/605.1.15, ] def build_headers(langfr-FR): return { User-Agent: random.choice(UA_POOL), Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: f{lang},{lang.split(-)[0]};q0.9,en;q0.7, Connection: keep-alive, } def fetch(url, langfr-FR, refererNone): headers build_headers(lang) if referer: headers[Referer] referer try: resp requests.get(url, headersheaders, timeout15) resp.raise_for_status() return resp except requests.RequestException as e: print(f[请求失败] {url} - {e}) return None注意几个细节User-Agent 池用随机方式轮换是为了避免每次请求都暴露完全相同的浏览器特征Accept-Language 根据目标网站语言动态设置Referer 只在需要时添加。这个模块足够应付三大影展官网的基础请求需求。3.2 静态页面解析以戛纳官网为例拿到 HTML 之后用 BeautifulSoup 定位入围影片的条目容器。假设容器 class 是 film-item解析逻辑可以这样写from bs4 import BeautifulSoup def parse_cannes(html): soup BeautifulSoup(html, lxml) films [] for block in soup.select(.film-item): film { title_original: block.select_one(.film-title).get_text(stripTrue), title_en: block.select_one(.film-title-en).get_text(stripTrue), director: block.select_one(.director).get_text(stripTrue), country: block.select_one(.country).get_text(stripTrue), section: block.select_one(.section).get_text(stripTrue), } films.append(film) return films这段代码里最需要注意的是 .get_text(stripTrue) 这个组合。不做 strip 的话从 HTML 里取出来的字符串会带大量换行和空格后续存进 CSV 还得二次清洗。select_one 返回的是第一个匹配元素如果某个字段不存在会返回 None这时再调用 get_text 就会报错。正式代码里要给每个字段加一层 try/except 或者使用 getattr 保护避免单条数据解析异常导致整个流程崩溃。写解析函数时还有一个经验先在命令行里把 HTML 片段打印出来肉眼确认选择器能匹配到目标元素再批量运行全量解析。直接跑全量容易在某个未知页面结构上踩坑调试成本反而更高。3.3 动态接口采集以柏林官网为例柏林官网的接口方案核心是找到那个返回影片数组的 JSON 接口。假设接口地址结构为api_url https://example-berlinale-api.org/api/selection params { edition: 2025, type: competition } headers build_headers(langde-DE) headers[Referer] https://example-berlinale.org/en/films resp requests.get(api_url, headersheaders, paramsparams) data resp.json() films [] for item in data.get(data, []): films.append({ title_original: item.get(originalTitle), title_en: item.get(englishTitle), director: / .join(item.get(directors, [])), country: , .join(item.get(countries, [])), section: item.get(section), })这里有几个关键点。directors 和 countries 字段在接口里通常是数组必须用 join 方法拼接成字符串否则存到 CSV 里会变成 Python 的 list 表达形式看起来很奇怪。用逗号连接国家、用顿号连接导演是我在实践里试出来的比较顺眼的格式你可以按自己习惯调整。动态接口方案远比你想象的可靠。官网改版时可能改页面模板、改 CSS 类名、改前端框架但底层接口的数据模型往往保持稳定。特别是电影节官网这种项目接口后面连着的是数据库研发团队不会因为首页改版就轻易改动数据库字段命名。所以只要有可用的接口优先走接口方案。如果接口请求失败比如返回 403 或者数据结构发生变化才需要退回 Playwright 方案。用 Playwright 打开页面等待影片列表渲染完成后直接读取渲染后的 DOM。这个方案成本高、速度慢但作为兜底手段能让爬虫在极端情况下仍然拿到数据。3.4 中英文片名对照最容易被低估的环节官网能提供原文片名和英文片名但中文译名几乎不会出现在官网里。这是整个项目里最需要人工参与的部分。我的处理策略是“映射表为主人工校对兜底”。先建立一张 Python 字典作为本地映射表CN_TITLES { The Journey: 旅程, Land of Silence: 静默之地, } def fill_cn_title(row): return CN_TITLES.get(row.get(title_en), row.get(title_en))运行完主体爬虫后检查输出 CSV 里 title_cn 列中与 title_en 相同的记录这些就是映射表缺失的影片集中处理补上译名。这种做法的好处是第一次跑完你可能需要人工补几十条但后续每年新增名单时大部分片名都能命中已有映射表需要人工处理的数量会越来越少。不建议依赖翻译 API 做全自动翻译。影片译名讲究约定俗成很多国际影片有固定的中文通译名直接直译出来的结果在豆瓣、IMDb 等平台对不上号反而给后续关联数据造成麻烦。翻译 API 可以作为一种辅助手段但最终要以人工校对为准。3.5 CSV 导出与数据清洗爬到原始数据只是第一步导出的 CSV 要让别人能直接打开使用这才是完整交付。import pandas as pd def save_to_csv(films, filename): df pd.DataFrame(films) df df.drop_duplicates(subset[title_original, director]) df df.fillna(未知) df.to_csv(filename, indexFalse, encodingutf-8-sig)这里有两个关键设置。第一个是 encodingutf-8-sig。很多初学者导出 CSV 后用 Excel 打开发现中文全部变成乱码原因就在这里。Excel 默认按本地编码在中文系统里通常是 GBK解析 CSV 文件而 Python 写入时如果用 UTF-8 且不带 BOMExcel 就会识别失败。utf-8-sig 编码会在文件头部写入 BOM 标记Excel 看到这个标记就能正确识别为 UTF-8 编码。第二个是 drop_duplicates 的去重逻辑。同一个影片可能在官网的多个子页面出现比如既出现在主竞赛单元列表里又出现在某场新闻发布会新闻稿里。用 title_original 加 director 的组合去重能有效避免最终名单里的重复记录。数据清洗还要注意字符串里的隐藏字符。HTML 里常见的不换行空格是 \xa0UTF-8 里有时会出现零宽空格\u200b这些肉眼看不到的字符会让你的文本匹配失败。清洗时统一用正则把它们替换成普通空格。4. 实战问题档案爬虫跑不起来时先查这几件事4.1 请求被拒绝403/406时的排查顺序遇到 403 Forbidden 或者 406 Not Acceptable按照下面的检查清单逐项排查检查 User-Agent 是否看起来像一个真实浏览器。放在 Python 默认的 requests.user-agent 很容易被识别换成一个完整的浏览器 UA 能解决大部分问题。检查 Accept-Language 是否与目标网站语言一致。请求法语官网却声明中文语言偏好可能会被 CDN 判定为异常请求。检查是否需要 Referer 头。动态接口场景下尤其常见服务器会校验请求来源页面是否合法。检查请求频率是否过高。用脚本连续不停发送请求触发基于速率限制的反爬策略是最常见的情况。每次请求之间加 1 到 3 秒的 sleep 很有必要。这里我踩过一个印象深刻的坑有一次柏林官网的接口突然大面积返回 403排查了半天发现是自己在代码里使用了某个已失效的旧 UA 字符串。换了一批新 UA 后立刻恢复。UA 池里的字符串需要定期更新尤其是过了一两年后旧版本浏览器的 UA 被服务端列入黑名单的情况并不少见。4.2 页面结构变化导致解析失败怎么办官网改版是每个爬虫项目都会遇到的问题电影节官网也不例外。最直观的表现就是 BeautifulSoup 选择器匹配不到任何元素返回结果为空。我推荐把选择器从代码逻辑中剥离出来集中维护在一个配置字典里SELECTORS { cannes: { container: .film-item, title_original: .film-title, title_en: .film-title-en, director: .director, country: .country, section: .section, }, berlinale_api: { title_original: originalTitle, title_en: englishTitle, director: directors, country: countries, section: section, }, }这样改版时只需要更新配置文件里的选择器不必改动主逻辑代码。解析函数里找不到元素时抛出的异常会被统一捕获并记录到日志文件中而不是直接让整个爬虫崩溃。类似这样def safe_extract(block, selector): elem block.select_one(selector) return elem.get_text(stripTrue) if elem else 用这个保护函数替代直接调用 select_one(...).get_text(...)可以确保某一条数据缺字段时不至于中断全流程。4.3 CSV 导出后 Excel 打开乱码怎么办这个问题前面提过解决方案这里展开说一下原因。Python 默认写文件的编码是 UTF-8但写成 UTF-8 无 BOM 格式时Excel 在 Windows 上会尝试用 ANSI 编码中文系统即 GBK解析从而产生乱码。解决方式即 CSV 导出时指定 encodingutf-8-sig。这是唯一的推荐方案不建议改为 encodinggbk因为 GBK 无法覆盖所有 Unicode 字符一旦片名包含生僻字或特殊符号写入就会直接报错。另外要注意的是pandas 的 to_csv 会默认对内容进行转义。如果片名里包含逗号字段会被自动用双引号包裹这是正常现象不要手动去掉引号否则 CSV 结构会出错。4.4 关于采集规范与请求频率的提醒最后说点偏规范的内容。虽然电影节官网的公开数据理论上是可以访问的但我们做爬虫时要守住几条底线。第一控制请求频率。单线程加随机延迟是最稳妥的方案每个请求之间至少间隔 1 秒。电影节名单一年就更新几次完全不存在需要高并发快速抓取的场景并发带来的收益微乎其微风险却会放大很多。第二尊重站点的访问条款。采集前可以在官网站点查一下站点条款特别是有没有明确禁止自动抓取的说明。个人学习和研究用途的数据采集通常问题不大但不要拿去做什么商业化服务。第三注意数据发布时的版权边界。即便只是名单也可能包含官网的排版、描述文字等信息。做数据分析时尽可能只保留结构化字段减少对外分发原始页面内容的可能性。我在实际做这个项目时最大的体会是真正花时间的不是 requests 怎么写、BeautifulSoup 怎么解析而是官网改版后的适配工作和片名译名的校对工作。这两件事没有一劳永逸的解法只能靠“配置化 日志排查 人工校对”这套流程去持续维护。如果你准备自己动手做一遍我的建议是先启动一个小规模试点抓一个单元、几十条数据跑通全流程再扩展去抓整个入围名单。一步到位往往意味着遇到问题时排查范围太大反而拖慢进度。片名映射表也建议从第一天就建好后续每年增量更新时你会发现前一年的人工积累能节省大量重复劳动。
做影视数据分析的朋友基本都绕不开国际电影节的入围名单。每年戛纳、柏林、威尼斯三大影展的入围名单一公布紧接着就是各种版本的片单整理。最笨的办法是一个一个官网去复制粘贴费时间不说片名中英文对照、制作国家/地区、竞赛单元、导演信息这些字段还特别容易漏。这份指南里我用 Python 爬虫把三家官网的采集逻辑彻底跑通了一遍哪些页面可以直接解析 HTML哪些数据其实藏在接口返回的 JSON 里中英文片名怎么对齐最后怎么导出成干净的 CSV 文件都会一步步拆开讲清楚。这个项目适合三类人一是需要定期追踪电影节片单的影评人、选片人、策展助理二是做影视数据库或文化数据分析的开发者三是刚学完 requests 和 BeautifulSoup、想找个真实项目练手的爬虫新手。文章按“需求拆解 → 页面分析 → 代码实现 → 问题排查”的顺序展开你可以直接照着操作也可以只挑自己关心的部分看。1. 需求拆解这份名单数据到底该从哪儿下手1.1 明确字段与数据来源先把需求讲清楚。我们要采集的核心字段有四个片名中英文、制作国家/地区、竞赛单元、导演信息。看起来简单真去官网翻一圈就会发现有很多坑。先说片名。三大影展的官网通常只提供原始片名和英文译名中文名基本不会出现在官网上。比如一部法语影片官网给出的是法文原名 Le Voyage 和英文名 The Journey中文名叫什么需要自己想办法处理。这是整个项目里最耗精力的部分后面我会单独讲对齐策略。再说制作国家/地区。合拍片非常常见一部影片可能同时标注法国、比利时、卢森堡三个国家采集的时候要考虑是用短横线分隔还是用逗号连接否则后面做统计时会很痛苦。竞赛单元字段相对明确但不同影展的单元名称差异很大。戛纳有“主竞赛”“一种关注”“午夜展映”柏林有“主竞赛”“遇见”威尼斯有“主竞赛”“地平线”“威尼斯日”。同一个单元在不同官网上的分类层级也不同有的在列表页直接可见有的需要点进详情页才能确认。采集结构设计时必须把这个层级差异考虑进去。导演信息同样不省心。导演姓名在官网里可能是“Jean Dupont”这种格式也可能在接口里拆成 first_name 和 last_name 两个字段甚至遇到双导演时会以数组形式返回。解析的时候要统一成“导演A / 导演B”的格式避免一条数据多个导演时把字段撑破。数据来源锁定在两个语言体系、三种页面结构上戛纳以法语内容为主柏林以德语为主威尼斯以意大利语为主。三家官网的页面语言、渲染方式、数据结构各有不同这正是这个项目最有价值的地方——你不是在写一个只适配某个网站的爬虫而是在练习一套能快速迁移到任意多语言官网的方法论。1.2 技术选型为什么先用 requests 而不是 Scrapy很多新手一看要抓三个网站第一反应是上 Scrapy。我的建议是这个量级完全没必要。Scrapy 的优势在于分布式、并发调度、中间件生态适合大规模、持续性、需要增量更新的爬虫项目。而电影节入围名单一年就公布几次数据量撑死几百条用 Scrapy 属于杀鸡用牛刀光配置 Item Pipeline 和中间件的时间就够把整个项目写完了。我的技术路线是分层的第一优先级requests BeautifulSoup 直接解析静态 HTML。结构规整的页面用这种方式最直接代码可读性也最好。第二优先级寻找页面背后的 XHR 接口用 requests 直接请求 JSON。很多动态渲染的官网底层数据接口反而是最稳定的入口比解析渲染后的 DOM 更可靠。第三优先级Playwright 做浏览器渲染兜底。只有接口有签名校验、或者页面结构过于复杂时才上这种重型方案。这个优先级设计的核心逻辑是能用简单方法解决的绝不上复杂工具。我见过不少爬虫项目最后死在过度设计上——用 Scrapy 写了大量中间件结果目标网站改一次版整套配置就要重写。用 requests 加 BeautifulSoup碰到改版时改几行选择器就能恢复工作。1.3 这份数据抓下来能做什么这个项目看起来只是抓一份名单但它真正能延伸的应用场景很多。历年入围名单做趋势分析是最直接的玩法。把 2015 年到最近一届的数据全部采集下来按国家/地区、竞赛单元做透视能直观看到各国影片的入围数量变化。比如某一年某个国家的入围数量突然增加背后可能反映的是当地电影工业的活跃度提升或者电影节策展方向的调整。还可以做多语言片名数据库。把原文片名、英文片名、中文译名对齐后建一张表做成公开的影展数据库后续做影评分析、影片关联推荐、搜索匹配都有用。很多影视社区的片单功能底层数据就是这么积累起来的。对影评人来说完整的入围名单配合导演过往作品信息能快速生成一篇带数据分析的选片观察文章。这也是一份名单数据最有价值的地方——它不只是几十个片名而是一个可以进行多维度分析的结构化数据集。2. 页面结构分析三家官网的数据定位实战2.1 用浏览器开发者工具找到数据的真实位置拿到一个官网页面第一件事不是写代码而是打开浏览器开发者工具先搞清楚数据到底以什么形式存在。判断逻辑很简单右键查看网页源代码搜索页面上一眼能看到的文字。如果源码里能搜到说明是服务端渲染的静态 HTML直接用 requests 请求再解析即可。如果源码里搜不到但页面上能看到说明数据是 JavaScript 动态加载的这时就要切到 Network 面板筛选 Fetch/XHR 请求刷新页面观察哪个接口返回的数据里包含了目标字段。这个判断动作很关键。我见过有人对着一个纯动态页面硬写 CSS 选择器折腾了半天拿不到数据最后发现页面元素是 JS 渲染的真正的数据在一个返回 JSON 的接口里。用生活化类比来说静态页面相当于把菜直接摆在货架上你拿着购物篮去挑就行动态页面相当于货架是空的但仓库管理员手上有完整的库存清单你得找到沟通窗口去问。定位接口时重点看三类请求返回 JSON 的 XHR 请求、返回 JSONP 的脚本请求、以及静态资源里引用的数据文件。找到可疑的接口后直接在浏览器新标签打开看返回的数据结构里有没有目标字段。如果有记录下来备用如果没有继续往下翻其他请求。2.2 戛纳官网静态列表页的解析套路戛纳官网的入围名单页结构上更接近传统门户风格。以法语为主但很多栏目有英文切换链接。页面 HTML 里能看到规整的条目容器每个入围影片通常对应一个带有统一 class 名称的区块。我用一个结构示意来说明div classfilm-item h3 classfilm-titleLe Voyage/h3 p classfilm-title-enThe Journey/p p classdirectorJean Dupont/p p classcountryFrance, Belgium/p span classsectionCompetition/span /div实际页面里标签结构会有差异但核心思路是一致的先定位条目容器再从容器内部提取各字段。这种页面的优势是直观麻烦在于官网经常对 HTML 结构调整每次改版都要重新确认选择器。我在后面会给出一套配置化选择器的解决方案避免每次都改代码。戛纳官网的反爬策略相对温和只要 User-Agent 设置正确请求频率控制在 1 秒以上基本不会触发拦截。但要注意 Accept-Language 请求头如果你的请求头声明的是 zh-CN而页面内容以法语为主有些 CDN 节点可能返回异常的响应。建议把 Accept-Language 设为 fr-FR 或 en-US与目标页面语言保持一致。2.3 柏林官网动态渲染页面的接口挖掘柏林官网是我在三个网站里踩坑最多的一个。页面本身是典型的动态渲染架构列表区域的内容是通过 JavaScript 从后端接口拉取后渲染出来的。直接请求页面 URL 拿到的 HTML 里根本找不到影片条目信息。解决办法是切到 Network 面板筛选 Fetch/XHR刷新入围名单页面。这时能看到一个返回 JSON 的接口响应数据里包含了完整的影片数组。每个影片对象里有原文片名、英文片名、导演数组、制作国家数组、竞赛单元字段甚至还有影片海报链接。这个接口的价值在于它比渲染后的 DOM 结构更稳定字段命名更规范数据量也更完整。用 requests 直接请求这个 JSON 接口解析效率远高于处理 HTML。柏林官网还有一个特点接口的请求头里需要带 Referer 字段否则服务器会直接拒绝响应。这在动态页面里很常见因为接口设计时通常会校验来源页面。实操中我见过不少初学者UA 设置了Accept 设置了唯独忘了 Referer结果请求返回 403。这个问题我会在第四章的排查表里重点写。2.4 威尼斯官网多语言页面的字段识别威尼斯官网的难度不在反爬而在语言。页面默认意大利语字段名称全是意语缩写Titolo 指片名Regista 指导演Paese 指制片国家Sezione 指竞赛单元。这里有一个很实用的小技巧威尼斯官网的 URL 通常支持语言切换把路径中的 it 替换为 en页面就会切换到英文版。但接口返回的 JSON 字段名未必会跟着语言切换可能是因为底层数据模型统一用意大利语命名也可能是因为接口只返回固定字段名。所以要在代码里做一层字段映射而不是指望官网帮你翻译好。威尼斯官网的页面结构改动比较频繁像是在持续重构。去年能用的一批选择器今年可能就失效了。这种情况下接口方案比 HTML 解析方案更有优势——官网改版通常不会动底层接口就算动了JSON 字段的调整也往往比 HTML 结构调整更容易适配。3. 核心代码实现从请求到 CSV 导出的全流程3.1 项目初始化与请求模块先建立项目结构。我的习惯是分成三个文件spider.py 放主流程逻辑parsers.py 放各网站的解析函数output.py 负责清洗和导出。如果你的项目规模不大也可以全部写在一个文件里但至少要把请求函数、解析函数、导出函数分开定义方便后续单独维护。依赖安装只需要四个库pip install requests beautifulsoup4 pandas lxml其中 lxml 不是必须的但它的解析速度比 Python 标准库解析器快不少处理大页面时体感差异明显建议顺手装上。请求模块的核心是请求头设置这段代码是每个爬虫项目的地基import random import requests UA_POOL [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Safari/605.1.15, ] def build_headers(langfr-FR): return { User-Agent: random.choice(UA_POOL), Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: f{lang},{lang.split(-)[0]};q0.9,en;q0.7, Connection: keep-alive, } def fetch(url, langfr-FR, refererNone): headers build_headers(lang) if referer: headers[Referer] referer try: resp requests.get(url, headersheaders, timeout15) resp.raise_for_status() return resp except requests.RequestException as e: print(f[请求失败] {url} - {e}) return None注意几个细节User-Agent 池用随机方式轮换是为了避免每次请求都暴露完全相同的浏览器特征Accept-Language 根据目标网站语言动态设置Referer 只在需要时添加。这个模块足够应付三大影展官网的基础请求需求。3.2 静态页面解析以戛纳官网为例拿到 HTML 之后用 BeautifulSoup 定位入围影片的条目容器。假设容器 class 是 film-item解析逻辑可以这样写from bs4 import BeautifulSoup def parse_cannes(html): soup BeautifulSoup(html, lxml) films [] for block in soup.select(.film-item): film { title_original: block.select_one(.film-title).get_text(stripTrue), title_en: block.select_one(.film-title-en).get_text(stripTrue), director: block.select_one(.director).get_text(stripTrue), country: block.select_one(.country).get_text(stripTrue), section: block.select_one(.section).get_text(stripTrue), } films.append(film) return films这段代码里最需要注意的是 .get_text(stripTrue) 这个组合。不做 strip 的话从 HTML 里取出来的字符串会带大量换行和空格后续存进 CSV 还得二次清洗。select_one 返回的是第一个匹配元素如果某个字段不存在会返回 None这时再调用 get_text 就会报错。正式代码里要给每个字段加一层 try/except 或者使用 getattr 保护避免单条数据解析异常导致整个流程崩溃。写解析函数时还有一个经验先在命令行里把 HTML 片段打印出来肉眼确认选择器能匹配到目标元素再批量运行全量解析。直接跑全量容易在某个未知页面结构上踩坑调试成本反而更高。3.3 动态接口采集以柏林官网为例柏林官网的接口方案核心是找到那个返回影片数组的 JSON 接口。假设接口地址结构为api_url https://example-berlinale-api.org/api/selection params { edition: 2025, type: competition } headers build_headers(langde-DE) headers[Referer] https://example-berlinale.org/en/films resp requests.get(api_url, headersheaders, paramsparams) data resp.json() films [] for item in data.get(data, []): films.append({ title_original: item.get(originalTitle), title_en: item.get(englishTitle), director: / .join(item.get(directors, [])), country: , .join(item.get(countries, [])), section: item.get(section), })这里有几个关键点。directors 和 countries 字段在接口里通常是数组必须用 join 方法拼接成字符串否则存到 CSV 里会变成 Python 的 list 表达形式看起来很奇怪。用逗号连接国家、用顿号连接导演是我在实践里试出来的比较顺眼的格式你可以按自己习惯调整。动态接口方案远比你想象的可靠。官网改版时可能改页面模板、改 CSS 类名、改前端框架但底层接口的数据模型往往保持稳定。特别是电影节官网这种项目接口后面连着的是数据库研发团队不会因为首页改版就轻易改动数据库字段命名。所以只要有可用的接口优先走接口方案。如果接口请求失败比如返回 403 或者数据结构发生变化才需要退回 Playwright 方案。用 Playwright 打开页面等待影片列表渲染完成后直接读取渲染后的 DOM。这个方案成本高、速度慢但作为兜底手段能让爬虫在极端情况下仍然拿到数据。3.4 中英文片名对照最容易被低估的环节官网能提供原文片名和英文片名但中文译名几乎不会出现在官网里。这是整个项目里最需要人工参与的部分。我的处理策略是“映射表为主人工校对兜底”。先建立一张 Python 字典作为本地映射表CN_TITLES { The Journey: 旅程, Land of Silence: 静默之地, } def fill_cn_title(row): return CN_TITLES.get(row.get(title_en), row.get(title_en))运行完主体爬虫后检查输出 CSV 里 title_cn 列中与 title_en 相同的记录这些就是映射表缺失的影片集中处理补上译名。这种做法的好处是第一次跑完你可能需要人工补几十条但后续每年新增名单时大部分片名都能命中已有映射表需要人工处理的数量会越来越少。不建议依赖翻译 API 做全自动翻译。影片译名讲究约定俗成很多国际影片有固定的中文通译名直接直译出来的结果在豆瓣、IMDb 等平台对不上号反而给后续关联数据造成麻烦。翻译 API 可以作为一种辅助手段但最终要以人工校对为准。3.5 CSV 导出与数据清洗爬到原始数据只是第一步导出的 CSV 要让别人能直接打开使用这才是完整交付。import pandas as pd def save_to_csv(films, filename): df pd.DataFrame(films) df df.drop_duplicates(subset[title_original, director]) df df.fillna(未知) df.to_csv(filename, indexFalse, encodingutf-8-sig)这里有两个关键设置。第一个是 encodingutf-8-sig。很多初学者导出 CSV 后用 Excel 打开发现中文全部变成乱码原因就在这里。Excel 默认按本地编码在中文系统里通常是 GBK解析 CSV 文件而 Python 写入时如果用 UTF-8 且不带 BOMExcel 就会识别失败。utf-8-sig 编码会在文件头部写入 BOM 标记Excel 看到这个标记就能正确识别为 UTF-8 编码。第二个是 drop_duplicates 的去重逻辑。同一个影片可能在官网的多个子页面出现比如既出现在主竞赛单元列表里又出现在某场新闻发布会新闻稿里。用 title_original 加 director 的组合去重能有效避免最终名单里的重复记录。数据清洗还要注意字符串里的隐藏字符。HTML 里常见的不换行空格是 \xa0UTF-8 里有时会出现零宽空格\u200b这些肉眼看不到的字符会让你的文本匹配失败。清洗时统一用正则把它们替换成普通空格。4. 实战问题档案爬虫跑不起来时先查这几件事4.1 请求被拒绝403/406时的排查顺序遇到 403 Forbidden 或者 406 Not Acceptable按照下面的检查清单逐项排查检查 User-Agent 是否看起来像一个真实浏览器。放在 Python 默认的 requests.user-agent 很容易被识别换成一个完整的浏览器 UA 能解决大部分问题。检查 Accept-Language 是否与目标网站语言一致。请求法语官网却声明中文语言偏好可能会被 CDN 判定为异常请求。检查是否需要 Referer 头。动态接口场景下尤其常见服务器会校验请求来源页面是否合法。检查请求频率是否过高。用脚本连续不停发送请求触发基于速率限制的反爬策略是最常见的情况。每次请求之间加 1 到 3 秒的 sleep 很有必要。这里我踩过一个印象深刻的坑有一次柏林官网的接口突然大面积返回 403排查了半天发现是自己在代码里使用了某个已失效的旧 UA 字符串。换了一批新 UA 后立刻恢复。UA 池里的字符串需要定期更新尤其是过了一两年后旧版本浏览器的 UA 被服务端列入黑名单的情况并不少见。4.2 页面结构变化导致解析失败怎么办官网改版是每个爬虫项目都会遇到的问题电影节官网也不例外。最直观的表现就是 BeautifulSoup 选择器匹配不到任何元素返回结果为空。我推荐把选择器从代码逻辑中剥离出来集中维护在一个配置字典里SELECTORS { cannes: { container: .film-item, title_original: .film-title, title_en: .film-title-en, director: .director, country: .country, section: .section, }, berlinale_api: { title_original: originalTitle, title_en: englishTitle, director: directors, country: countries, section: section, }, }这样改版时只需要更新配置文件里的选择器不必改动主逻辑代码。解析函数里找不到元素时抛出的异常会被统一捕获并记录到日志文件中而不是直接让整个爬虫崩溃。类似这样def safe_extract(block, selector): elem block.select_one(selector) return elem.get_text(stripTrue) if elem else 用这个保护函数替代直接调用 select_one(...).get_text(...)可以确保某一条数据缺字段时不至于中断全流程。4.3 CSV 导出后 Excel 打开乱码怎么办这个问题前面提过解决方案这里展开说一下原因。Python 默认写文件的编码是 UTF-8但写成 UTF-8 无 BOM 格式时Excel 在 Windows 上会尝试用 ANSI 编码中文系统即 GBK解析从而产生乱码。解决方式即 CSV 导出时指定 encodingutf-8-sig。这是唯一的推荐方案不建议改为 encodinggbk因为 GBK 无法覆盖所有 Unicode 字符一旦片名包含生僻字或特殊符号写入就会直接报错。另外要注意的是pandas 的 to_csv 会默认对内容进行转义。如果片名里包含逗号字段会被自动用双引号包裹这是正常现象不要手动去掉引号否则 CSV 结构会出错。4.4 关于采集规范与请求频率的提醒最后说点偏规范的内容。虽然电影节官网的公开数据理论上是可以访问的但我们做爬虫时要守住几条底线。第一控制请求频率。单线程加随机延迟是最稳妥的方案每个请求之间至少间隔 1 秒。电影节名单一年就更新几次完全不存在需要高并发快速抓取的场景并发带来的收益微乎其微风险却会放大很多。第二尊重站点的访问条款。采集前可以在官网站点查一下站点条款特别是有没有明确禁止自动抓取的说明。个人学习和研究用途的数据采集通常问题不大但不要拿去做什么商业化服务。第三注意数据发布时的版权边界。即便只是名单也可能包含官网的排版、描述文字等信息。做数据分析时尽可能只保留结构化字段减少对外分发原始页面内容的可能性。我在实际做这个项目时最大的体会是真正花时间的不是 requests 怎么写、BeautifulSoup 怎么解析而是官网改版后的适配工作和片名译名的校对工作。这两件事没有一劳永逸的解法只能靠“配置化 日志排查 人工校对”这套流程去持续维护。如果你准备自己动手做一遍我的建议是先启动一个小规模试点抓一个单元、几十条数据跑通全流程再扩展去抓整个入围名单。一步到位往往意味着遇到问题时排查范围太大反而拖慢进度。片名映射表也建议从第一天就建好后续每年增量更新时你会发现前一年的人工积累能节省大量重复劳动。
