做资料整理的人肯定都遇到过这种情况手里一堆从各种渠道弄来的电子书或扫描文献后缀是.pdgWindows 图片查看器打不开PDF 阅读器也不认装一个专有阅读器呢只能一页页翻想检索、想打印、想批量处理都无从下手。PDG 这个格式在高等教育和学术资料圈子里出现频率不低很多学校的图书馆镜像、早期电子书资源都用它问题是它太封闭了。我自己也踩过这个坑。后来摸索出一条还算顺手的路先找工具把 PDG 的每一页释放成 JPG 图片然后用 Python 脚本把这些图片统一处理、按页码合并成一个标准 PDF。整个过程跑顺之后几十本电子书一次就能过完而且最终得到的是通用 PDF手机、平板、电脑上的任何阅读器都能打开直接解决了“格式绑架”的问题。今天这篇文章就是把这条链路从头到尾拆开讲清楚包括 PDG 到底是什么、为什么用这种两段式方案、脚本每个环节怎么设计、以及我实际用下来踩过的各种坑。1. 先搞明白 PDG 到底是个什么“怪物”动手之前强烈建议先了解 PDG 文件的底细。我见过太多人上来就直接搜 “pdg2pdf 工具下载”结果下载了一堆乱七八糟的软件不仅没解决格式问题还差点装上全家桶。其实只要理解了 PDG 的存储逻辑你就知道转换方案该怎么设计、哪些工具靠谱、哪些环节容易出问题。1.1 PDG 格式的出身与常见场景PDG 是超星数字图书馆采用的一种专有电子书格式早期的超星图书资源、部分高校图书馆的镜像资料、一些学术扫描书都使用这种格式。一个典型的 PDG 电子书实际上就是一个文件夹里面按页码存放若干个以数字命名的 .pdg 文件比如 000001.pdg、000002.pdg以此类推一本几百页的书就有几百个这样的文件。从内容本质上看PDG 又分成两种一种是“图像型”每一页其实就是一张扫描图经过某种私有算法压缩后存成 .pdg另一种是“文本型”底层带有 OCR 文字层理论上支持复制和检索。但不管是哪一种对普通用户来说PDG 文件不能直接被常规软件读取必须依赖超星阅读器或少数第三方工具才能打开这就导致了它的传播性和可用性都非常差。也正因为如此把 PDG 转成通用格式几乎是刚需。PDF 是最理想的归宿因为它跨平台、支持文字层、体积管理得当而且后续可以继续做 OCR、切分、合并、加密等各种操作。但这里有一个很现实的问题PDG 的解析算法没有公开的标准文档直接写代码解析完整格式并不现实更稳妥的做法就是避开复杂解析先把它转成开放、通用的 JPG 图片再走 PDF。1.2 为什么必须“先转 JPG再合成 PDF”而不是直接转 PDF很多人会疑惑为什么不能一步到位把 PDG 直接转成 PDF非要先弄成图片再合并这不是脱裤子放屁吗我在实际尝试之后可以负责任地说“先图后 PDF”是现阶段最稳、最通用的方案。原因在于 PDG 文件的读取链路太特殊。真正在处理 PDG 时靠谱的解码工具释放出来的内容形式就是图片也就是一页一张 JPG 或者 PNG这是大多数转换工具的通用输出格式。尤其是遇到图像型 PDG它本质上就是一张张扫描图解码之后的自然产物就是图片硬要跳过“图片”这个中间态等于自己去重写一遍 PDG 解码逻辑投入产出比极低。而且从工程角度看图片转 PDF 是极其成熟的领域img2pdf、Pillow、PyMuPDF 这些库都能处理中间还方便插入“预处理”步骤比如统一页面尺寸、调整压缩质量、给图片加页码水印这些操作在图片阶段做起来非常顺手。反过来如果某种工具号称“PDG 直接转 PDF”你反而要警惕它内部是不是偷偷经历了“解成图片再合成 PDF”的过程只是没跟你细说而已。1.3 动手之前先判断这条链路适不适合你不是所有 PDG 都适合用同一种方式处理动手之前先做个简单判断。首先看 PDG 文件有没有被加密或加密特征是否明显。部分早期超星资源带有加密校验解密失败时解码工具输出的图片会缺页、黑屏或者全是乱码遇到这种情况再牛的 Python 脚本也救不回来只能换思路。其次看页码是否连续。正规资源通常是 000001.pdg、000002.pdg 连续排列但有些资源是残缺的、乱序的甚至同一本书有好几个版本混在一起这种情况下直接转出来的 PDF 会页码混乱必须在合并前做排序纠偏。最后看你对成品的要求。如果只是阅读JPG 质量 75 到 85 足够PDF 体积会比较理想但如果要做精细化打印或者后期存档就尽量保持原始分辨率不要过度压缩否则图片锯齿感严重打印出来没法看。我的建议是默认走“原尺寸、中等偏上质量”的方案后续有特殊需求再单独调参不要一开始就把参数压得太狠。2. 转换链路怎么设计Python 在哪个环节发威明确思路之后下一步就是规划设计整条链路。PDG 到 JPG 再到 PDF看起来是两个步骤但真正落地时中间还有文件扫描、排序、预处理、参数控制、异常处理一大堆细节。把每个环节拆清楚脚本才不会写成“一次性玩具”。2.1 完整流程拆解解码、预处理、合并、收尾我在实际工程中通常把流程拆成四个阶段。第一阶段是“解码释放”把 PDG 文件作为输入借助成熟的解码组件把每一页导出成 JPG 图片放到一个指定目录第二阶段是“图片预处理”用 Python 扫描这个目录里的所有 JPG按照文件名自然排序然后根据需求做尺寸统一、质量压缩、格式规范化第三阶段是“合成 PDF”把处理好的图片按顺序喂给 img2pdf 或 Pillow生成一个完整 PDF第四阶段是“收尾检查”统计页码、PDF 文件大小、抽样检查页面方向发现问题就追溯到具体环节修复。这四个阶段里真正非 Python 不可的其实是“预处理”和“合成 PDF”。解码阶段我倾向于交给可靠的现成工具因为 PDG 格式私有性太强自己写 Python 解析代码不仅工作量巨大而且很容易在加密资源上翻车不值得。2.2 环境准备Python 和你真正需要的三个库环境准备并不复杂但有几个细节会影响后续使用。Python 建议装 3.8 以上版本我自己的主力环境是 3.10这几个库都兼容得很好。然后通过 pip 安装依赖基本上是三条命令pip install pillow pip install img2pdf pip install natsort三个库各司其职。Pillow 负责图片读取、尺寸调整、格式转换和重新保存img2pdf 负责把图片无损嵌入 PDF它的核心优势是速度快且不会对图片二次压缩适合档案级保留natsort 用来做“自然排序”处理 000001.jpg、000002.jpg、000010.jpg 这类文件名时能避免“字符串排序”带来的 1、10、2 错乱问题。有人问为什么不用 PyMuPDF 合成 PDF。PyMuPDF 也很强但它更适合做 PDF 的高级操作比如提取文字、渲染页面、添加注释单纯把一堆图片转成 PDFimg2pdf 在速度和保真上更直接而且依赖更轻。实际处理几百页的书img2pdf 通常一两秒就完成Pillow 批量保存反而更耗时。2.3 参数设计思路尺寸、质量和体积怎么平衡参数设计是整个流程的核心也是最容易踩坑的地方。先说图片质量JPEG 质量参数 quality 的范围是 1 到 95我处理扫描书时通常设在 80 到 88 之间。低于 75文字边缘会出现明显噪点尤其是扫描原件本身带底灰的时候压缩会把底灰变成马赛克高于 90文件体积飙升但肉眼几乎看不出差别对阅读场景毫无意义。再说页面尺寸。不同来源的 PDG 扫描页尺寸可能不一致有的页面被切成了奇形怪状的长条有的页面白边特别大。为了让 PDF 版式统一我通常会做个“限宽处理”超过设定宽度就等比缩放比如统一缩到 1600 像素宽高度按比例变化。这样既控制体积又保证文字清晰度效果接近原始版面。最后提一下“要不要转 PNG”。如果你对清晰度要求极高或者原图是图文混排的精细内容建议用 PNG 作为中间格式再用 img2pdf 合并。代价是中间文件体积会大很多几百页的书可能瞬间占掉几个 GB这时候记得给磁盘留够空间。我的实践经验是常规扫描书用高质量 JPG 就够了除非是古籍、图纸这类高精度资料才值得上 PNG。3. 核心实现从零组装一个可用的 pdg2pdf 脚本环境备好、参数心里有数之后就可以动手写脚本了。我提供的这套代码不是那种“一键复制就万事大吉”的玩具而是把四个阶段的关键逻辑都拆了出来你可以按需修改也可以直接跑通重点是理解每一步在干什么之后遇到问题才知道从哪里下手。3.1 第一步把 PDG 目录变成“标准图片集”第一步的核心目标拿到一个干净、按页码排列的 JPG 目录。我自己的做法比较务实先用老马的 Pdg2Pic 这类成熟工具把 PDG 文件“释放”成 JPG。这个工具在电子书圈子里名声很响它能处理大部分超星 PDG 资源输出 JPG 或 PNG操作界面虽然朴素但可靠性很高。如果你希望整个流程更自动可以让解码工具直接把输出目录固定成一个约定的文件夹比如 book_jpg然后 Python 脚本轮询这个目录等图片释放完毕后再开始合并。这一步没必要自己写 PDG 解析器浪费时间且不稳定。拿到图片目录后Python 的职责是扫描并排序。这一步的关键点在于严格按文件名自然顺序排列而不是默认的字符串顺序。我见过太多次 000010.jpg 被排到 000002.jpg 前面的情况就是因为忽略了自然排序。脚本里可以直接用 natsorted 解决import os from natsort import natsorted def scan_images(folder, exts(.jpg, .jpeg, .png)): files [] for fname in os.listdir(folder): if fname.lower().endswith(exts): files.append(os.path.join(folder, fname)) return natsorted(files)这个函数会在后面的步骤里反复用到。3.2 第二步按顺序扫描 JPG 并统一预处理拿到有序图片列表之后进入预处理阶段。这一步解决两个问题一是跨页面的尺寸和方向不一致二是部分图片过大导致 PDF 体积失控。预处理函数如下import os from PIL import Image def unify_image(src, dst_dir, max_width1600, quality85): im Image.open(src) im im.convert(RGB) if im.width max_width: ratio max_width / im.width new_width max_width new_height int(im.height * ratio) im im.resize((new_width, new_height), Image.LANCZOS) if im.height im.width: im im.rotate(-90, expandTrue) dst os.path.join(dst_dir, os.path.basename(src)) im.save(dst, JPEG, qualityquality, optimizeTrue) return dst这里有几个细节值得展开讲。我特意先转成 RGB是因为有些扫描图片是灰度模式或带透明通道的 PNG直接保存成 JPG 会报错或产生黑色背景。转成 RGB 之后所有图片统一进入同样的保存逻辑省去很多麻烦。旋转逻辑是可选的。有些 PDG 扫描件是竖排页面但导出时变成了横向放置static 旋转能统一阅读方向。我习惯判断“高大于宽”时旋转回正但这个规则不一定普适如果你手中的资料都是正向的把这部分删掉就行。图片缩放用的是 LANCZOS 重采样这是 Pillow 里质量最高的缩放算法比默认的 NEAREST 和 BILINEAR 好一截缩放文字类图片时边缘更平滑。代价是略微慢一点但对几百页的书来说这点时间完全可以忽略。3.3 第三步用 img2pdf 把图片合并成 PDF预处理完毕所有图片已经是统一的、按自然顺序排列的状态接下来就是合成 PDF。我用的是 img2pdf因为它本质上是把图片逐张嵌入 PDF 容器不重新编码图像数据所以无论多少页速度都很快而且画质零损失。import img2pdf def images_to_pdf(image_paths, output_pdf): with open(output_pdf, wb) as f: f.write(img2pdf.convert(image_paths)) return output_pdf看起来很短但它是整条链路的收口。img2pdf.convert 接收列表每一项是图片路径内部会按顺序读取并生成 PDF。这里有一个非常关键的注意点传入的列表必须是有序的而且是“你要合成 PDF 的最终顺序”。所以我在上一节强调自然排序就是为了这一步不出错。如果你不想做任何预处理直接以原始图片列表喂给 img2pdf 也可以但这样页面尺寸可能不统一PDF 看起来会参差不齐。我个人建议至少做一次尺寸统一阅读体验会好很多。3.4 完整脚本串联一步到位跑通全流程把上面的函数串成一个可执行脚本整个流程就清晰了import os import logging from natsort import natsorted from PIL import Image import img2pdf logging.basicConfig(levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s) def scan_images(folder, exts(.jpg, .jpeg, .png)): files [] for fname in os.listdir(folder): if fname.lower().endswith(exts): files.append(os.path.join(folder, fname)) return natsorted(files) def unify_image(src, dst_dir, max_width1600, quality85): im Image.open(src).convert(RGB) if im.width max_width: ratio max_width / im.width im im.resize((max_width, int(im.height * ratio)), Image.LANCZOS) dst os.path.join(dst_dir, os.path.basename(src)) im.save(dst, JPEG, qualityquality, optimizeTrue) return dst def images_to_pdf(image_paths, output_pdf): with open(output_pdf, wb) as f: f.write(img2pdf.convert(image_paths)) logging.info(PDF生成完成%s, output_pdf) return output_pdf if __name__ __main__: IMG_DIR book_jpg # 解码工具输出的图片目录 PROC_DIR book_jpg_proc # 预处理后的图片临时目录 OUTPUT book.pdf # 最终PDF输出路径 os.makedirs(PROC_DIR, exist_okTrue) pages scan_images(IMG_DIR) if not pages: raise SystemExit(没有任何JPG图片请检查PDG解码目录) processed [] for page in pages: processed.append(unify_image(page, PROC_DIR)) images_to_pdf(processed, OUTPUT)这个脚本已经满足大部分需求。如果你想要更精细的控制比如给每一页加页码水印、添加书签、合并多个文件夹可以在预处理循环里继续扩展。无论怎么改核心逻辑不会变先解出图片再统一处理最后合并。4. 实战踩坑实录问题排查与批量优化看完上面的代码你已经能跑通最基本的一条线了。但真实世界的资料处理永远不可能一帆风顺我在实际转换各种来源的 PDG 时遇到过的奇葩情况可以写满一页纸。下面这些问题如果提前知道能帮你省下不少时间。4.1 排序错乱和页码缺失你以为的“第2页”其实是“第10页”最典型的坑就是排序问题。文件名按字符串排序时000002.jpg 和 000010.jpg 谁在前取决于代码怎么写。我最初写的排序逻辑用的是 sorted 函数结果生成的书从第 10 页开始就全乱了跟原文对不上。解决办法一是在解码阶段尽量保证输出文件名带前导零二是脚本里用 natsort 做自然排序。如果源文件的页码本身就不连续比如缺了 000050.pdg那你需要在扫描图片后做个“页码完整性检查”统计实际页数与预期页数差多少并找出缺失的文件名。经验做法是打印扫描结果的前几页和后几页肉眼确认排序无误再往下走。4.2 加密、残缺 PDG 的处理当解码工具输出的图片全是黑的更糟心的情况是解码工具明明跑完了输出目录里也有几百张 JPG但打开一看满屏黑块、花屏、或者只有半页内容。这种通常是源文件做过加密尤其是早期超星格式带区域码或用户名校验时特别常见。遇到这种情况建议先做抽样检查不要直接拿着几百张坏图就去合成 PDF。如果确认是加密源文件可以试试换 Pdg2Pic 的不同版本或者检查一下电脑里有没有安装配套的超星阅读器及其专有解码环境老马工具在处理加密时有时依赖系统里有其他解码组件。但说句实话有些加密资源确实无解该放弃就得放弃不要在一个文件上耗太久。4.3 缺页或坏页导致 PDF 页码跳变怎么自动跳过并记录一种很实际的情况几百页的书里某两三页的源文件损坏了解码时直接输出了一张 0 KB 的空 JPG或者压根没输出。如果脚本不做任何容错img2pdf 读取坏图时会直接抛异常整个任务中断前功尽弃。我的做法是在扫描图片之后加一个“有效性过滤”步骤把文件大小为 0 或不是有效图片的文件剔除同时打印一条警告日志记录哪些页被跳过了。这样既不让脚本崩溃又能事后根据日志找回缺页决定是否单独修复。逻辑很简单def filter_valid_images(pages): valid [] for p in pages: if os.path.getsize(p) 0: logging.warning(空文件跳过%s, p) continue try: with Image.open(p) as im: im.verify() valid.append(p) except Exception: logging.warning(图片损坏跳过%s, p) return valid这个方法我很推荐尤其是批量处理几十本书时有了它就不用每本书都盯在电脑前看着了。4.4 批量处理多个文件夹的自动化扩展如果你的需求是处理一整个目录下的多本 PDG 电子书而不是单本那只需在外层加一个遍历逻辑。我通常的做法是外层遍历每个子目录发现里面存在 .pdg 文件就先把该目录交给解码工具处理等输出图片完成后调用上面的脚本生成一个按目录名命名的 PDF。批量处理最大的挑战不是代码而是磁盘空间和排队顺序。一台机器同时跑多个解码任务CPU 和磁盘 IO 都会被拉满反而拖慢整体速度。我的建议是一次处理一两本剩下的放进队列依次执行别贪多。4.5 常见问题速查表现象常见原因解决办法页码排序错乱文件名做了字符串排序使用 natsort 或补齐前导零输出 PDF 某页空白源 PDG 页损坏或解码失败检查源文件重新解码必要时删除坏页PDF 文件体积异常大JPG 保持高分辨率且未压缩用 unify_image 统一缩放质量降到 80 到 85页面方向横竖混排原扫描页方向不一致在预处理里加入基于宽高比的旋转逻辑图片全部黑屏源 PDG 加密或解码环境不完整尝试其他解码工具版本或更换资源生成 PDF 时抛异常传入列表包含非图片或空文件增加有效性过滤步骤剔除坏文件内存占用过高一次性读取过多高清图片使用 img2pdf 按路径直接读取不要全load进内存5. 从“能用”走向“好用”我的个人心得与二次加工建议这条链路跑通之后你其实已经拥有了一个可复用的 PDG 处理工作流。但每次用到它我都会根据自己的实际需求做些微调因为“能出 PDF”和“出一份好用、可检索、适合长期保存的 PDF”之间还是有一小段距离的。5.1 后续可以顺手做的三个增强第一个增强是 OCR 文字层。PDG 转换来的 PDF 本质上是纯图片 PDF文字不能被搜索和复制这对阅读体验影响很大。如果你手里的资料是文本型早期资源内容相对清晰可以在最终 PDF 上跑一遍离线 OCR用开源的 Tesseract 或 PaddleOCR 就能做到生成一个带文字层的搜索版 PDF。这一步并不是必须的但做完之后查阅体验立刻不一样。第二个增强是统一元数据和书签。用 img2pdf 生成的 PDF 没有目录书签对于几百页的工具书来说翻找章节非常痛苦。如果你愿意多花点功夫可以在合成 PDF 后用 PyMuPDF 给它加一个简单的目录树把每卷或每章的起始页定位到对应位置。这里的重点是提前维护好一份章节标题和页码的对应关系不要指望程序自动识别。第三个增强是“源文件归档”。我处理完后通常会把原始 PDG 目录单独保存转出来的 PDF 放另一端。很多人转完 PDF 就把源文件删了但一旦发现 PDF 有缺页或需要重新调参源文件没了就真的无解。磁盘不值钱资料重求才真头疼。5.2 关于“你该不该自己写脚本”的真心话最后说点掏心窝子的。网上其实有不少现成的 PDG 转 PDF 工具有的甚至是全自动的双击就用。那为什么我还要写一套 Python 脚本不完全是“代码洁癖”而是因为现成工具在黑盒环境下运行遇到问题你毫无办法脚本虽然初期搭建麻烦但每一步都透明可控而且遇到新的批量需求改改参数就能复用。如果你只是偶尔转一本书用现成工具效率更高没必要折腾环境。但如果你像我一样要处理一批又一批的文献资料那这套 Python 工作流绝对值得投资。我自己的体会是第一次搭建花了半个下午之后每次转换只需要填两个路径省下来的时间早就回本了。5.3 最后的最后一个细节个人经验里有一个很容易被忽略的收尾动作PDF 生成完之后随机抽翻几页确认页面顺序和方向没有异常。因为处理过程中即使有日志也难免有肉眼看不出的坏页比如某页误旋转了 90 度、某页是重复页。这些错误在阅读器里非常碍眼而修复它们却要重新走整条链路很麻烦。所以我的习惯是把 PDF 生成和“抽查”绑定成一个完整流程每次都少不了这一步。检查时也不用全看看一下开头十页、中间十页、结尾十页就足够了基本能覆盖绝大多数问题。这一趟下来PDG 这个“格式钉子户”也就算彻底拔掉了。