一款具備目標感知能力的 PDF 壓縮器，只有在儲存檔案的實際位元組數小於或等於您所輸入的 MB 數值時，才會提供下載。這項差異——將實際儲存的位元組與您的目標進行比對，而非僅從來源進行估算——正是將「經驗證的結果」與「近似結果」區分開來的地方。「壓縮 PDF 至指定大小」正是圍繞此規則而設計：它在瀏覽器中載入您的檔案，對符合條件的 JPG 串流執行一連串有界限的重新壓縮嘗試，儲存每個候選檔案，並將儲存的位元組數與目標進行比對。若沒有任何一個有界限的設定檔能產生小於或等於目標的檔案，該工具便不會顯示下載。沒有「近似」成功訊息，沒有僅相差幾百 KB 的下載，也沒有悄悄退而求其次給出比要求更小結果的行為。對於曾看過其他「壓縮至 X MB」工具默默交付別種結果的使用者而言，這道關卡正是整個工具的核心價值。
為何「壓縮至 X MB」的工具經常無法達標
大多數標榜目標 MB 輸出的 PDF 壓縮器，依賴的是粗略估算而非實際位元組數。最常見的捷徑包括：以任意比例除以來源大小、根據品質設定而非實際輸出宣告成功，或單純交付引擎所能達到的最佳結果並標記為「已達標」。搜尋「下載結果是否總能符合目標」的使用者，幾乎肯定曾被這些捷徑坑過——檔案標示為 5 MB，開啟後卻是 5.4 MB；或是滑桿提早停止，結果含糊不清。
所要求的目標與實際交付之間的落差，取決於如何衡量成功。一個以儲存檔案的實際位元組長度與目標進行比對的工具，其行為與僅將衍生估算值與來源比對的工具截然不同。只有前者能產生可驗證的答案，也只有前者能在安全範圍內無法達成目標時，誠實地拒絕顯示下載。同樣的邏輯正是為何 壓縮 PDF 至指定大小 圍繞單一規則而建：除非實際儲存的檔案小於或等於所要求的 MB，否則不會出現下載連結。
下載按鈕出現前會發生什麼事
驗證就是整個故事。當您載入 PDF 並選定目標後，「壓縮 PDF 至指定大小」會透過 Mozilla PDF.js API 中所記錄的 PDF.js 讀取器，在您的瀏覽器內讀取檔案，找出可安全重新編寫的 JPG 串流，並執行一連串有界限的重新壓縮設定檔。每個設定檔會以固定的 JPEG 品質與最長邊設定重新編碼符合條件的影像、儲存產生的 PDF，並將該候選檔案的實際位元組長度與您的目標進行比對。
四個設定檔依序嘗試：0.70/1400、0.55/1000、0.40/800，以及 0.30/600。當其中之一產生的儲存檔案位元組數小於或等於您的 MB 目標時，工具會重新開啟該檔案，驗證其頁數是否與原始檔案相符。若兩項檢查皆通過，下載連結便會出現。若四個設定檔皆未跨越目標，則不會提供下載，工具會告訴您該目標無法在安全範圍內達成。不會退而求其次採用最接近的嘗試結果、不會有「近似」標籤，也不會悄悄產生超出大小的結果。
如何將 PDF 壓縮至精確的目標大小
- 開啟「壓縮 PDF 至指定大小」，選擇一個不超過 25 MB 的本地 PDF。超過 25 MB 的檔案不在處理範圍內，如需處理較大的文件，請先分割或裁剪來源檔案。
- 輸入介於 0.1 至 25 MB 之間的目標值。目標必須小於來源檔案——本工具絕不會放大 PDF。一份 12 MB 內含 JPG 的報告可能目標設為 4 MB；一份 6 MB 的掃描合約可能目標設為 1.5 MB。
- 選擇「壓縮至目標大小」，並等待有界限的設定檔序列執行完畢。每個設定檔會透過 WHATWG canvas toBlob 規範中所描述的瀏覽器 canvas 管線，對符合條件的 JPG 進行編碼，儲存候選 PDF，並測量其實際位元組長度與您輸入的目標進行比對。
- 留意下載連結。它僅在候選檔案通過兩項檢查時出現：儲存位元組小於或等於目標，以及重新開啟的 PDF 頁數與原始檔案相符。
- 若未出現下載，工具會說明在有界限的設定檔範圍內，該目標無法安全達成。此時您可以稍微提高目標、換用不同的來源檔案重試，或閱讀下方的限制說明以瞭解原因。
所有處理皆在您的瀏覽器中進行，因此檔案永遠不會被上傳。唯一的網路活動僅為載入工具頁面本身。
工具不會產生下載的情境
即使請求有效，仍有三種情況不會產生下載。第一，PDF 為純文字或以向量為主，且無符合條件的 JPG 串流可供重新編寫。工具沒有可壓縮的內容，檔案大小無法朝目標靠近。第二，來源由工具不會處理的影像物件所主導——帶遮罩的 DCTDecode 串流、帶解碼參數的影像、CMYK JPEG，或非 DCT 格式（如 PNG、JBIG2 或 CCITT 編碼的掃描檔）。第三，所需的縮減量超出安全 JPG 重新壓縮所能達成的程度；即使在 0.30/600 這個最積極的有界限設定檔下，符合條件的串流仍無法縮減至您所輸入的 MB。
一份掃描型 PDF——其中每頁基本上都是由平台式掃描器產生的大型 JPG——通常擁有大量符合條件的串流，且往往能達到比混合文字與影像的混合型 PDF 更低的目標。一本包含向量圖表、字型子集以及少量內嵌 JPG 的教科書，通常只能達成有限的縮減，之後工具便會停止嘗試。該工具的設計將此種「停止嘗試」的結果視為特色而非失敗，因為猜測成功與否將違背驗證的承諾。
工具會重新編寫哪些影像，又會保留哪些影像
| 來源 PDF 中的影像物件 | 工具的處理方式 | 原因 |
|---|---|---|
| 無遮罩 DCTDecode DeviceRGB JPG，無解碼參數 | 以當前設定檔的品質與最長邊重新編寫 | 可安全重新編碼；視覺變化保持可預測 |
| 無遮罩 DCTDecode DeviceGray JPG，無解碼參數 | 以當前設定檔的品質與最長邊重新編寫 | 可安全重新編碼；視覺變化保持可預測 |
| 帶明確遮罩或 SMask 的 DCTDecode JPG | 略過 | 遮罩定義了編碼器無法安全保留的透明度 |
| 帶解碼參數的 DCTDecode JPG | 略過 | 解碼參數會反相或重新對應色彩；重新編碼將改變外觀 |
| CMYK DCTDecode JPG | 略過 | 工具僅處理 DeviceRGB 與 DeviceGray |
| PNG、JBIG2、CCITT、Flate 編碼的影像串流 | 略過 | 非 DCTDecode，因此不在此重新壓縮路徑的處理範圍內 |
| 會比其原始串流更大的候選 JPG | 在該影像中保持不變 | 工具絕不會放大個別影像串流 |
單次執行中，所有已解碼影像合計 80 個符合條件的影像與 100 百萬像素的上限，即是實際的天花板。一份每頁皆為單一大型掃描影像的 PDF，會被計為許多影像，但可能在前幾頁就用盡大部分的百萬像素預算。頁面結構、可選取的文字、連結、表單、向量以及不支援的物件在整個過程中皆保持不變，因此改變的僅有上表所列的 JPG 內容。
僅限本地端的處理及其對驗證的意義
PDF 讀取、JPG 解碼、JPEG 重新編碼、候選檔案儲存以及頁數驗證，皆在您的瀏覽器內完成。由於沒有任何資料被上傳，工具所測量到的位元組數，即是下載檔案將包含的位元組數。一個將檔案上傳、在遠端伺服器上壓縮、再回傳結果的雲端工具，無法保證本地下載的位元組長度與伺服器所測量的相同，因為傳輸過程中的中間重新壓縮可能使大小往任一方向偏移。
對於將本工具與其他「壓縮至指定大小」選項進行比較的使用者，實用的檢查清單很簡短：該工具是否以實際儲存的位元組數與目標進行比對？在安全範圍內無法達成目標時，它是否拒絕提供下載？驗證是否在使用者實際下載的同一個檔案上進行？「壓縮 PDF 至指定大小」滿足以上三點，這正是為何原始問題——下載結果是否總能符合目標——的答案是肯定的，因為這是由其設計所保證的。
有界限的設定檔如何使結果保持可預測
四個設定檔聽起來不多，但每一個都對應著真實的工程權衡。0.70/1400 設定檔能讓大型 JPG 在螢幕上保持清晰可讀，且在目標僅略小於來源時效果良好。0.55/1000 設定檔負責中間範圍，即需要縮減 30% 至 50% 的情況。0.40/800 與 0.30/600 設定檔則接管積極縮減，以及可接受細節損失的掃描文件。
由於工具會在第一個符合目標的設定檔處停止，接近目標的壓縮通常能在早期便成功，且幾乎沒有明顯的品質下降；而積極的壓縮則會跑完所有四個設定檔，之後才通過或拒絕。這種逐步行為正是使結果可驗證而非近似的原因：每個設定檔皆會產生一個可測量的儲存檔案，且工具僅在其中一個檔案小於或等於您要求的目標時才會停止。請保留您的原始檔案，並在文件忠實度至關重要時檢視結果，特別是針對混合文字與照片，或包含精細線條圖的 PDF。
若您正在權衡各種選項，將 PDF 縮減至 100 KB 目標：您需要知道的事對此有詳細說明。
若您正在權衡各種選項，壓縮 PDF 至指定大小時如何避免犯錯對此有詳細說明。