前阵子往自己的工具库里登记了一个编号为611的小项目批量把PDF导出为长图图片。起因是朋友遇到一个实际痛点——几十份产品手册要转成手机上好读的长图一页页截图显然不现实。PDF转长图这个需求听起来简单做起来却牵扯到渲染精度、版面拼接、批量文件处理、内存控制一堆细节。这篇文章就把我从方案选型到落地脚本的全过程拆开讲清楚内容覆盖三种主流做法Python脚本批量处理、桌面工具零代码操作、在线工具应急方案适合运营、编辑、教师、研发文档维护者以及所有被PDF阅读体验折磨过的人参考。1. 批量PDF转长图这个需求到底在解决什么问题1.1 一张长图解决了三类人的痛点身边需要“PDF转长图”的人远比想象中多。最常见的是手机阅读场景PDF在手机上打开要么需要左右缩放拖动要么字体小到眼睛酸扫描版论文更是灾难。转成长图之后微信里直接点开就能看双指放大也比PDF阅读器流畅得多不用额外装软件。运营和新媒体编辑是第二类高频用户。公众号配图、朋友圈分享、社群发资料都不适合直接丢一个PDF文件过去长图则可以像一张海报一样被浏览、转发和保存。很多企业把产品手册、技术白皮书、活动方案PDF转成长图分发到客户群阅读率明显比发文件高。还有一类是教师和培训讲师。课程讲义、PPT转出的PDF往往有几十页发给学员时一个个文件很麻烦拼成一张长图后“今天内容全在图里”复习时一拉到底体验完全不同。电商场景里商品详情页、资质证书、检测报告也经常需要以长图形式呈现。1.2 批量与单张的差异为什么非要“批量”单份PDF转长图最简单的方法是手动截图。手机上的滚动截屏虽然能截但清晰度不稳定经常出现重叠、漏页、条带模糊电脑端屏幕截图更是不适合长文档。更重要的是一旦文件数量到了十份、几十份手动操作的时间成本会变成灾难。批量的意义不只是“一次处理多份文件”而是要保证输出规则的统一所有长图使用相同的渲染分辨率、相同的页间距、相同的文件命名规范。这样后续做目录、归档、分发才会省心。举个例子批量处理几十份标书时如果每份输出尺寸参差不齐光整理就够耗一个下午。批量的另一个好处是离线可复现。脚本方式下今天处理一批三个月后来了同样格式的新文件把PDF丢进同一文件夹再跑一次命令输出格式和规则完全一致这是手动操作没法保证的。1.3 方案选型脚本、桌面工具、在线网站怎么选动手之前先对比了几条常见路线。方案批量能力分辨率控制隐私安全适用人群Python脚本PyMuPDF强全自动强随意指定DPI本地处理文件不出本机愿意装Python环境的同学桌面图形工具PDF补丁丁、WPS等一般一般本地处理不想写代码的零基础用户在线转换网站受限通常要会员弱固定DPI文件需上传涉密文档谨慎临时应急处理公开文档手机滚动截屏无批量能力差本地处理单份短文档随手操作我最终把主力方案定为Python脚本核心原因有三个第一PyMuPDFfitz模块是本地渲染PDF文件不需要上传到任何第三方服务器产品手册、合同、内部技术文档这类内容放网上转一圈心理上不踏实第二脚本可以直接控制DPI输出清晰度是可以复现的第三批量能力完全是脚本化的三十份也好、三百份也好跑命令就行。为什么不选pdf2image这个流行库因为它在Windows上依赖poppler组件安装配置比较折腾。PyMuPDF的渲染器是自带的pip安装之后立刻能用对Windows用户友好太多。在线工具则在最后留作应急选项。2. 把PDF变成一张长图核心原理并不难2.1 先搞清楚PDF的页面尺寸与DPI很多人不理解为什么转出来的长图有时候糊成一团问题基本都出在渲染分辨率上。PDF本身是矢量文档页面里记录的并不是像素点而是一系列坐标和绘制指令。把它变成一张位图必须指定一个“渲染密度”也就是DPI每英寸像素数。PDF的页面尺寸默认单位是point点1 point等于1/72英寸。A4纸的尺寸是210毫米×297毫米换算过来约595×842点。渲染成图片时像素宽高按这个公式算像素宽度 页面宽度点÷ 72 × DPI比如A4纸在150 DPI下输出宽度为595 ÷ 72 × 150 ≈ 1240像素高度为842 ÷ 72 × 150 ≈ 1754像素。PDF页面数越多纵向像素累加得就越长。这里给个经验值手机屏幕普遍是2倍到3倍分辨率150 DPI输出的长图在手机上放大查看基本够用文件体积也适中如果需要打印或者细节很多的技术图纸用300 DPI只是临时看个大概96 DPI也可以。我默认场景统一用150代码里做成参数随时能调。2.2 多页拼长图的两种拼接方式多页PDF拼成长图最常见的做法是垂直堆叠按页面顺序把每一页渲染成位图然后首尾相接纵向拼到一张画布里。这个方法最直观也最符合“长图”的阅读习惯。拼接时有一个容易被忽视的细节页面之间要不要留间距。紧贴拼接的图看起来像一整块翻页边界不明显浏览时容易串行我习惯在页面之间留20像素左右的空白视觉上能清晰区分每一页又不会有明显的割裂感。这个间距同样做成参数喜欢无缝拼接的设置为0即可。还有一种情况是页面尺寸不一。有些PDF里混着横版和竖版页面直接垂直拼接会导致长图宽度不统一。处理方式是取所有页面中的最大宽度作为画布宽度窄页面左对齐放置视觉上虽然不完美但能保证整张长图宽度一致。更精细的做法是统一缩放到固定宽度但那会改变原始版面比例我一般不推荐。2.3 内存占用估算为什么高DPI容易撑爆内存“多页拼长图内存不够、程序卡死”是我被问得最多的问题根源在于没算过内存账。一张RGB位图占用的内存大约是图片字节数 ≈ 宽 × 高 × 3A4纸在300 DPI下渲染出来是2480×3508像素单页位图约24.8MB。如果这份PDF有20页只在内存里存一个包含所有页的列表就是将近500MB。再加上拼接后的画布又是500MB总共接近1GB。普通办公电脑跑这种任务卡死太正常了。解决思路有两个方向一是把DPI从300降到150单页内存直接从24.8MB降到6.2MB20页全部缓存也就124MB体感完全不一样二是改变代码结构不把每一页的渲染结果存进列表而是先遍历一遍PDF拿到所有页面的尺寸计算出整张长图的宽高然后一边渲染页面一边拼接到最终画布上循环中产生的单页位图用完后就被回收内存峰值就只剩下“一页位图 一张长图画布”。后面给的脚本用的就是第二种方案。3. 实操三种方式把PDF导出为长图3.1 方式一Python脚本批量处理推荐全程本地运行先装环境。打开命令行执行pip install pymupdf pillowPyMuPDF负责把PDF页面渲染成位图Pillow负责拼接和保存图片。装好后新建一个Python文件把下面的完整脚本保存进去# batch_pdf_to_long.py import argparse import re from pathlib import Path try: import fitz # 兼容新版PyMuPDF except ImportError: import pymupdf as fitz from PIL import Image def natural_key(name: str): # 自然排序把文件名中的数字按数值大小排序避免 1、10、11、2 这种乱序 return [int(part) if part.isdigit() else part.lower() for part in re.split(r(\d), name)] def pdf_to_long_image(pdf_path: str, png_path: str, dpi: int 150, spacing: int 20): doc fitz.open(pdf_path) if doc.page_count 0: doc.close() return zoom dpi / 72.0 matrix fitz.Matrix(zoom, zoom) # 第一遍只读取页面尺寸不渲染避免把所有页面位图一次性放进内存 page_size_px [] for page in doc: rect page.rect page_size_px.append((int(rect.width * zoom), int(rect.height * zoom))) canvas_width max(w for w, _ in page_size_px) canvas_height sum(h for _, h in page_size_px) spacing * (len(page_size_px) - 1) canvas Image.new(RGB, (canvas_width, canvas_height), (255, 255, 255)) # 第二遍逐页渲染立即拼接到画布 y 0 for page in doc: pix page.get_pixmap(matrixmatrix, alphaFalse) img Image.frombytes(RGB, (pix.width, pix.height), pix.samples) canvas.paste(img, (0, y)) y pix.height spacing canvas.save(png_path, formatPNG) print(f[OK] {Path(pdf_path).name} - {png_path} f{canvas_width}x{canvas_height} {dpi}dpi) doc.close() def batch_convert(input_dir: str, output_dir: str, dpi: int 150, spacing: int 20): input_path Path(input_dir) output_path Path(output_dir) output_path.mkdir(parentsTrue, exist_okTrue) pdf_files list(input_path.glob(*.pdf)) pdf_files.sort(keylambda p: natural_key(p.stem)) if not pdf_files: print(没有找到任何PDF文件。) return for pdf_file in pdf_files: out_file output_path / f{pdf_file.stem}_长图.png try: pdf_to_long_image(str(pdf_file), str(out_file), dpi, spacing) except Exception as exc: print(f[FAIL] {pdf_file.name}: {exc}) if __name__ __main__: parser argparse.ArgumentParser(description批量把PDF导出为长图) parser.add_argument(input_dir, helpPDF所在目录) parser.add_argument(output_dir, help长图输出目录) parser.add_argument(--dpi, typeint, default150, help渲染DPI默认150) parser.add_argument(--spacing, typeint, default20, help页间距像素默认20) args parser.parse_args() batch_convert(args.input_dir, args.output_dir, args.dpi, args.spacing)脚本的核心逻辑分两遍。第一遍遍历PDF只读取每页尺寸是为了算出最终长图的总宽度和总高度第二遍才真正渲染页面渲染一页、拼接一页、释放一页内存占用控制得很好。运行命令python batch_pdf_to_long.py D:\PDF输入 D:\长图输出 --dpi 150 --spacing 20处理完成后输出目录里每个PDF对应一张PNG长图文件名是“原文件名_长图.png”。如果想把输出保存为JPG把脚本里的canvas.save(png_path, formatPNG)改成canvas.save(png_path, formatJPEG, quality88)后缀名同步改成.jpg即可。3.2 方式二Windows桌面工具零代码操作完全不想碰命令行的话桌面工具也能做。国产办公软件WPS自带“输出为图片”功能打开PDF后选择输出格式部分版本支持“长图”模式会把多页合并成一张长图导出操作路径是PDF编辑页面 → 输出为图片 → 选PNG/JPG → 勾选“长图拼接” → 确定。PDF补丁丁是开源免费的工具适合动手能力强的Windows用户。它的主要用法是把PDF页面导出为单张图片导出后还需要手动拼接。拼图可以用PowerPoint把所有图片按顺序插入同一页幻灯片纵向排列再把幻灯片空白边距设为0另存为图片就能得到一张长图。这个办法虽然绕但零代码也能出结果。注意区分概念很多工具的“导出为图片”把每一页导出为单独一张PNG而不是拼成一张长图。如果你的需求是把“整份PDF拼成一张长图片”一定要确认工具提供的是长图拼接模式。桌面GUI工具处理单份文件没问题但批量几十份的话你会怀念脚本方案的。3.3 方式三在线工具应急使用在线PDF转长图服务不少基本套路都是上传PDF → 选择输出长图 → 下载结果。对一份两页的公开文档应急用完全没问题。适合的典型场景是人在外面、手头电脑没有Python环境、文件不敏感、只需快速得到一张长图。在线方案的缺点也很明显。免费账户通常限制文件大小和页数批量处理需要开会员服务器渲染出来的图片几乎不给你调DPI的权限默认输出扩到手机上够用但想放大看细节可能会糊更重要的是文档内容要上传到别人服务器合同、报价单、内部技术资料这类文件尽量不要走这条路。我的做法是在线工具只处理公开的、不涉敏的文档工作资料一律本地跑脚本。宁可多花三分钟装环境也不把敏感文件交给第三方平台。4. 常见问题与排查技巧实录4.1 转出来的长图模糊这是遇到最多的问题十次里有八次是DPI太低。在线工具默认输出往往只有72 DPI在手机上全屏看似乎还行一旦放大就露馅。自建脚本时把DPI参数设到150如果原PDF里有高分辨率图片或精细线条直接上300。还有一种情况属于“救不回来”PDF本身是扫描件页面里的图片分辨率就只有100多DPI那渲染DPI设再高也只是放大原有像素不会凭空增加细节。遇到这种文件检查原始扫描参数重新扫描是唯一办法。判断方法很简单渲染出来的长图尺寸如果远小于理论值说明源头分辨率就低。4.2 多页拼长图内存溢出、程序卡死症状是运行到一半内存飙升最后报MemoryError或者系统无响应。原因就是2.3节说的一次性把所有页面的渲染结果全部缓存起来最后才拼接到画布。把代码改成“先算尺寸边渲染边拼”就能解决这也是我给的脚本默认的实现方式。如果文档特别长比如上百页边渲染边拼也可能顶不住。这时可以把一个PDF分段输出成多张长图比如每30页一张分别保存为文件名_第1-30页.png、文件名_第31-60页.png。或者把DPI从150降到120视觉差异不大内存减少三分之一。还有一种极端情况是PDF页面尺寸异常巨大那需要先检查这个PDF的页面设置是否正常。4.3 页面顺序不对批量处理时发现输出顺序是1、10、11、2、3典型的字符串排序问题。Path.glob()按文件名排序时10会排在2前面因为它是按字符顺序而不是数值顺序比较的。解决方案是自然排序代码里已经给了natural_key函数把文件名中的数字段提取出来按数值比较。更彻底的预防方法是在命名源文件时用零填充01.pdf、02.pdf……10.pdf这样即使用普通的字符串排序也不会乱。如果你手上已经有一堆顺序混乱但内容顺序正确的PDF建议先批量重命名再转换否则输出顺序乱了更麻烦。4.4 中文乱码或字体缺失用PyMuPDF处理绝大多数正规PDF不会有字体问题因为PDF里如果嵌入了字体渲染器会直接使用嵌入数据。问题出在两类情况一是PDF生成时没有嵌入字体只记录了本机字体名称换一台没有这款字体的机器渲染就会出现方块或替换字体二是服务器是精简Linux系统没有安装中文字体。排查思路先在Windows本地跑一遍如果正常说明PDF没问题如果同样乱码或缺字多半是PDF本身没嵌字。Linux服务器上执行fc-list | grep -i noto看看有没有中文字体没有的话安装fonts-noto-cjk。最好是在PDF生成端把“嵌入所有字体”选项打开彻底解决跨平台渲染问题。4.5 输出文件过大几十页PDF拼成一张PNG文件动辄四五十MB微信里根本发不出去。PNG针对的是无损场景对长图这种内容体积劣势很明显。最有效的办法是换保存格式JPG质量85体积通常能压到PNG的十分之一WebP更小但部分老设备兼容性一般。另一个思路是控制DPI。150 DPI是清晰度和体积的平衡点降到120会更小但手机上放大细节会弱一些。如果文档超过50页建议别拼成一张“巨无霸长图”分段成多张微信查看体验反而更好。故障现象常见原因快速解法长图模糊DPI过低或源头扫描分辨率不足DPI至少150文字版用300内存溢出所有页面一次性渲染缓存按脚本“边渲染边拼接”方式修改页面顺序错乱字符串排序缺陷用自然排序或源文件零填充命名中文乱码PDF未嵌入字体或系统缺字体生成端嵌入字体服务器装中文字体文件体积过大PNG无压缩、DPI过高换JPEG/WebP长文档分段输出5. 进阶玩法把批量转长图做成顺手的小工具5.1 批量命名与目录整理当文件数量多到一定程度输出目录会变成一锅粥。我习惯在脚本里把输出文件名做得更有信息量比如保留原文件名的同时增加页数标记产品手册_第1-12页_长图.png这种格式在归档时特别有用。页数标记可以通过doc.page_count拿到分段输出时则记录起始和结束页码。处理完成后还可以在输出目录自动生成一个convert_report.txt记录每份PDF的原始文件名、输出文件名、页数、图片尺寸、处理耗时方便出问题时溯源。这个报告在批量处理几十份文件时价值很大否则哪份成功哪份失败只能靠肉眼核对。5.2 加页码、水印、转灰度长图内容多了以后读者很容易找不到“我现在看到第几页”。可以给长图加上页码标记在每页底部或顶部用Pillow的ImageDraw写入“第X页/共Y页”字体用Windows自带的微软雅黑路径在C:/Windows/Fonts/msyh.ttc。Linux服务器上则用Noto Sans CJK的路径。水印的逻辑一样遍历长图上的每个页面区域在固定坐标写入半透明文字或Logo。处理扫描件时转灰度也可以用canvas.convert(L)再做保存文件体积能进一步缩小。这些功能加在脚本里都是几十行代码的事但使用体验会好很多。5.3 一键运行做个双击就能用的batPython环境装好之后把代码封装成双击即用的bat就能把“批量处理”这个能力交付给完全不懂技术的同事。新建一个pdf_to_long.bat内容如下echo off chcp 65001 nul python batch_pdf_to_long.py %~1 %~2 --dpi 150 pause调用方式是拖拽PDF文件夹到bat文件上再拖入输出文件夹路径按提示回车。还可以更进一步在bat里固定输入输出目录或者把脚本用PyInstaller打包成exe同事拿到后直接双击运行连Python都不用装。我给这个610多号工具库里的611号项目保留了一个固定习惯每次批量处理前先复制一份原始PDF到临时文件夹确认无误后再跑脚本。这样即使脚本参数填错或者输出结果不理想原始文件也永远不受影响。批量处理这种事宁可多一步备份也不要处理到一半发现源头数据被覆盖。