掃描檔縮小約84%，「新台幣」卻變「新台瘋」：SnapOtter 實測
重點摘要
- 2026-10-12第一輪自製三頁掃描PDF壓縮錄影顯示2711→433 KB，單次呼叫0.26秒，約減少84%。
- 第一輪自製圖片清除資訊後，ExifTool查拍攝位置、品牌、型號與作者四個欄位輸出0行，錄影計時0.29秒。
- 第一輪繁中公告文字辨識錄影3.72秒取得544位元組TXT，但有混入簡體與「新台瘋」錯字，未達直接交付門檻。
- 本次未使用付費API；人工比較時間、架設費用與電費未量測，不能換算實際省工或總成本。
- 結論： 本次壓縮與指定照片資訊清除取得成功結果；繁中辨識未達直接交付門檻。
- 適合： 需壓縮與清除指定照片資訊、能架設維護並檢查結果者（依本次樣本判斷）。
- 不適合： 期待此次繁中掃描文字可免校稿直接交付者。
| 實測項目 | 結果 |
|---|---|
| 測試日期與來源 | 2026-10-12第一輪 lab-snapotter-74ffc9，term-075852.mp4 |
| PDF壓縮（錄影） | 2711→433 KB，0.26秒；KB畫面標示採1024位元組 |
| PDF壓縮（另次API收據） | 2776507→443218位元組，0.25秒 |
| 照片指定四欄位 | 清除後查詢輸出0行，0.29秒 |
| 繁中OCR（錄影） | 3.72秒，544位元組TXT，有錯字 |
| 第二輪 | pnpm32.1秒完成；apt未完成，未取得功能成功收據 |
| 付費API/圖片/Veo | 本次未使用 |
| 人工省時 | 未量測 |
掃描公告明明只有三頁，寄送時卻被嫌檔案太大；想複製裡面的文字，滑鼠又選不到。成果能否使用，是另一個問題。這次試的是可以自己架設的檔案處理工具 SnapOtter：不用把樣本交給陌生轉檔網站，能不能少做一點事？
測試設備為 Mac mini M4 Pro（12核、64GB）。受測版本是 v2.2.0、commit 7af0ab6。本文所有功能數字與畫面都來自 2026年10月12日第一輪，不是第二輪成功。樣本是自製三頁繁中公告與一張合成圖片，沒有使用真人照片、客戶文件或私人資料。
檔案真的小了，但只代表這份樣本
公告以圖片組成，原始大小2,776,507位元組。品質參數40的壓縮收據輸出443,218位元組，約少84%；錄影另一個單次呼叫顯示 2711 KB→433 KB、0.26秒。畫面沿用KB標示，換算實際以1024位元組為單位。這是呼叫處理計時，不含架設、操作選單或人工檢查時間。
原檔本來就沒有可選取文字，壓縮也不會憑空生出文字層。既有收據另將壓縮頁轉成圖片，再用繁中文字辨識讀回，仍能讀到公告內容；這只支持這份樣本的可讀性，不能保證所有小字、印章或其他PDF都一樣清楚。
最快的結果，不一定能直接交付
同一份公告接著做掃描文字辨識。錄影顯示 3.72秒產生544位元組TXT，不是可搜尋PDF。內容混入簡體字，「新台幣」變成「新台瘋」，星期文字也有錯誤。
這次的可用門檻是公告能直接拿來閱讀、複製與交付；辨識結果未達門檻，仍要對照原稿。受測版本把zh連到chi_sim；同一頁另以chi_tra取得較正確文字，但不能算成SnapOtter已修好。
照片資訊清除，有明確但有限的收據
合成圖片先人工加入拍攝位置、相機品牌、型號和作者四個欄位。工具清除後，錄影計時0.29秒；再以ExifTool查相同四個欄位，輸出0行。原圖和結果都是3000×2000。這證明指定資訊在結果裡查不到，沒有證明照片畫面本身匿名化，也沒有遍查所有格式的資訊。
如何重現這次呼叫
下面是實測用的指令；snap是本次為計時、送出API與下載結果寫的測試包裝，不是官方內建指令。重現前須先啟動服務，完成登入及建立包裝；這不是安裝教學。
snap pdf/compress-pdf scan.pdf '{"mode":"quality","quality":40}'
snap pdf/ocr-pdf scan.pdf '{"language":"zh","engine":"tesseract"}'
壓縮與辨識須等完成事件並下載結果，不能把「已接受工作」當成功。
省工與費用，不能只看處理秒數
本次沒有使用付費API、生圖或Veo，但硬體、電費、架設與校稿都未換算費用。原預測的手動流程1至3分鐘並未實際計時，不能宣稱每份省了幾分鐘。第二輪套件安裝等待近40分鐘仍未完成，已停止並留存收據，沒有拿它冒充功能成功。
我的判斷是：經常處理檔案、有人能協助架設維護，這次壓縮和指定照片資訊清除結果值得考慮；偶爾只用一次，或要求繁中辨識免校稿，這次結果不支持推薦。先檢查成果，再談省工。
專案：snapotter-hq/SnapOtter。受測授權AGPLv3；商業版未測。