系统导出 93 份 PDF 报表怎么装订成册？批量改名、合并页码与双面打印的完整流程实测

月底要交的是一本册子，不是资源管理器里 93 个叫 export_20261103T080107_45564183.pdf 的文件。这类活儿的难点从来不在「合并」那一下，而在它前后三步：把机器生成的文件名换成人能读懂的名称，把几十份文件各自的页序接成一本连续的页码，以及让纸的正反面都印对方向。

PDF 合并指的是把多个 PDF 的页面按顺序搬进一个新文件、共用一套文档结构，页面尺寸、内嵌字体和注释都跟着页面走；它和「把文本拼在一起」不是一回事。本文用一批 93 份、232 页、17.04 MB 的导出件，把改名、合并、页码、双面、打包、校验六步在同一条链路上跑完，每一步都给本机实测的数字。

信息核验时点：2026-11-03（本机环境为 Windows 10 专业版 10.0.19045 内部版本 19045.6466 的一个非管理员账户，Microsoft Edge 156.0.4314.58，Windows PowerShell 5.1.19041.6456。文中 93 份报表 PDF 是用这台机器的 Edge「打印为 PDF」生成的替身文件，每页印有报表号、期间、页序与唯一标记，用来逐页核对内容有没有搬错、搬漏；改名、合并、拆分、奇偶页提取、打包、哈希、压缩七组操作全部在真浏览器里对本站工具页实际执行过，产物另用 pypdf 6.2.1.1 与 Python 标准库 zipfile 逐字节复核。引用的 PDF 规范为 Adobe 官方托管的 ISO 32000-1:2008 全文，抓取时该文件 HTTP 头标注 2026-10-26 更新；ZIP 规范为 PKWARE APPNOTE 6.3.9（2020-07-15 修订）。文中提到的本站工具页均为本站原创开发：PDF 合并与拆分 v3、ZIP 打包与解压 v2、文件哈希生成器 v3、PDF 压缩 v2、图片转 PDF v2。本机的双面结论有一处限制需要点明：这台机器只装了 Microsoft Print to PDF、Microsoft XPS Document Writer、传真和 WPS PDF 四个虚拟打印机，打印队列里没有支持双面的物理设备，因此双面部分给的是官方口径与文件级准备步骤，没有出纸照片。）

这 93 份文件是哪来的，为什么非要先处理文件名？

业务系统的「导出报表」按钮通常一次只给一个文件，而且文件名是机器口径：时间戳加一段随机十六进制。本次这批替身文件沿用的就是这个形态，93 个文件名都长这样：

export_20261103T080107_45564183.pdf
export_20261103T080214_6a5aaeae.pdf
export 20261103T082341 9c1f00ca (1).pdf

第三个是刻意留的：浏览器重复下载会给文件名加带空格的 (1) 后缀，这类名字在后面的脚本和命令行里最容易出事。93 份的基本盘是：三个区域各 31 类报表、共 232 页、合计 17,869,720 字节（工具页显示 17.04 MB），单份从 65,492 字节到 419,565 字节不等；按份数看，1 页的 41 份、2 页的 14 份、3 页的 11 份、4 页的 16 份、6 页的 11 份。

报表的页数不是随手来的，它由三件事共同决定，微软官方对每一件事都有原话。打印区域的定义是「一个工作表可以有多个打印区域。每个打印区域将打印为单独的页面」（设置或清除工作表上的打印区域，页面元数据 2026-01-23）；分页位置是算出来的，「Microsoft Excel 会根据纸张大小、边距设置、缩放选项以及你插入的任何手动分页符的位置插入自动分页符」（插入、移动或删除分页符，元数据 2025-10-15）；缩放则可能只压住宽度，调整工作表大小以适应一页 里写着「列现在将显示在一页上，但行可能会扩展到多页」（该句出自缩放工作表，元数据 2025-10-07）。

这三句合起来是一条实用结论：同一份报表换打印机、换纸张、改缩放，页数就会变。所以装订前第一步不是合并，是把「文件名对不上、页数对不上」这两件事先钉死。这一步的来龙去脉本站在网页另存为 PDF 全是错位：浏览器打印为 PDF 的六个坑与三种可靠替代里逐条实测过，本文不再重复。

