合併 PDF 而不把一切壓成影像

「把這五份 PDF 合併一下」可以指兩條管線。一條把既有的頁面物件串接成單一檔案，另一條把每一頁印成點陣圖，再把影像打包成一份新 PDF。兩者都產出一個附件，但只有前者保留可選取的文字與銳利的向量。

結構合併到底做了什麼

在 PDF123 上，合併 PDF 藉由接合每個檔案的頁面物件，把兩份以上的 PDF 合成一份。伺服器路徑用空白基底與 --pages 對輸入跑 qpdf：頁面串流是以頁的身分搬過去，不是螢幕截圖。內嵌字型、向量與既有書籤都跟著這些頁面一起走。這條路徑不會把任何一頁光柵化成影像，所以原生數位合約在合併後仍可搜尋、可複製。

預設的上傳順序就是輸出順序。HTTP 表單在同一次請求裡接受重複的 fileInput 部分；批次大小受上傳上限約束，沒有「最多兩份」的硬性上限。可選的 sortType=byFileName 會在接合前依檔名重排輸入。各來源的書籤可以保留下來；如果輸入本來就沒有大綱樹，合併不會憑空變出完整大綱。

單一檔案上傳，就是對該 PDF 原樣直通。兩份以上會變成一份 merged.pdf，頁面是輸入依所選順序串接的結果。OpenAPI、MCP 與 pdfx merge 暴露的是同一個 op id，所以腳本和瀏覽器點擊不會對「合併」這件事偷偷給出不同答案。

什麼時候會不小心光柵化

有些「合併」流程會先匯出成影像（傳真閘道、掃描 App、以螢幕解析度列印成 PDF），或者在接合前把註解壓平進點陣圖。檔案體積因此暴增、可能得重新 OCR，放大之後還會看到像素邊緣。

來源本來就是數位 PDF 時，請優先採用串流合併。只有當輸入是沒有可用文字的掃描件時，才用 OCR，並記住這裡的 OCR 回傳的是 Markdown（text/markdown），不是帶隱藏文字層的重新分層 PDF。先光柵化再 OCR，和合併原生數位檔案是兩條不同的產品路徑。

如果你要的是頁面影像，那是轉換工作（PDF 轉影像），不是合併。把這兩種意圖混在一起，「合併」結果就會變成好幾 MB 的文件相簿。結構合併之後再用 壓縮 仍能縮小串流，但它撤不掉你已經烤進去的柵格化。

合併不承諾什麼

合併不會統一頁面尺寸、不會跨檔案統一字型，也不會從零重建目錄。它不會替你解密已加密的輸入：來源有密碼保護時請先解鎖。它也不取代某些法院入口網站要求的 portfolio／套件容器格式，只產出普通的多頁 PDF。

這些限制和你用瀏覽器、REST、MCP 還是 pdfx 無關。這個 op 是刻意收窄的，好讓輸出對自動化保持可預測。如果你需要有序的多步工作（先合併，再浮水印，再壓縮），用 POST /api/v1/pipeline 傳一份有序的 steps 清單，而不是發明第二個「智慧合併」旗標。

怎麼執行

在瀏覽器裡用 合併 PDF，或向 POST /api/v1/general/merge-pdfs 送出重複的 fileInput 部分（開發者）。從命令列：

pdfx merge a.pdf b.pdf -o merged.pdf

或打到你自己的代管或自架 base：

pdfx --cloud --api-base "$API_BASE" --api-key "$KEY" merge a.pdf b.pdf -o merged.pdf

公網站上的匿名目錄呼叫不需要金鑰；金鑰是為了穩定的自動化身分，以及受控管的自架伺服器。同一個 op 如何經 curl 與 MCP 呼叫，見 同一操作，四種用戶端。