Reddit 討論串中關於依大小分割 PDF 的話題，幾乎總是以相同的建議作結:把檔案保留在瀏覽器中，並使用一款能測量每個部分實際位元組數的工具，而不是根據原始大小來猜測。Split PDF by Size 正是這樣做的。它完全在目前的瀏覽器分頁中執行，從您本機的 PDF 中複製頁面到候選文件，然後在將其接受為一個部分之前，序列化每一個以檢查其實際長度。您可以設定介於 0.01 和 25 MiB 之間的目標值，工具會在下一頁會使目前部分超過該目標之前，就開始一個新的部分。頁面順序被視為不可中斷，因此各部分包含原始順序中的連續頁面，其頁數總和永遠等於原始檔案的總頁數。來源檔案與產生的部分永遠不會離開瀏覽器，這表示沒有任何東西需要上傳、註冊，或交由第三方信任。這正是 Reddit 討論串一致推薦的本地化、重視隱私的做法，也是本文後續所有內容的基礎。
為什麼 Reddit 討論串持續推薦本地 PDF 分割工具
Reddit 的 r/PDF、r/privacy 和 r/sysadmin 社群經過多年，歸納出同一份 PDF 工具檢查清單:檔案保留在本地、無需帳號、不會靜悄悄地上傳到伺服器，以及在工具能直接測量時不要依賴估算。當有人發佈類似「分割 200 MB PDF 以利寄信的最佳方式」的討論串時，最熱門的回覆幾乎總是推薦瀏覽器型的分割工具，而不是桌面端安裝版或雲端服務。
這些原因一致且值得明說:
- 隱私。當本地替代方案能產生相同輸出時，法律合約、醫療匯出或財務報表不應接觸第三方伺服器。
- 速度。大型 PDF 在許多家庭與行動網路下上傳緩慢。本地處理完全跳過上傳步驟。
- 成本。對於一年只會用少數幾次的任務來說，訂閱制並不合理。
- 可攜性。瀏覽器型工具可在一台工作筆電、學校 Chromebook 或借來的電腦上運作，無需安裝任何東西。
Split PDF by Size 完全符合該清單上的每一點。它可在任何現代瀏覽器中執行，接受單一最大 25 MiB 的 PDF，並採用實測位元組數的方式，而不是從來源檔案大小粗略估算比例。
「依大小分割」實際上測量的是什麼
網路上大多數「依檔案大小分割」的工具，只是把來源檔案大小除以部分數就交差了。這種估算在兩個方向上都會出錯。內嵌一張大型圖片的 PDF 頁面，可能遠比只有一段文字的頁面重得多;而被複製的 PDF 資源可能跨頁共用、以不同方式壓縮，或在複製到新文件時被加上新的序列化器負擔。
這款工具避開了這個陷阱。瀏覽器會把頁面複製到候選文件，呼叫 PDF 序列化器，然後測量該候選文件的實際位元組長度。唯有在加入下一頁後，新序列化的長度仍維持在目標值以內時，才會加入該頁。當加入下一頁會使候選文件超出目標時，前一組就會被定案為一個部分，而下一頁則成為新部分的起點。
結果是誠實的:每個被接受的多頁部分，在建立當下，都有符合或低於所選目標的實際位元組長度。工具也會在結果畫面上顯示每個產生部分的大小，讓您在下載前可以檢視這些測量值。由於瀏覽器和作業系統的下載顯示可能以不同方式四捨五入相同的位元組數，螢幕上顯示的值才是值得信賴的。
如何在瀏覽器中依大小分割 PDF
- 在任何現代瀏覽器中開啟 Split PDF by Size。
- 從您的裝置中選擇一個不為空，且大小不超過 25 MiB 的 PDF。
- 以介於 0.01 和 25 MiB 之間的小數值，輸入每個部分的最大產生大小(例如 5 或 4.75)。
- 點擊 Split PDF by size 按鈕。
- 閱讀工具所顯示的任何單頁過大警告，並決定繼續作業或調整您的目標值。
- 依序下載每個編號的部分。所有部分的頁數加總將等於來源頁數。
如果您的輸入為空、大於 25 MiB、有加密、損壞、標示錯誤或不受支援，工具會顯示明顯的錯誤，並在任何下載連結發出之前停止作業。不會繞過密碼保護。
MiB 與 MB，以及 0.01 到 25 的目標範圍
本工具的目標使用 mebibyte(二進位百萬位元組)，其中 1 MiB 正好等於 1,048,576 個位元組。這是國際電工委員會(IEC)所定義的二進位倍數，也是大多數作業系統與電子郵件閘道以 MiB 回報檔案大小時所使用的單位。十進位百萬位元組(1 MB = 1,000,000 位元組)是另一種單位，在某個系統中描述為「5 MB」的目標，在另一個系統中可能代表不同的位元組數。使用 MiB 可讓計算保持誠實。
本工具接受到小數點三位數的輸入，因此 0.01 MiB 可用於小型文件的確定性測試，而 25 MiB 則對應本機檔案的大小上限。最小值適用於非常小的文件與測試;最大值則反映有界限的本機檔案工作流程。
| 目標 | 位元組 | 對應的十進位 MB |
|---|---|---|
| 0.01 MiB | 10,486 | 0.01049 MB |
| 0.1 MiB | 104,858 | 0.10486 MB |
| 1 MiB | 1,048,576 | 1.04858 MB |
| 5 MiB | 5,242,880 | 5.24288 MB |
| 10 MiB | 10,485,760 | 10.48576 MB |
| 25 MiB | 26,214,400 | 26.21440 MB |
由於瀏覽器和作業系統的下載顯示可能以不同方式四捨五入相同的位元組數，本工具也在每個下載連結旁顯示每個產生部分的大小，以便獨立檢視。
當單一頁面已超過目標時
單一的 PDF 頁面無法透過此工作流程被切割成更小的視覺片段，本工具也不會假裝可以。如果複製單一頁面就已產生大於您目標的 PDF，該頁會被保留為自己的單頁部分，且下載時會明確標示為超出目標。
這個例外存在有三個值得說明的理由:
- 它能避免靜悄悄的頁面遺失，因為該頁仍會出現在輸出中，只是放在一個被標記的檔案中。
- 它能避免無限的重試迴圈，因為沒有更小的頁面片段可以退而求其次。
- 它說出了事實:對讀者而言，一個被標記為過大的單頁，比一個遺失的頁面更有用。
如果下游系統拒絕接收被標記為過大的部分，實際的選擇是要調高目標讓被標記的檔案容納得下，或是先對來源執行專門的壓縮工作流程，然後再重新分割。
挑選適合工作的 Lizely 工具
Split PDF by Size 是圍繞一個問題所打造:每個部分應該是多少位元組?當真正的問題不同時，別的工具會更合適。
| 您真正的目標 | 最佳選擇 |
|---|---|
| 將每個部分限制在最大序列化位元組數內 | Split PDF by Size |
| 分割為相等的頁數 | Split PDF in Half |
| 將自訂的頁面範圍提取到新檔案中 | Extract PDF Pages |
| 分割為 N 個大致相等的頁數 | Split PDF |
| 縮減來源檔的總位元組數 | Compress PDF |
這些工具都不會上傳檔案。它們都以同樣的方式在目前的瀏覽器分頁中執行，因此選擇純粹取決於哪一款符合您真正需要完成的任務。
工具的內部運作原理
這項實作很直接，值得說明，因為它正是讓測量結果誠實的關鍵。瀏覽器會驗證一個有大小限制的 PDF 以及您輸入的小數 MiB 目標，接著依序走訪頁面清單。它會將每個頁面索引附加到候選文件，並在每次附加後序列化該候選文件，以便讀取實際的位元組長度。如果下一頁會使候選文件超出目標，先前的候選文件就會被定案為編號部分，而超出限制的那一頁會成為下一個候選文件的起點。過大的單頁會被保留為自己的、被標記的單頁部分，而不是重試，當整個走訪完成後，編號的下載連結就會開放。
用於測量的序列化器與最終下載所使用的序列化器相同，因此您在結果中看到的位元組長度，就是您實際收到的位元組長度。這套方法直接對應到 pdf-lib copyPages API 與 pdf-lib save API，這些是本工作流程所依賴的公開介面。
頁面框、旋轉、向量圖稿、文字以及嵌入的點陣圖內容，在現有複製作業所能支援的範圍內都會被保留。書籤、指令碼、附件、組合包關係、具名目的地以及跨部分連結等進階文件層級結構，一旦頁面被分割到不同檔案，可能無法保留其原始語意，因此在依賴這些部分之前，應檢查互動式文件。變更檔案或大小目標會撤銷先前的下載 URL，每次執行都以一個新的工作識別碼作為鍵值，因此同一分頁中較慢的先前作業無法取代較新的結果。
參考資料與延伸閱讀
本工具所建基的兩個底層 API 文件位於:pdf-lib API — PDFDocument copyPages，以及 pdf-lib API — PDFDocument save。如需本文所述同一套實測位元組方法的更深入說明，請參閱 Lizely 指南 Split a PDF by Size: A Local Browser Method，其中擴展了 Reddit 討論串持續浮現的本地化處理理念。
延伸閱讀:Split a PDF in Half: Scans, Spreads, and Two-Panel Layouts。