为什么改名要在合并之前做？

三个理由，都能当场验证。

第一，产物名跟着第一份文件走。本站PDF 合并与拆分的合并输出名是「第一份文件的基础名 + _合并_ + 份数 + 份.pdf」，而基础名要先过一遍清洗：反斜杠、冒号、星号、问号、双引号、尖括号、竖线和空白一律换成下划线，并且截到 40 个字符。93 份改名前后各跑一次，产物名分别是 export_20261103T080107_45564183_合并_93份.pdf 与 01_华东区_销售月报_2026-10_合并_93份.pdf。第二份名字能一眼看出是哪本册子，第一份不能。

第二，文档标题也会跟着第一份走。合并稿的元数据里 /Title 是 华东区 销售月报 2026-10，即列表第一份文件自带的标题。这里要留一句实话：合并时元数据保留哪一份，PDF 规范和微软官方都没有口径（Adobe 的相关帮助页本次抓取全部被 403 挡住，微软侧没有 PDF 合并功能的帮助页），所以「以第一份为准」是本站工具页的实测行为，不是规范要求。

第三，排序会先在你眼前乱一次。微软官方对「按数字比较字符串」能查到的现行载体是 API 文档 StrCmpLogicalW function（页面元数据 2018-12-05，2024-02-22 更新），原话是「Digits in the strings are considered as numerical content rather than text」，同一页还给了免责句「Behavior of this function, and therefore the results it returns, can change from release to release. It should not be used for canonical sorting applications.」流传很广的那篇 KB 174513 现在直接返回 404，正文无法核实。到了 PowerShell 这边，Sort-Object（元数据 2026-01-18）的参数里只有 -Culture，没有任何自然排序开关，官方给的数字序做法是手工转整数：Sort-Object {[int]$_}。

结论很朴素：序号一定要补零。1_、2_ 一直到 93_ 在任何排序口径下都稳定，报表1、报表2、报表20 就不一定。

Windows 给文件名划了哪些线，越过会怎样？

批量改名前先摸清底线，全部出自微软官方两页文档。

Naming Files, Paths, and Namespaces（元数据 2024-08-28，2025-04-11 更新）列了九类保留字符：小于号、大于号、冒号、双引号、正斜杠、反斜杠、竖线、问号、星号；另外整数值为 0 的字符和 1 到 31 的控制字符也不能用。同一页还有一条常被忽略的：「Do not end a file or directory name with a space or a period」——末尾的空格和句点看着能存，但资源管理器和 shell 不认。保留名清单是 CON、PRN、AUX、NUL、COM1 到 COM9、LPT1 到 LPT9，并且「Also avoid these names followed immediately by an extension」，即 NUL.txt 也算命中；页面注释还补了一句更冷的：八位 ISO/IEC 8859-1 的上标数字 ¹、²、³ 也被当成数字，所以 COM¹ 同样是保留名。大小写方面官方只说「Do not assume case sensitivity」，并指出 NTFS 支持 POSIX 的大小写敏感语义、只是默认不启用。

260 那条线管的是路径不是名称：Maximum Path Length Limitation（元数据 2024-07-15）写的是「the maximum length for a path is MAX_PATH, which is defined as 260 characters」，单个名称段的常用上限 255 官方措辞是「this value is commonly 255 characters」，属于常见值而非硬承诺。想解除 260 限制要同时满足两个条件，官方原话是「A registry value must be set, and the application manifest must include the longPathAware element」。本机 HKLM\\SYSTEM\\CurrentControlSet\\Control\\FileSystem\\LongPathsEnabled 实测读回 0，也就是这台机器仍在 260 限制下工作。这两条线的细节本站另有提示路径太长打不开也删不掉怎么办？260 字符限制的三条实测解法和文件名里的 CON、NUL、尖括号为什么删不掉？两篇专文。

报表名还有一层隐形线：跨工具传的时候，编码会说话。微软官方在 Character Sets Used in File Names 里写「NTFS stores file names in Unicode」；而 ZIP 那边，PKWARE APPNOTE 6.3.9（Version 6.3.9，Revised July 15, 2020）附录 D.1 说历史格式只支持 IBM Code Page 437，D.2 说「If general purpose bit 11 is set, the filename and comment fields for this file MUST support The Unicode Standard ... using the UTF-8 storage specification」。中文名进压缩包变乱码，根子就在这位标志位上。

