尧图网站建设 
简介本资源是一个面向科研人员与数据工程师的Web of Science学术论文自动化采集工具基于Python开发解决人工检索效率低、批量获取元数据如标题、作者、摘要、年份、引用数困难等问题适用于文献计量分析、研究趋势挖掘及知识图谱构建等场景。压缩包共21个文件约100KB包含7个核心Python脚本如爬虫主程序cl.py、数据清洗脚本cl_deal_data.py、引用分析模块citaton.py、6个XML配置/项目文件、2个PYC编译缓存、1个README.md说明文档、1个城市编码txt及1个初始引用数据Excel表结构体现“采集—清洗—分析”完整链路。已有4125人学习下载提供可直接运行的多版本爬虫逻辑、配套数据处理函数及初步分析示例兼顾功能完整性与代码可读性适合具备基础Python与网络请求知识的用户快速上手并二次拓展至其他学术数据库。 你有没有遇到过这种场景在Web of Science里筛一批论文标题、作者、期刊、被引次数一条条手动复制到Excel再整理成表格一晚上就搭进去了。尤其做文献计量、综述或者追踪某个研究方向的同学这种重复劳动简直是在浪费生命。用Python写一个Web of Science论文爬虫就是为了把这些机械操作一次性自动化。这篇文章我会分享一套完整的实践方案覆盖从访问逻辑梳理、检索请求构造、页面解析到数据导出的全流程附带可复用的核心代码框架和我在实际跑项目中踩过的坑。它适合有一定Python基础、想上手真实爬虫项目的人参考也适合正在做科研数据整理、想把自己从复制粘贴里解放出来的朋友。一开始先把话说清楚本文只讨论合法合规的学术元数据采集。Web of Science是商业数据库爬虫程序必须运行在你具备合法访问权限的网络环境里采集范围限定于公开可浏览的题录信息不破解任何付费机制、不绕过人机验证、请求频率控制在正常学术使用范围内。搞清楚边界下面的所有技术方案才是安全且有价值的。1. 动手之前先确认需求和边界1.1 这个爬虫到底要解决什么问题很多人在GitHub上看到WOS爬虫项目就直接拿来跑结果要么被封IP要么抓回来一堆乱码。问题不在代码在于没想清楚自己到底要什么。先用一句话定义需求从Web of Science按照指定检索式抓取符合条件论文的元数据字段例如标题、作者、来源期刊、出版年份、DOI、被引次数输出为结构化表格。这里的关键词是“元数据”不是全文PDF。抓摘要、抓引文信息、抓参考文献列表这些都在元数据范围内抓全文、批量下载PDF那就越界了。在这个需求下你要采集的数据量基本可控一篇综述做文献调研两百到五百篇核心论文足够了做一个小型文献计量分析几千篇也算可观。如果你的目标是百万级数据那就不是爬虫能解决的问题该去申请Clarivate的官方API或数据许可这个后面我会专门说。1.2 Web of Science的访问机制与合规底线Web of Science不同于普通公开网站。它的内容分两层检索结果页需要有效访问权限通常由机构订阅或账号登录控制论文详情页则在结果列表基础上更进一步包含摘要、关键词、引用关系等。爬虫要做的就是在这两层里取公开可浏览的信息而不是用技术手段绕过身份验证。实际操作中有几个合规原则值得提前定死只在你有权限的网络内运行很多高校和科研机构本身就开通了WOS访问权限直接扫码或IP授权就能进。请求频率限制在“人手工操作不会引起注意”的范围内每次请求间隔两三秒以上大批量数据分时段采集。不研究绕过验证码的方案。遇到验证页面就停一下手动验证一次再继续这是平台的反滥用机制也是我们作为从业者该守的规矩。采集结果仅用于个人学术研究不做二次转售、不做商业用途。为什么要这么较真因为我在实际项目中见过反例有个朋友为了赶毕业论文的文献综述写了个脚本一口气抓了几万条数据结果不到二十分钟账号被标记连累整个课题组那几天的WOS访问都受影响。爬虫不是跑得越快越好稳定、合规、可持续才是核心诉求。2. 技术方案选型requests、BeautifulSoup、Selenium如何分工2.1 先判断页面是静态渲染还是动态加载Web of Science的经典版检索结果页是服务端渲染的也就是说你发送一个带正确参数的GET请求服务器直接返回包含完整论文列表的HTML页面。这种情况下Python的requests库加BeautifulSoup就足够完成任务完全不需要动用浏览器自动化。但新版界面和部分详情页不一样页面里有些模块是JavaScript异步加载的比如引用次数趋势图、部分扩展字段单纯用requests拿到的HTML里没有这些数据。这时候有两个选择一是在请求时找出背后的XHR接口直接请求数据接口拿JSON二是引入Selenium这样的浏览器自动化工具让真实的浏览器完成渲染之后再取页面源码。我的建议是分阶段处理总量不大、以标准字段为主的项目requests BeautifulSoup就够了涉及异步加载字段或者登录交互复杂的场景再用Selenium兜底。一开始就上Selenium往往是大材小用跑起来又慢又吃内存。2.2 别忽略WOS自带的导出功能说一句可能不太中听的话很多人问我要WOS爬虫代码但实际去现场一看他们连Web of Science自带的导出功能都没用过。WOS检索结果页提供标准导出支持直接将题录导出为Excel、纯文本、RIS等格式单批有数量上限但足够日常使用。所以我的方案选型里一直有个习惯先手动导出一批数据看看结构再决定要不要写爬虫。如果每次检索结果只有一两百条官方导出完全够用再用Python做数据清洗和字段合并就行了如果你要做自动化流程、要定时批量采集、要跨检索式合并多个数据集这个时候爬虫才真正派上用场。2.3 反爬策略的正确打开方式一提到反爬很多人第一反应是UA伪装、代理池、验证码识别这套思路在普通网站上管用在WOS这种学术数据库上反而是错误示范。WOS的核心防线不是技术性的而是访问权限和频率控制。你只要有有效权限正常频率访问根本不会被拦你需要做的反而是克制自己不要高频请求。以我实际的使用节奏为例连续抓取时每个请求间隔控制在3到6秒每抓取50条记录就停一两分钟单次任务总量不超过两千条。这样跑下来长周期内都不会触发任何风控。如果把这个“节奏”写进代码就是设置合理的time.sleep间隔、使用带有重试机制的请求函数、对429或403状态码做退避处理。代理池不是不能用但对WOS这种IP授权数据库来说频繁更换IP反而容易被判定为异常强烈不建议。3. 核心代码实现从检索到数据落地的完整链路3.1 环境准备与依赖安装先说环境。我这边用的是Python 3.10理论上3.8以上都没问题。需要安装的库包括pip install requests beautifulsoup4 lxml pandasrequests负责HTTP请求beautifulsoup4配合lxml解析器解析HTMLpandas负责最后的结构化导出。这里我特别说一下lxmlbs4默认的Python解析器在解析大页面时速度会慢很多换lxml之后速度能提升好几倍尤其是WOS检索结果页的HTML又是出了名的嵌套深、结构杂解析器的性能差距非常明显。如果你的环境里还需要模拟浏览器操作再补一个Seleniumpip install selenium配合你本机已安装的Chrome浏览器和对应版本的chromedriver使用。不过就像前面说的核心链路不建议全程用Selenium它更适合做登录态获取或者处理少数动态加载的场景。3.2 访问票据Cookie与登录态准备Web of Science的访问权限一般通过两种方式生效一种是你所在的机构IP在订阅范围内直接从校园网进入就不需要登录另一种是需要在登录页输入机构账号或通过统一认证跳转。第二种情况下爬虫程序必须携带有效的登录凭证。最稳妥的方式不是让爬虫代码自己走一遍登录流程而是让浏览器完成一次真实的登录然后把浏览器里的Cookie导入到requests的Session中。这样做的好处是绕开了验证码、CAS跳转、多因素认证这些琐碎环节而且登录态和你在办公电脑上的会话保持一致行为更像一个真实的活跃用户。这里有一段从浏览器Cookie构造requests Session的示例代码import requests # 从浏览器开发者工具中复制完整的Cookie字符串格式如 # SIDxxx; UIDyyy; ... cookie_str 你的Cookie粘贴到这里 session requests.Session() session.headers.update({ 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-Language: en-US,en;q0.9,zh-CN;q0.8, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, }) # 将浏览器Cookie解析成字典并覆盖进去 for item in cookie_str.split(;): if in item: key, value item.strip().split(, 1) session.cookies.set(key, value)代码本身没什么高深的核心是把Cookie字符串结构化注入Session。这里的注意事项是Cookie会过期尤其是一些学校统一认证的会话可能几个小时就失效了。我自己的习惯是每次运行爬虫前先做一个连通性预检用Session请求一次WOS首页或检索页如果返回的状态码不是200或者页面里出现登录跳转关键字就说明Cookie失效了需要去浏览器重新登录并更新。3.3 构造检索请求并解析结果页接下来是核心环节构造检索URL发送请求解析结果列表。WOS检索URL的核心参数包括数据库选择、检索式、每页记录数和起始页码。由于WOS的界面改版过多次这里我不写一个死板的固定URL而是给一个可以灵活改写的模板。import time import random from bs4 import BeautifulSoup def build_search_url(query, start1, page_size10): # 以经典检索页结构为例实际使用请根据抓包结果修正参数 params { db: WOS, ts: query, # topic search 检索式 start: str(start), # 起始记录位置 pageSize: str(page_size), sortBy: relevance } # 这里用 requests 的 params 参数自动完成 URL 编码 return https://www.webofscience.com/wos/woscc/summary, params def fetch_page(session, query, start, page_size): base_url, params build_search_url(query, start, page_size) resp session.get(base_url, paramsparams, timeout30) resp.raise_for_status() return resp.text拿到HTML之后就到了解析阶段。不同版本的WOS页面结构差异很大不可能给一个一劳永逸的选择器但解析思路是通用的先找到承载论文列表的外层容器再在容器里逐条取出每一篇论文的信息块。以我最近一次解析的经验为例列表页中每篇论文的信息块通常包含标题、完整作者列表、期刊名称、出版年份、卷期页码、DOI、被引次数。这里给出一个相对稳健的解析框架实际字段定位需要你结合页面结构调整def parse_results(html): soup BeautifulSoup(html, lxml) records [] # 定位论文条目的容器按实际情况修改选择器 items soup.select(app-record) # 示例选择器请以实际页面为准 for item in items: try: title_el item.select_one(.title a) or item.select_one(.title) title title_el.get_text(stripTrue) if title_el else N/A authors_el item.select_one(.authors) authors authors_el.get_text(; , stripTrue) if authors_el else N/A source_el item.select_one(.source) source source_el.get_text(stripTrue) if source_el else N/A # DOI、年份、被引次数等字段按实际页面结构调整 doi_el item.select_one(.doi) doi doi_el.get_text(stripTrue) if doi_el else year_el item.select_one(.year) year year_el.get_text(stripTrue) if year_el else cited_el item.select_one(.citation) cited cited_el.get_text(stripTrue) if cited_el else 0 records.append({ title: title, authors: authors, source: source, doi: doi, year: year, cited_count: cited }) except Exception as e: # 单条解析失败不终止整体记录日志继续 print(f[warn] parse record failed: {e}) return records这里我特别想强调一个工程习惯解析环节一定要有异常保护。WOS页面经常出现个别论文缺少DOI、某条记录的字段结构略有不同等情况如果因为一条数据就抛出异常导致整批中断后续的维护成本会让你怀疑人生。稳妥的做法是逐条try-except解析失败的记录打日志跳过最后统计失败率如果失败率异常高再去排查选择器是否失效。3.4 翻页、去重与频控策略WOS的高级检索结果可能成千上万条翻页逻辑其实就是一个起始位置递增的循环。需要处理好的问题有三个重复数据、请求节奏、最大页数限制。去重是很多人会忽略的点。多页抓取时可能出现同一篇论文被不同检索式命中、或者排序变化导致结果重复的情况。我建议在数据收集阶段维护一个以DOI或“标题年份”为键的集合每次解析完一批数据就先查重再并入最终结果def is_duplicate(record, seen): key (record.get(doi) or ).lower() or (record[title] record[year]).lower() if key in seen: return True seen.add(key) return False请求节奏是稳定性的生命线。一个过于激进的循环可能在几十次请求后就触发平台的风控机制。我在实际项目中固定使用的模式是随机间隔加定期暂停def polite_sleep(): time.sleep(random.uniform(3, 6)) # 每5次请求后额外停顿一小段时间 if random.randint(1, 5) 1: time.sleep(random.uniform(8, 15))关于最大页数限制WOS的检索结果并不是无限翻页的实际能浏览的记录条数有上限不同权限等级下差异较大。爬虫代码里必须设置一个明确的上限不要在越权边界试探。更合理的做法是如果任务需要的数据量超过单次检索可访问的范围就把检索式拆分成多个时间片或主题子项分多次采集再合并。3.5 数据落地与编码处理所有记录收集完成后最后的落库环节我用pandas一步到位import pandas as pd def save_records(records, output_path): df pd.DataFrame(records) # 去除完全重复的行 df df.drop_duplicates(subset[doi, title], keepfirst) # 按被引次数降序排列方便后续阅读 df[cited_count] pd.to_numeric(df[cited_count], errorscoerce).fillna(0).astype(int) df df.sort_values(cited_count, ascendingFalse) # 使用 UTF-8 with BOM 编码防止 Excel 打开中文乱码 df.to_csv(output_path, indexFalse, encodingutf-8-sig) print(f[info] saved {len(df)} records to {output_path})这里的两个细节在不同项目里都帮过大忙一是utf-8-sig编码。直接保存成UTF-8Excel打开会识别成乱码加上BOM头之后Windows下的Excel和WPS都能正常显示中文。二是把被引次数转成数值类型再排序。WOS页面上有些字段提取下来可能是字符串带千分位逗号或者空值清洗后排序才能得到“被引次数最高”的列表。3.6 完整流程串联把上面的部分拼装起来一个最小可用的主流程大概长这样def main(): session setup_session_with_cookie(cookie_str) query TS(machine learning AND sentiment analysis) seen set() all_records [] for start in range(1, 101, 10): # 从1到100步长10共10页 html fetch_page(session, query, startstart, page_size10) records parse_results(html) for rec in records: if not is_duplicate(rec, seen): all_records.append(rec) print(f[info] page {start//10 1}, fetched {len(records)}, total {len(all_records)}) polite_sleep() # 简单终止条件如果某一页没有解析出任何记录说明到底了 if len(records) 0: break save_records(all_records, wos_results.csv)这段代码是骨架不是万能药。你最需要修改的地方是URL参数和页面选择器这两处必须根据你当前看到的具体页面来调整。怎么调用浏览器开发者工具的Network面板正常手动搜索一次看浏览器实际发出了什么请求再把这个请求的URL和响应HTML作为参照来改代码。4. 常见问题与排查技巧实录4.1 返回页面里找不到论文数据症状请求返回的HTML看起来是正常的页面标题和框架都在但解析出来的记录数是零。排查思路先在浏览器里打开同样的URL手动搜索一次然后看开发者工具里该请求的实际响应。WOS的搜索结果页有时候会走POST请求或者直接返回一个包含数据的JSON接口这种情况下用requests的GET方式拿不到列表数据。你需要找到真实的数据来源可能是一个隐藏的POST请求也可能是某个带token的XHR接口拿到它再在代码里构造同样的请求。另一个常见原因是Cookie失效或权限不足页面返回的是登录跳转页或机构认证页。这时候检查响应URL里有没有login/redirect之类关键字有的话优先更新Cookie。4.2 解析出的字段张冠李戴症状标题、作者、期刊名看起来都在但个别论文的DOI串到了标题里年份成了乱码。这很典型因为WOS的页面在不同浏览器宽度、不同登录态下渲染出的DOM结构不一样。我之前遇到过一种情况正常状态下每个论文块里只有一个DOI链接但某些论文没有DOI时页面会把空元素隐藏导致后续字段的选择器错位。解决思路分两层。第一层写选择器时优先使用稳定的属性标识比如style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" /> Python爬虫实战：合规采集Web of Science论文元数据
简介本资源是一个面向科研人员与数据工程师的Web of Science学术论文自动化采集工具基于Python开发解决人工检索效率低、批量获取元数据如标题、作者、摘要、年份、引用数困难等问题适用于文献计量分析、研究趋势挖掘及知识图谱构建等场景。压缩包共21个文件约100KB包含7个核心Python脚本如爬虫主程序cl.py、数据清洗脚本cl_deal_data.py、引用分析模块citaton.py、6个XML配置/项目文件、2个PYC编译缓存、1个README.md说明文档、1个城市编码txt及1个初始引用数据Excel表结构体现“采集—清洗—分析”完整链路。已有4125人学习下载提供可直接运行的多版本爬虫逻辑、配套数据处理函数及初步分析示例兼顾功能完整性与代码可读性适合具备基础Python与网络请求知识的用户快速上手并二次拓展至其他学术数据库。 你有没有遇到过这种场景在Web of Science里筛一批论文标题、作者、期刊、被引次数一条条手动复制到Excel再整理成表格一晚上就搭进去了。尤其做文献计量、综述或者追踪某个研究方向的同学这种重复劳动简直是在浪费生命。用Python写一个Web of Science论文爬虫就是为了把这些机械操作一次性自动化。这篇文章我会分享一套完整的实践方案覆盖从访问逻辑梳理、检索请求构造、页面解析到数据导出的全流程附带可复用的核心代码框架和我在实际跑项目中踩过的坑。它适合有一定Python基础、想上手真实爬虫项目的人参考也适合正在做科研数据整理、想把自己从复制粘贴里解放出来的朋友。一开始先把话说清楚本文只讨论合法合规的学术元数据采集。Web of Science是商业数据库爬虫程序必须运行在你具备合法访问权限的网络环境里采集范围限定于公开可浏览的题录信息不破解任何付费机制、不绕过人机验证、请求频率控制在正常学术使用范围内。搞清楚边界下面的所有技术方案才是安全且有价值的。1. 动手之前先确认需求和边界1.1 这个爬虫到底要解决什么问题很多人在GitHub上看到WOS爬虫项目就直接拿来跑结果要么被封IP要么抓回来一堆乱码。问题不在代码在于没想清楚自己到底要什么。先用一句话定义需求从Web of Science按照指定检索式抓取符合条件论文的元数据字段例如标题、作者、来源期刊、出版年份、DOI、被引次数输出为结构化表格。这里的关键词是“元数据”不是全文PDF。抓摘要、抓引文信息、抓参考文献列表这些都在元数据范围内抓全文、批量下载PDF那就越界了。在这个需求下你要采集的数据量基本可控一篇综述做文献调研两百到五百篇核心论文足够了做一个小型文献计量分析几千篇也算可观。如果你的目标是百万级数据那就不是爬虫能解决的问题该去申请Clarivate的官方API或数据许可这个后面我会专门说。1.2 Web of Science的访问机制与合规底线Web of Science不同于普通公开网站。它的内容分两层检索结果页需要有效访问权限通常由机构订阅或账号登录控制论文详情页则在结果列表基础上更进一步包含摘要、关键词、引用关系等。爬虫要做的就是在这两层里取公开可浏览的信息而不是用技术手段绕过身份验证。实际操作中有几个合规原则值得提前定死只在你有权限的网络内运行很多高校和科研机构本身就开通了WOS访问权限直接扫码或IP授权就能进。请求频率限制在“人手工操作不会引起注意”的范围内每次请求间隔两三秒以上大批量数据分时段采集。不研究绕过验证码的方案。遇到验证页面就停一下手动验证一次再继续这是平台的反滥用机制也是我们作为从业者该守的规矩。采集结果仅用于个人学术研究不做二次转售、不做商业用途。为什么要这么较真因为我在实际项目中见过反例有个朋友为了赶毕业论文的文献综述写了个脚本一口气抓了几万条数据结果不到二十分钟账号被标记连累整个课题组那几天的WOS访问都受影响。爬虫不是跑得越快越好稳定、合规、可持续才是核心诉求。2. 技术方案选型requests、BeautifulSoup、Selenium如何分工2.1 先判断页面是静态渲染还是动态加载Web of Science的经典版检索结果页是服务端渲染的也就是说你发送一个带正确参数的GET请求服务器直接返回包含完整论文列表的HTML页面。这种情况下Python的requests库加BeautifulSoup就足够完成任务完全不需要动用浏览器自动化。但新版界面和部分详情页不一样页面里有些模块是JavaScript异步加载的比如引用次数趋势图、部分扩展字段单纯用requests拿到的HTML里没有这些数据。这时候有两个选择一是在请求时找出背后的XHR接口直接请求数据接口拿JSON二是引入Selenium这样的浏览器自动化工具让真实的浏览器完成渲染之后再取页面源码。我的建议是分阶段处理总量不大、以标准字段为主的项目requests BeautifulSoup就够了涉及异步加载字段或者登录交互复杂的场景再用Selenium兜底。一开始就上Selenium往往是大材小用跑起来又慢又吃内存。2.2 别忽略WOS自带的导出功能说一句可能不太中听的话很多人问我要WOS爬虫代码但实际去现场一看他们连Web of Science自带的导出功能都没用过。WOS检索结果页提供标准导出支持直接将题录导出为Excel、纯文本、RIS等格式单批有数量上限但足够日常使用。所以我的方案选型里一直有个习惯先手动导出一批数据看看结构再决定要不要写爬虫。如果每次检索结果只有一两百条官方导出完全够用再用Python做数据清洗和字段合并就行了如果你要做自动化流程、要定时批量采集、要跨检索式合并多个数据集这个时候爬虫才真正派上用场。2.3 反爬策略的正确打开方式一提到反爬很多人第一反应是UA伪装、代理池、验证码识别这套思路在普通网站上管用在WOS这种学术数据库上反而是错误示范。WOS的核心防线不是技术性的而是访问权限和频率控制。你只要有有效权限正常频率访问根本不会被拦你需要做的反而是克制自己不要高频请求。以我实际的使用节奏为例连续抓取时每个请求间隔控制在3到6秒每抓取50条记录就停一两分钟单次任务总量不超过两千条。这样跑下来长周期内都不会触发任何风控。如果把这个“节奏”写进代码就是设置合理的time.sleep间隔、使用带有重试机制的请求函数、对429或403状态码做退避处理。代理池不是不能用但对WOS这种IP授权数据库来说频繁更换IP反而容易被判定为异常强烈不建议。3. 核心代码实现从检索到数据落地的完整链路3.1 环境准备与依赖安装先说环境。我这边用的是Python 3.10理论上3.8以上都没问题。需要安装的库包括pip install requests beautifulsoup4 lxml pandasrequests负责HTTP请求beautifulsoup4配合lxml解析器解析HTMLpandas负责最后的结构化导出。这里我特别说一下lxmlbs4默认的Python解析器在解析大页面时速度会慢很多换lxml之后速度能提升好几倍尤其是WOS检索结果页的HTML又是出了名的嵌套深、结构杂解析器的性能差距非常明显。如果你的环境里还需要模拟浏览器操作再补一个Seleniumpip install selenium配合你本机已安装的Chrome浏览器和对应版本的chromedriver使用。不过就像前面说的核心链路不建议全程用Selenium它更适合做登录态获取或者处理少数动态加载的场景。3.2 访问票据Cookie与登录态准备Web of Science的访问权限一般通过两种方式生效一种是你所在的机构IP在订阅范围内直接从校园网进入就不需要登录另一种是需要在登录页输入机构账号或通过统一认证跳转。第二种情况下爬虫程序必须携带有效的登录凭证。最稳妥的方式不是让爬虫代码自己走一遍登录流程而是让浏览器完成一次真实的登录然后把浏览器里的Cookie导入到requests的Session中。这样做的好处是绕开了验证码、CAS跳转、多因素认证这些琐碎环节而且登录态和你在办公电脑上的会话保持一致行为更像一个真实的活跃用户。这里有一段从浏览器Cookie构造requests Session的示例代码import requests # 从浏览器开发者工具中复制完整的Cookie字符串格式如 # SIDxxx; UIDyyy; ... cookie_str 你的Cookie粘贴到这里 session requests.Session() session.headers.update({ 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-Language: en-US,en;q0.9,zh-CN;q0.8, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, }) # 将浏览器Cookie解析成字典并覆盖进去 for item in cookie_str.split(;): if in item: key, value item.strip().split(, 1) session.cookies.set(key, value)代码本身没什么高深的核心是把Cookie字符串结构化注入Session。这里的注意事项是Cookie会过期尤其是一些学校统一认证的会话可能几个小时就失效了。我自己的习惯是每次运行爬虫前先做一个连通性预检用Session请求一次WOS首页或检索页如果返回的状态码不是200或者页面里出现登录跳转关键字就说明Cookie失效了需要去浏览器重新登录并更新。3.3 构造检索请求并解析结果页接下来是核心环节构造检索URL发送请求解析结果列表。WOS检索URL的核心参数包括数据库选择、检索式、每页记录数和起始页码。由于WOS的界面改版过多次这里我不写一个死板的固定URL而是给一个可以灵活改写的模板。import time import random from bs4 import BeautifulSoup def build_search_url(query, start1, page_size10): # 以经典检索页结构为例实际使用请根据抓包结果修正参数 params { db: WOS, ts: query, # topic search 检索式 start: str(start), # 起始记录位置 pageSize: str(page_size), sortBy: relevance } # 这里用 requests 的 params 参数自动完成 URL 编码 return https://www.webofscience.com/wos/woscc/summary, params def fetch_page(session, query, start, page_size): base_url, params build_search_url(query, start, page_size) resp session.get(base_url, paramsparams, timeout30) resp.raise_for_status() return resp.text拿到HTML之后就到了解析阶段。不同版本的WOS页面结构差异很大不可能给一个一劳永逸的选择器但解析思路是通用的先找到承载论文列表的外层容器再在容器里逐条取出每一篇论文的信息块。以我最近一次解析的经验为例列表页中每篇论文的信息块通常包含标题、完整作者列表、期刊名称、出版年份、卷期页码、DOI、被引次数。这里给出一个相对稳健的解析框架实际字段定位需要你结合页面结构调整def parse_results(html): soup BeautifulSoup(html, lxml) records [] # 定位论文条目的容器按实际情况修改选择器 items soup.select(app-record) # 示例选择器请以实际页面为准 for item in items: try: title_el item.select_one(.title a) or item.select_one(.title) title title_el.get_text(stripTrue) if title_el else N/A authors_el item.select_one(.authors) authors authors_el.get_text(; , stripTrue) if authors_el else N/A source_el item.select_one(.source) source source_el.get_text(stripTrue) if source_el else N/A # DOI、年份、被引次数等字段按实际页面结构调整 doi_el item.select_one(.doi) doi doi_el.get_text(stripTrue) if doi_el else year_el item.select_one(.year) year year_el.get_text(stripTrue) if year_el else cited_el item.select_one(.citation) cited cited_el.get_text(stripTrue) if cited_el else 0 records.append({ title: title, authors: authors, source: source, doi: doi, year: year, cited_count: cited }) except Exception as e: # 单条解析失败不终止整体记录日志继续 print(f[warn] parse record failed: {e}) return records这里我特别想强调一个工程习惯解析环节一定要有异常保护。WOS页面经常出现个别论文缺少DOI、某条记录的字段结构略有不同等情况如果因为一条数据就抛出异常导致整批中断后续的维护成本会让你怀疑人生。稳妥的做法是逐条try-except解析失败的记录打日志跳过最后统计失败率如果失败率异常高再去排查选择器是否失效。3.4 翻页、去重与频控策略WOS的高级检索结果可能成千上万条翻页逻辑其实就是一个起始位置递增的循环。需要处理好的问题有三个重复数据、请求节奏、最大页数限制。去重是很多人会忽略的点。多页抓取时可能出现同一篇论文被不同检索式命中、或者排序变化导致结果重复的情况。我建议在数据收集阶段维护一个以DOI或“标题年份”为键的集合每次解析完一批数据就先查重再并入最终结果def is_duplicate(record, seen): key (record.get(doi) or ).lower() or (record[title] record[year]).lower() if key in seen: return True seen.add(key) return False请求节奏是稳定性的生命线。一个过于激进的循环可能在几十次请求后就触发平台的风控机制。我在实际项目中固定使用的模式是随机间隔加定期暂停def polite_sleep(): time.sleep(random.uniform(3, 6)) # 每5次请求后额外停顿一小段时间 if random.randint(1, 5) 1: time.sleep(random.uniform(8, 15))关于最大页数限制WOS的检索结果并不是无限翻页的实际能浏览的记录条数有上限不同权限等级下差异较大。爬虫代码里必须设置一个明确的上限不要在越权边界试探。更合理的做法是如果任务需要的数据量超过单次检索可访问的范围就把检索式拆分成多个时间片或主题子项分多次采集再合并。3.5 数据落地与编码处理所有记录收集完成后最后的落库环节我用pandas一步到位import pandas as pd def save_records(records, output_path): df pd.DataFrame(records) # 去除完全重复的行 df df.drop_duplicates(subset[doi, title], keepfirst) # 按被引次数降序排列方便后续阅读 df[cited_count] pd.to_numeric(df[cited_count], errorscoerce).fillna(0).astype(int) df df.sort_values(cited_count, ascendingFalse) # 使用 UTF-8 with BOM 编码防止 Excel 打开中文乱码 df.to_csv(output_path, indexFalse, encodingutf-8-sig) print(f[info] saved {len(df)} records to {output_path})这里的两个细节在不同项目里都帮过大忙一是utf-8-sig编码。直接保存成UTF-8Excel打开会识别成乱码加上BOM头之后Windows下的Excel和WPS都能正常显示中文。二是把被引次数转成数值类型再排序。WOS页面上有些字段提取下来可能是字符串带千分位逗号或者空值清洗后排序才能得到“被引次数最高”的列表。3.6 完整流程串联把上面的部分拼装起来一个最小可用的主流程大概长这样def main(): session setup_session_with_cookie(cookie_str) query TS(machine learning AND sentiment analysis) seen set() all_records [] for start in range(1, 101, 10): # 从1到100步长10共10页 html fetch_page(session, query, startstart, page_size10) records parse_results(html) for rec in records: if not is_duplicate(rec, seen): all_records.append(rec) print(f[info] page {start//10 1}, fetched {len(records)}, total {len(all_records)}) polite_sleep() # 简单终止条件如果某一页没有解析出任何记录说明到底了 if len(records) 0: break save_records(all_records, wos_results.csv)这段代码是骨架不是万能药。你最需要修改的地方是URL参数和页面选择器这两处必须根据你当前看到的具体页面来调整。怎么调用浏览器开发者工具的Network面板正常手动搜索一次看浏览器实际发出了什么请求再把这个请求的URL和响应HTML作为参照来改代码。4. 常见问题与排查技巧实录4.1 返回页面里找不到论文数据症状请求返回的HTML看起来是正常的页面标题和框架都在但解析出来的记录数是零。排查思路先在浏览器里打开同样的URL手动搜索一次然后看开发者工具里该请求的实际响应。WOS的搜索结果页有时候会走POST请求或者直接返回一个包含数据的JSON接口这种情况下用requests的GET方式拿不到列表数据。你需要找到真实的数据来源可能是一个隐藏的POST请求也可能是某个带token的XHR接口拿到它再在代码里构造同样的请求。另一个常见原因是Cookie失效或权限不足页面返回的是登录跳转页或机构认证页。这时候检查响应URL里有没有login/redirect之类关键字有的话优先更新Cookie。4.2 解析出的字段张冠李戴症状标题、作者、期刊名看起来都在但个别论文的DOI串到了标题里年份成了乱码。这很典型因为WOS的页面在不同浏览器宽度、不同登录态下渲染出的DOM结构不一样。我之前遇到过一种情况正常状态下每个论文块里只有一个DOI链接但某些论文没有DOI时页面会把空元素隐藏导致后续字段的选择器错位。解决思路分两层。第一层写选择器时优先使用稳定的属性标识比如style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />