Python爬虫怎么爬取PDF文件_使用requests获取内容后保存流
requests.get() 返回的 content 怎么保存为 PDF 文件
这事儿其实很简单，核心就一句话：直接用 response.content 写入二进制文件。PDF本身就是二进制格式，千万别当成文本来处理。新手最容易踩的坑，就是把 response.text 或者经过编码转换的内容写进去，结果生成一堆乱码，或者一个根本打不开的“假PDF”。
具体操作时，记住这几个关键点：
- 务必用
'wb'模式打开文件，那个b代表二进制，绝对不能省。 response.content就是服务器返回的原始字节流，原封不动地写入最安全。- 虽然默认开启，但显式地加上
allow_redirects=True参数会更稳妥，确保能跟随重定向。 - 保存前，先检查
response.status_code == 200。这一步能帮你避免把404错误页面当成PDF存下来的尴尬。
import requests
r = requests.get('https://example.com/doc.pdf')
if r.status_code == 200:
with open('output.pdf', 'wb') as f:
f.write(r.content)
怎么判断响应确实是 PDF 而不是网页或错误页
光看URL的后缀名？那可太不保险了。有些服务的下载链接长得像 /download?id=123，但返回的却是正经PDF；反过来，有些链接以 .pdf 结尾，实际却返回一个要求登录的HTML页面。要准确识别，得靠双重验证：响应头加文件头。
- 第一重，检查响应头：
r.headers.get('content-type')里是否包含'application/pdf'（比对时忽略大小写更安全）。 - 第二重，检查文件头：标准的PDF文件，其前4个字节固定是
%PDF。用r.content[:4] == b'%PDF'可以快速验证。 - 如果这两条都不满足，那基本可以断定不是PDF。这时候，建议把
r.url（最终请求的URL）和r.status_code打印出来，排查一下是不是发生了重定向或者跳转到了其他页面。
大 PDF 文件下载中断怎么办：用 stream=True 配合 iter_content
直接读取 .content 会把整个文件一股脑儿全加载到内存里。对付小文件没问题，但遇到几百MB甚至更大的PDF，内存溢出（OOM）的风险就大大增加，而且网络一旦中断就得从头再来。流式下载才是解决之道，既能控制内存占用，也为实现断点续传提供了可能。
- 关键一步：必须在请求时加上
stream=True参数，否则后续的iter_content()将不起作用。 - 循环写入：使用
iter_content(chunk_size=8192)来分块读取数据，每次8KB是个比较通用的选择。块太小会增加I/O次数，块太大则失去了分块的意义。 - 关于断点续传：如果想实现更高级的断点续传功能，可以用
'ab'（追加二进制）模式写入文件，但这需要你自己管理已经下载的字节数，并在下次请求时通过Range请求头告诉服务器从哪里开始。
r = requests.get('https://big-file.pdf', stream=True)
with open('large.pdf', 'wb') as f:
for chunk in r.iter_content(chunk_size=8192):
if chunk: # 过滤 keep-alive 空块
f.write(chunk)
为什么保存后 PDF 打不开：常见陷阱汇总
代码明明没错，保存也显示成功，可文件就是打不开——这种问题最让人头疼。往往不是语法错误，而是环境或服务端的“隐形”行为导致的。下面这些陷阱，每一个都可能让你卡上半天。
立即学习“Python免费学习笔记（深入）”；
- 网站反爬机制：服务器返回状态码200，但内容却是Ja vaScript渲染的页面、验证码图片或者一段提示语。这时候检查
content[:4]，肯定不是b'%PDF'。 - 请求头缺失：部分提供PDF的接口会校验
User-Agent（用户袋里）或Referer（来源页）等请求头。如果你的请求头太简单或者缺失，可能会收到403禁止访问的响应，或者一个空白的回复。 - HTTPS证书问题：在内网环境或使用自签名证书的网站上下载，
requests库默认的SSL证书验证会失败。临时解决方案是添加verify=False参数（仅限测试环境），生产环境则应正确配置证书路径。 - 响应内容被压缩：如果响应头里包含
Content-Encoding: gzip，说明数据在传输中被压缩了。好消息是，requests默认会自动解压，所以你拿到的.content已经是解压后的数据，千万别再手动去调用gzip.decompress()了，那会画蛇添足。
最麻烦的情况，是程序没有任何报错，文件也成功保存了，但双击就是无法打开。遇到这种问题，最好的办法就是回头去检查原始响应：看看 response.content 的前几十个字节到底是什么，再仔细核对一遍 response.headers 里的信息，线索往往就藏在这里面。