93 个文件名怎么一次改完？

系统导出文件名和装订名之间要靠一张对照表，而不是靠记忆。本次用的是一个 UTF-8 的 CSV，列头是序号、系统导出文件名、重命名后文件名、页数、字节、横竖向、正文标记，93 行数据；后四列是留给核对用的，改完名还能反查「这个名字原本是哪份」。

改名这一步本机用的是 PowerShell 5.1，把对照表喂给 Rename-Item：

Import-Csv -Path 'map.csv' -Encoding UTF8 | ForEach-Object {
    Rename-Item -LiteralPath $_.old -NewName $_.new
}

本机实测：93 个文件耗时 207 毫秒，跑完后再按 export_*.pdf 过滤剩 0 个，落盘的中文名逐字节正常（控制台里显示成乱码是 GBK 码页的显示问题，不是文件名坏了）。三个写法上的讲究都有官方依据。Rename-Item（元数据 2026-04-01）写明「This cmdlet does not affect the content of the item being renamed」，也写明不能靠它移动文件（「You can't use Rename-Item to move an item」，要移动加改名得用 Move-Item）；-NewName 只接受名称不接受路径（「Enter only a name, not a path and name」）；-Force 不能覆盖目标位置已存在的同名文件（「the cmdlet can't override security restrictions or replace an existing item at the destination name」），所以重名要靠对照表自己保证。官方示例第 4 条给的正是管道加脚本块的批量改名写法。

为什么不推荐在资源管理器里手点？因为「多选自增编号」这类行为在微软官方支持页里查不到表述——现行的 File Explorer in Windows（元数据 2026-02-07）关于改名只写了「You can find Cut, Copy, Paste, Rename, Share, and Delete at the top of the context menu」，历史那篇改名专文已被跳转成 Windows 10 停止支持公告。要图形界面就走官方有文档的那条：PowerToys 的 PowerRename（元数据 2025-01-23），官方定位是「a Windows bulk renaming tool that enables you to quickly rename multiple files at once」，并强调先在预览窗确认结果、改完可撤销。

九十三份里还有两个不守规矩的名字：一个带空格加 (1)，另一个长到 39 个字符。这两个正好用来验证清洗规则——改名阶段就把空格和括号处理掉，别留给后面的工具去猜。

在浏览器里合并 93 份 PDF，实际要多久、会不会丢东西？

本站PDF 合并与拆分是单文件纯前端页：文件在本机内存里被读取和拼装，不上传。九十三份一起拖进去，页面顶部统计条给的是 📁文件：93 📄总页数：232 📦合计：17.04 MB 🎯预计输出：1 个 / 232 页。

本机在真浏览器里跑了三轮，取的是页面上的时间戳差：

两个数字值得解释。一个是「读」比「合」慢不了多少：这份页面读文件是串行的，一次只解一份，93 份排队；界面上每行的状态徽章从「读取中」变「待合并」，全部变完之前「开始处理」按钮是灰的。另一个是产物只有 3.73 MB，而输入是 17.04 MB——差了 14 MB 的文件到底少了什么，这个必须查清楚，不然没法说「没丢东西」。

拆开逐类核对，结论干净：93 份源件里承载正文的内容流解压后合计 10,528,808 字节，合并稿里是 10,552,970 字节，不减反增 24,162 字节，多出来的正是 232 页页脚那行页码文字；承载字体的 186 个 FontFile2 流对象，两边存盘字节都恰好是 2,821,611——合并既没有重压字体，也没有跨文件去重，是原样搬过去的。缩下去的 14 MB 是每份文件各自那套对象字典和交叉引用表，合并后只留一套。反过来讲：合并省的是结构开销，不省内容，所以别指望用它给图片型报表瘦身。

内容有没有真少，用文本层核对更直接。93 份每份正文里印着一枚唯一标记（形如 R63TOK001 到 R63TOK093），合并稿 232 页逐页提取文字，93 枚标记一枚不少；打开「底部页码」后，232 页页脚从 1 到 232 连续、逐页读回完全等于页序。内嵌字体也保住了：合并稿每页仍引用 2 个 Type0 字体子集，和源件一致。

