PDF 工具如何做到不上傳檔案就能處理 — 簡單說明

WebAssembly、pdf-lib，以及為什麼你的 PDF 可以在不離開電腦的情況下被合併或壓縮。

當網站說「您的檔案不會離開您的裝置」時，聽起來通常像行銷話術。但對於瀏覽器型 PDF 工具來說，這是字面上成立的——而能夠做到這件事的關鍵，就是 WebAssembly。

WebAssembly（Wasm）是一種精簡、快速的二進位格式，能夠在瀏覽器中以接近原生的速度執行。處理 PDF 所需的函式庫——編輯用的 pdf-lib、渲染用的 pdf.js、重新編碼內嵌 JPEG 用的 browser-image-compression——全部都會編譯成 JavaScript 或 Wasm，以幾百 KB 的程式碼隨頁面下載。當你把 PDF 拖到頁面上時，檔案會透過標準 FileReader API 讀進記憶體，交給函式庫處理，再以 Blob 的形式回傳給你下載。整個過程中，檔案本身完全不會發出任何網路請求。

這件事是可以驗證的。打開 DevTools → Network 面板，把一個 30 MB 的 PDF 拖到瀏覽器型工具上，仔細觀察：沒有 POST、沒有上傳流量、什麼都沒有。唯一的網路活動是首次載入頁面與 Wasm 套件，第一次造訪後就會被瀏覽器快取。

唯一的限制是記憶體。瀏覽器分頁跑在沙盒裡，有一個軟性的記憶體上限——桌面端大約 2 GB，手機更少。要把一個 500 MB 的 PDF 跟另一個 500 MB 的 PDF 合併，pdf-lib 在解析物件圖時，可能會暫時佔到 2–3 倍記憶體。在 16 GB 的 MacBook 上沒問題，但在 4 GB 的 Chromebook 上可能會讓分頁當掉。伺服器型工具沒有這個限制，因為他們真的有伺服器。

另一個取捨是某些特定工作的處理速度。對 200 頁掃描 PDF 做 OCR 很吃資源，瀏覽器中的 Tesseract.js 會比有 GPU 的伺服器慢。但對於合併、壓縮、JPG 轉 PDF 這三件 95% 使用者真正需要的事情，瀏覽器已經夠快，你不會察覺到差別。

對於所有跟隱私相關的檔案——薪資單、合約、就醫掃描檔、報稅文件——瀏覽器端處理不只是「附加好處」，而是唯一一種工具提供者根本看不到你檔案的架構，因為檔案根本沒有抵達他們的伺服器。

#webassembly #隱私 #原理