体积上限按本机实时可用内存算。这一轮页面上的提示写的是「单文件约 580 MB，整批合计约 2.83 GB」，换一台机器数字就变，别把它当常量。份数上也有一句提醒：文件多于 40 份且处于合并模式时，页面会弹出「文件较多时会依次占用内存，建议每批 20 份以内」。本次 93 份一次跑成功，但那是因为每份只有几十到几百 KB。

双面打印到底选哪一种：长边、短边、手动双面还是奇偶分打？

先把话说到底层。PDF 规范里双面是一个「查看器首选项」，ISO 32000-1:2008 全文（Adobe 官方托管，抓取时 HTTP 头标注 2026-10-26 更新）第 12.2 节 Table 150 给 /Duplex 列的取值只有三个：Simplex 是单面、DuplexFlipShortEdge 是短边翻转、DuplexFlipLongEdge 是长边翻转，默认值 none，且限定语是「The paper handling option that shall be used when printing the file from the print dialog」。同一页还有 /NumCopies（打印对话框打开时的份数）、/PrintScaling 和 /Direction。要特别提醒一句：常见二手资料里的 /DuplexNone 在这份全文中出现 0 次，单面就用 Simplex。

也就是说，PDF 文件能表达的是「建议怎么打」，落不落得了地看驱动。规范自己也留了口子：没有查看器首选项字典时，阅读器「should behave in accordance with their own current user preference settings」。微软侧把责任划得更明白，Print Schema 的 JobDuplexAllDocumentsContiguously（可见更新日期 2021-06-18）原话是「Automatic duplex is performed by hardware. Manual duplexing is performed by software and the user.」

「能不能选双面」也由设备决定。Word 官方中文帮助在纸张的两侧打印（元数据 2026-10-11）写得很直白：「在"设置"下，选择"单面打印"。如果"双面打印"可用，则打印机已设置为双面打印」，还补了一句「如果安装了多个打印机，则可能是一台打印机支持双面打印，而另一台打印机不支持」。本机的实际情况就是这条注脚：打印机列表里只有四个虚拟设备，逐一读它们的双面能力字段全是空值，所以本文不给出纸效果，只给能复现的文件级准备。

术语也要提前打招呼。长边、短边在微软官方中文页里有三种写法：DEVMODE 中文页写作「短边缘绑定」「长边缘绑定」（ns-wingdi-devmodea，可见日期 2024-11-20，机翻痕迹明显），Word for Mac 中文页写作「长边装订（在长端翻转页面）」「短边装订（在短端翻转页面）」，Publisher 中文页写作「双面打印 - 在长边上翻转纸张」。英文侧同样是 Long-edge binding 与 flip on the long edge of the sheet 两套口径。别照着某个软件的下拉文字去教别人，以你自己驱动里显示的那句为准。

真正能落地的两条路：

有自动双面能力：合并稿直接打，双面类型选长边。A4 纵向读物的翻页方向就是长边；横排台历、便签式竖翻才是短边。232 页按算术是 116 张纸（这是简单换算，规范里没有「N 页等于几张纸」的表述，但规范 14.11.2.1 明确区分了 page 与 finished sheet）。

只有单面打印机：微软官方给的路径是把奇偶页分两次打，Word 中文帮助原话是「在"设置"下，选择"打印所有页面"。在库底部附近，选择"仅打印奇数页"。打印奇数页后，翻转页面堆栈，然后……选择"仅打印偶数页"」。Publisher 那边对手动双面的描述更贴近动作本身：「打印机打印页面第一面的所有副本，然后暂停并要求您翻转刚刚打印的纸张并将它们返回打印机。然后打印第二面的所有副本。」注意这条路径里「先奇后偶」是应用程序分成两个作业来打的，不是打印队列内部的调度机制，官方没有把队列描述成奇偶优先。

分两趟打就要先把两摞纸准备好。用本站工具的「提取 / 删页」模式：页面操作选「保留所选页」，快捷芯片点「奇数页」，一次跑出 116 页、2,722,689 字节；清空选择框后点「偶数页」，另得 116 页、2,839,174 字节。两趟分别耗时 529 毫秒和 1,622 毫秒。这里有两个必须知道的实测结论：

1. 提取出来的两摞页脚仍是原始页码 1、3、5、7、9 与 2、4、6、8、10，页码不会跟着重新编排。所以奇偶分打前，先在合并那一步把连续页码加上，翻面时才有依据可查。
2. 奇数页跑完直接点「偶数页」会被拒绝。快捷芯片是对当前列表再筛一次，奇数页过滤后的列表里点偶数页，选中数为 0，处理不启动；而界面若不提示，很容易以为出了第二个文件、实际拿到的还是第一份（本轮就在第一次尝试时复现过这个假成功：两份产物字节一模一样是 2,722,689）。正确顺序是奇数页出完 → 点「清空框」→ 点「偶数页」→ 再跑。

要打成对折的小册子，页数还得是 4 的倍数。微软官方两页都写了这点：Publisher 的小册子设置（元数据 2026-01-01）原话「Microsoft Publisher will insert pages so that the total number is a multiple of four, because one sheet of paper becomes four pages」；Word 的制作小册子（元数据 2026-08-13）写明 Book fold 布局会自动把版式转成横向，成品尺寸是纸张宽度的一半。232 页正好是 4 的倍数，摊到 58 张纸。装订要留边的官方依据在 Word 的装订线边距（元数据 2026-10-11）：「装订线边距有助于确保不会因装订而遮住文字」。

横竖混排、页码与体积：装订前要处理的三件事

横竖方向。报表导出最常见的事故是某几份被排成横向页面，混进册子后翻到那页就要转本子。本站工具给每个文件一个整份旋转档位。实测取机器名那批的前 4 份，把第 2 份转 90° 后合并成 4 页，用 pypdf 读回产物第 2 页：/Rotate 是 90，页面框仍是 595 × 842。这说明转的是显示指令、没有重排页面内容——好处是不损画质，代价是某些严格的下游处理（比如按宽度裁剪、按坐标套打）仍要自己处理这 90°。

页码。合并那一步的底部页码支持自定义起始号，实测起始号 1 时 232 页全对。要提醒的是拆分与提取不加页码，页码只在合并输出上生效；想给奇偶两摞都带页码，就分两趟各合一次。

体积。文字型报表千万别走压缩那一步。本站PDF 压缩的做法是逐页重新渲染成位图再装回 PDF，实测把这本 232 页、3,907,636 字节的册子按「标准压缩 86 DPI」跑一遍，10,267 毫秒后得到 22,245,122 字节，页面统计条显示 📦原始：3.73 MB ✨压缩后：21.21 MB 💾节省：+469%，行内还有一条老实说明「正文重渲染后反而变大，这类文字型文档保留原文件更划算」。逐页取文字，第一页已经是空字符串——文字全变成图了，搜索和复制跟着一起没了。这台机器上该页的体积上限提示实时算到约 720 MB。压缩页真正适合的是扫描件、图片型 PDF；要压图，不如在源头把图片压了，本站图片压缩和图片转 PDF是干这个的。

如果这本册子要归档，规范层面有现成口径。Adobe 托管的 ISO 32000-1 前言写着「PDF/A (ISO 19005) is now the industry standard for the archiving of digital documents」，书目第 6 条给出正式名「ISO 19005-1:2005, Document management — Electronic document file format for long-term preservation -- Part 1: Use of PDF 1.4 (PDF/A-1)」。微软侧的对应说法更朴素：「PDF/A 有助于确保文档稍后在另一台计算机上打开时，其外观是相同的」（在 Office 中保存或转换为 PDF，元数据 2026-03-07）。至于 ISO 官网和国会图书馆那两页 PDF/A 介绍，本次抓取一律 403，所以以上两句的出处都指到 Adobe 托管文本，不要写成「来自 loc.gov」。

成品怎么发出去：打包与三个邮箱的体积分界

合并稿 3.73 MB，直接当附件发谁都收得下。要发的是那 93 份原件（比如财务要逐张存档），才需要打包。本站ZIP 打包与解压是纯前端打包，93 份实测 797 毫秒出包：

中文名这一栏值得单独看：用改名后的 93 份打包，产物 5,435,905 字节，逐条读回，93 个条目名的通用标志位第 11 位全部置起，也就是说全部按 UTF-8 声明，01_华东区_销售月报_2026-10.pdf 这类名字进包再出来仍然完整，testzip() 校验全对。这正好对上前面 APPNOTE 附录 D 那条：不设第 11 位就只能按 IBM Code Page 437 解释文件名。顺带一句，合并页拆分产物用的 ZIP 是另一条链路，条目名是 ASCII（book63_1-10.pdf 这种），标志位为 0，两种方式在这一点上不一样。

至于「一个 ZIP 最多能装多少」这类问题，官方口径要给准：经典上限来自字段宽度——尺寸字段 4 字节、溢出值 0xFFFFFFFF，中央目录条目数字段 2 字节、溢出值 0xFFFF（APPNOTE 4.4.9、4.4.21、4.4.22 逐字给的正是这套溢出说明），ZIP64 把同样字段扩成 8 字节。这是由字段宽度推得的，规范里没有「每包最多 65,535 条」这种命题式原话。至于民间常说的「Windows 压缩文件夹上限 65,536 个文件」，微软现行的Zip and unzip files（元数据 2026-06-04）通篇没有任何容量或文件数表述，历史上那几篇 KB（14158、300555、130594）现在都是 404——65,536 这个数没有可核的官方载体，别和 65,535 混着写。93 个 PDF 离这条线远得很，真正会让人卡住的是邮件上限：

• QQ 邮箱：「普通邮件附件最大为 50M，邮件正文加普通附件最大为 55M」，且「一天内可以发送的普通附件总大小最多是 200M」（帮助系统 479、帮助系统 79，两页都没有任何更新日期，只能写成「当前页面写的数字」）。
• 网易 163：「一般情况下，网易邮箱附件超过 50M 才转为超大附件」，普通用户超大附件「最大可上传 3G 文件（单个文件）」（帮助中心，页面无日期）。同站另有一张 2007 年前后的旧页写着「包括附件在内，您所发送和接收的邮件不能超出 15 兆」，那是遗留口径，别当现行。
• Outlook.com：「文件的附件大小限制为 25 MB」，「OneDrive 文件的附件大小限制为 2 GB」（Outlook.com 中的发送限制，元数据 2026-04-21）。微软另有一页写的是整体邮件口径「对于 Internet 电子邮件帐户，电子邮件大小限制为 20 MB」、Exchange 账户默认 10 MB，并注明「此限制包括附件的大小和电子邮件的大小」，两页数字口径不同，不能并成一句。

按本批实测数字对照：合并稿 3.91 MB 三家都能直接普通附件发出；93 份打包后的 5.44 MB 同样能直发；如果不压缩直接打包成 17.1 MB，QQ 和 163 的 50M 线内没问题，Outlook.com 的 25 MB 线内也过，但正文一长就贴着 20 MB 那条整体口径了。

怎么证明对方拿到的和发出的是同一本？

发之前先给整批算一遍指纹。本站文件哈希生成器零依赖，在本机读完就算 MD5、SHA-1、SHA-256、SHA-512 和 CRC32。这一轮把 93 份导出件加两个刻意放进去的重复样本（一个复制件、一个「重新导出」）一共 95 个文件拖进去，928 毫秒算完，页面统计 17.4 MB，导出报告 17,746 字节、477 行，每条带文件名、大小、MD5、SHA-256、CRC32 四行。

报告拿来一对，两对重复立刻现形：export_20261103T080535_a6d7f0f5.pdf 与它的 _副本 SHA-256 完全相同，export_20261103T081010_f38840bb.pdf 与 export_20261103T081050_重新导出.pdf 也完全相同。第二条是这里最有用的信息：同一份报表从系统里再导一次，只要内容没变，字节就是一模一样的——所以「我重新导过了」不该被当成新文件收进册子，认指纹比认文件名可靠。对方回传时同样用这页跑一遍，「比对」面板把两组哈希对一下，缺哪份、哪份被改过当场就能定位。这一步的成本在本机是 95 个文件合计 928 毫秒、平均每份不到十毫秒，而一次错发重来的成本是半个下午。

这条流程里实测踩到的六个坑

1. 加密的 PDF 会静默变成一页空白。造了一份加密报表：打开它需要口令，加密是 RC4 128 位（/V 2、/R 3、/Length 128），权限位 /P 是 4294967292，按 32 位有符号数读就是 -4，打印、复制、修改这几位全是 1——所以它不是「限制打印」那种，而是「不给口令就打不开」那种，文件只有 1,723 字节。拖进合并页时它没有弹口令框、照常读入、照常显示 1 页、照常进合并计划；产物里那一页用 pdf.js 渲染出来非白像素是 0 个（同一份产物里正常那页是 38,560 个非白像素、占版面 7.7%），用 pypdf 解那页内容流直接报 incorrect header check。上传区写着「加密文件请先去除密码」，页面 FAQ 里还写着「真正加密的会提示『文件已加密，请先去除密码』」，但本轮这份文件两条提示都没出现——它既不检测也不拦。合并 93 份册子时这种事故的表现是「册子少了一页内容」，而页数统计还是对的。
2. 坏件的提示是英文原文，而且不影响其它文件。一份被截断的 PDF 报错「读取失败：Failed to parse PDF document (line:25 col:1931 offset=399)」，一份扩展名改成 .pdf 的纯文本（39 字节）报同一类英文解析错。两轮下来 8 份里有 2 份标「失败」，剩下 6 份照样输出 6 页，成功提示只说「共输出 1 个 PDF」。要盯的是每行那枚「失败」徽章，不是提示条。
3. 奇偶页连着点，第二次跑的是上一次的产物。前面已经写过：快捷芯片是对当前列表再筛，奇数页过滤后的列表点偶数页得到空选择，处理不启动。必须先点「清空框」。
4. 提取之后页码不重排。奇数页那一摞页脚是 1、3、5，不是 1、2、3。翻面装订前页码必须先在合并那一步加好。
5. 合并稿的文档标题继承第一份。列表顺序一变，册子在阅读器标题栏、在检索系统里显示的名字就变。所以排序这一步要放在拖文件之前，别在合并界面里临时上下挪。
6. 页面切到后台会看起来卡死。这不是页面的问题：Chrome 对不可见标签页把 setTimeout 掐到几十秒一次，而这类逐页处理都要让出一帧。本轮第一次尝试时 93 份合并「五分钟没反应」，就是这么来的；把页面留在前台，同一批 5.5 秒就完了。跑大批量时别把这个标签页切走，也别在它旁边开视频。

一遍跑完的操作清单

1. 导出全部报表，先在 Excel 或 Word 里把打印区域、分页符、缩放钉死，让每份的页数稳定下来（本站另有WPS PDF 从入门到精通可以处理源文件那一侧的事）。
2. 用 UTF-8 的 CSV 建对照表，序号一律零填充；先对照命名底线过一遍非法字符与保留名。
3. Import-Csv 加 Rename-Item -LiteralPath 批量改名，跑完按旧名过滤确认剩 0。
4. 全部文件拖进PDF 合并与拆分，等每行状态都变「待合并」；顺手看一眼有没有「失败」徽章和可疑的极小文件（加密件的表现就是它）。
5. 检查列表顺序，打开底部页码，起始号设 1，模式保持「合成一份」，点开始，页面留在前台。
6. 产物用 pypdf 或任何一个能读文本层的工具抽查：总页数、每份的唯一标记、页脚是否连续、/Title 是哪一份。
7. 打双面：驱动支持就整本双面（长边）；不支持就先用「提取 / 删页」分趟出奇数页摞和偶数页摞，中间记得清空选择框。
8. 要归档或要发人，先算一遍哈希留底；93 份原件用ZIP 打包与解压压缩打包，中文名会带 UTF-8 标志位。
9. 附件按收件方邮箱的上限选路：3.73 MB 直发，5.44 MB 直发，超过 25 MB 就改共享链接。
10. 回传方收到后同一页跑一遍哈希，「比对」面板核对指纹。

工具之外的一步也不该省：这一整套里，浏览器只做得了本机之内的活，真正的批量改名靠的还是 PowerShell。要把这条链子接顺，先读在线工具清单：不用装软件，打开网页就能用看站内还有哪些页可用，再回头读字体嵌入解决「册子在自己机器上好看、在别人机器上变形」这最后一件事。