TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Caesium Image Compressor：開源圖片壓縮工具，照片留在本機壓縮的 TinyPNG 替代方案
Caesium Image Compressor 是 GPL-3.0 開源的桌面圖片壓縮工具，底層的 libcaesium 引擎在本機處理 JPEG、PNG、WebP、TIFF 與 GIF，壓縮過程不用把照片上傳雲端，並提供完整繁體中文介面。本文從原始碼、發布紀錄與 issue 追蹤整理它的能力、平台現實與幾個下載前要知道的限制。
用 AI 摘要這篇文章：
絕大多數免費圖片壓縮工具的運作方式是這樣的：你把照片上傳到它們的網站，伺服器壓縮完再傳回給你。 TinyPNG 、 Squoosh 這類服務方便，但代價是照片得先離開你的電腦。 Caesium Image Compressor 走的是相反的路：它是一套裝在你電腦上的桌面軟體，壓縮用自己的 libcaesium 引擎在本機做完，過程中照片不必交給任何雲端伺服器。這個差異聽起來平淡，卻是挑選壓縮工具時最根本的分界，後面所有優缺點都從這裡長出來。
Caesium 不是新面孔。專案從 2016 年開始，在 GitHub 累積超過六千顆星，作者 Matteo Paonessa 以 SaeraSoft 名義維護至今，目前桌面版是 v2.8.5 ，下一個大版本 v3.0.0 已在開發。它走 GPL-3.0 授權，是真正的開源軟體而非打著免費旗號的閉源產品，介面還有完整的繁體中文翻譯。以下整理它的核心能力，以及幾個會直接影響下載決定的現實限制。
本機壓縮和上傳型壓縮，差在照片要不要先交出去
要判斷 Caesium 值不值得裝，得先想清楚自己對「照片上傳」的底線在哪。上傳型的線上壓縮服務（例如 Squoosh 或 TinyPNG ）的運算發生在伺服器端，所以你的圖片檔案一定得先經過網路傳到對方機器，處理完再傳回。對部落格縮圖、要公開的素材這類不敏感的內容，這通常不成問題；但換成客戶提案稿、未公開的產品照、含個人資訊的截圖，把原始檔交給第三方伺服器就不是每個人都能接受的事。
Caesium 的桌面版把整條壓縮鏈搬進你的作業系統。圖片從硬碟讀進來、經過引擎運算、寫回硬碟，全程不離開你的機器。這不代表它完全沒有網路行為（後面會談到它其實有上傳與更新相關的網路功能），但「壓縮這件事本身在本機完成」是成立的。如果你的需求底線就是不想把原始圖交出去，那桌面壓縮工具是結構上唯一能保證這點的選擇，線上工具再強調隱私也改變不了檔案得過伺服器的事實。
壓縮的大腦是 libcaesium ，介面只是外層
很多人把 Caesium 想成一套「壓縮程式」，但拆開原始碼會看到比較清楚的分工。真正負責壓縮的是 libcaesium ，一個用 Rust 寫成、附帶 C 介面的獨立函式庫；你安裝的桌面應用則是用 C++ 加 Qt6 框架寫成的圖形介面，它呼叫 libcaesium 來做實際的運算。這個拆分不是技術細節而已：它代表壓縮核心是獨立可重用的，同一個引擎還驅動了命令列工具 CaesiumCLT ，甚至可以被其他程式當套件引入。
從 libcaesium 的文件可以看出它暴露的能力。除了基本的 compress 把單張圖壓縮成檔案，還有 compress_in_memory 直接處理記憶體裡的圖片位元組、以及 compress_to_size 把輸出壓到指定的目標大小（例如一百 KB 以內），後者對網頁素材要卡在特定檔案大小上限的情境很實用。支援的格式涵蓋 JPEG 、 PNG 、 WebP 、 TIFF ，以及部分 GIF 。值得注意的是桌面介面的 README 在「用途」段只列了 JPG 、 PNG 、 WebP 三種主流格式，TIFF 和 GIF 比較像是引擎層支援、介面未必全部開放出來的項目。
實際在介面上調整時，影響成品最直接的兩個參數是 JPEG 品質值與是否保留中繼資料。 JPEG 品質是一個零到一百的數字，設得越低檔案越小，但畫面也越容易出現壓縮區塊與色階斷層；一般網頁用圖落在六十到八十之間能在體積與肉眼品質間取得平衡，攝影作品若要保留後製空間則建議往八十以上設。 PNG 與 WebP 屬於無損或可調無損的格式，壓縮思路和 JPEG 不同，更適合線稿、圖示、有大面積純色的畫面。 Caesium 把這幾種格式的參數放在同一個介面裡，搭配壓縮前後的即時預覽，讓你一邊拖數值、一邊看到畫質變化，比單純填數字送出再等結果的工作流直覺得多。
格式支援與平台現實：三個平台境遇大不相同
壓縮格式之外，更影響下載決定的是它在你用的作業系統上能裝得多順利。 Caesium 桌面版官方提供三個平台的安裝包，但成熟度差距很大。 Windows 有安裝版和免安裝可攜版兩種，門檻最低，只要 Windows 10 build 1809 以後的 64 位元系統就能直接跑。 macOS 提供 DMG 安裝映像檔，系統要求 macOS 12 以上。
麻煩出在兩個地方。一個是 macOS 的 Apple Silicon 。目前的安裝包是 Intel 架構，在 M1 以後的 Mac 上得靠 Rosetta 轉譯執行，而 issue 追蹤已有人提出蘋果將在 macOS 28 停止支援 Intel 程式，屆時沒有原生 ARM 版本就會直接跑不動。換句話說，現在 Mac 用戶能裝，但這個能裝是有期限的。另一個是 Linux ：官方沒有提供預編譯的安裝包，你得自己用 CMake 加 Qt6 SDK 從原始碼編譯，或仰賴第三方社群編譯的 AppImage 。對不熟悉編譯流程的人， Linux 這條路的進入門檻明顯偏高。
授權與介面語言：兩個影響實際使用的訊號
授權是 Caesium 比多數同類工具硬氣的地方。它的 LICENSE 是 GNU General Public License v3.0 （ GPL-3.0 ），經 GitHub 授權 API 確認 spdx 識別碼為 GPL-3.0 。這代表你可以自由使用、修改、再散布，連商業用途都允許，代價是衍生作品必須沿用相同的 GPL-3.0 授權、並提供原始碼。和「免費但閉源」或「個人免費、商用收費」的工具比起來，這是授權條件最明確的開放程度之一，對想把壓縮能力整合進自己工作流程或產品的人特別有利。
介面語言是另一個實際的優點。 Caesium 的 2.0 版因為整組字串重新改寫，1.0 時代的社群翻譯無法沿用，等於從頭累積翻譯進度。從 README 的語言進度表可以看到，繁體中文（ zh_TW ）與簡體中文（ zh_CN ）的翻譯都達到百分之百，這代表完整的中文化介面，不需要在英文選單裡摸索品質參數或資料夾設定。搭配前述的 WebP 網頁圖片格式轉檔需求，對要做網站素材最佳化的人是順手的組合。
桌面版其實有網路功能，還有一個待修的 CVE
講完優點，有一個容易被「本機壓縮」這四個字掩蓋的事實必須說清楚： Caesium 桌面版並非完全沒有網路行為。從它的建置需求可以看出端倪， macOS 版的編譯需要 libssh （ SSH 連線函式庫）與 Sparkle （ macOS 應用程式自動更新框架），這暗示它帶有更新檢查以及某種透過 SSH 上傳壓縮結果的能力。實際上 issue 追蹤裡有一條標題明確寫著要為主分支回移（ backport ） CVE-2026-36365 ，涉及的程式碼範圍是 NetworkOperations 與 PostCompressionActions 兩個模組。
這則資安通報的具體細節，目前 issue 並未附上完整說明。從通報名稱與涉及的模組來看，問題出在壓縮完成後動作（ PostCompressionActions ）這段程式碼呼叫外部指令的方式，屬於本地指令注入一類的弱點，需要攻擊者已經能在你的電腦上執行程式才能利用，並不是一個能從網路遠端直接打進來的漏洞。即便如此，它仍透露兩件讀者該知道的事： Caesium 確實帶有壓縮完成後把結果上傳到指定伺服器的功能（這是 PostCompressionActions 的用途），而這段功能曾經需要資安修補。對把隱私當成核心考量的人，正確的理解是：壓縮運算在本機沒錯，但這套軟體並不是一座與世隔絕的離島，它有更新檢查與壓縮後上傳等網路相關功能。如果你要的是絕對零連線，得在設定裡關掉這些功能。
和其他壓縮工具的位置差異
把 Caesium 放回同類工具的地圖上，會比較好判斷它是不是你要的。線上壓縮服務（ Squoosh 、 TinyPNG 、 imgzilla 、 Recompressor 等）勝在免安裝、跨平台、開瀏覽器就能用，代價是檔案得過伺服器。 WordPress 外掛型的壓縮工具（例如 ShortPixel 、 Imagify ）把壓縮嵌進發布流程，自動處理上傳後的媒體庫，但綁定單一平台、且多半是訂閱制。 Caesium 桌面版的位置介於兩者之外：它獨立於任何網站系統，可以在圖片上傳到任何地方之前先把體積壓下來，適合需要在源頭控制檔案大小、又不想被綁進特定平台生態的人。
同樣是桌面壓縮工具， Caesium 的特色在於開源、跨平台、底層引擎獨立可嵌入。它的劣勢也同樣清楚：沒有雲端同步、沒有批次佇列的伺服器排程、不會自動幫你處理已經上傳到 WordPress 的舊圖。它是「把一堆圖丟進去、調好參數、一次壓完拿走」的離線工具，不是會自動跟著你工作流程跑的服務。想清楚自己要的是一次性的大量壓縮，還是常駐的自動最佳化，能幫你決定 Caesium 到底對不對。
| 工具類型 | 運算位置 | 授權與費用 | 批次與自動化 | 適合場景 |
|---|---|---|---|---|
| Caesium 桌面版 | 本機 | GPL-3.0 開源免費 | 手動批次、可設壓縮後動作 | 壓縮前控制、隱私優先 |
| 線上壓縮器（ Squoosh 、 TinyPNG ） | 伺服器端 | 閉源、多為免費或訂閱 | 單次上傳、有數量上限 | 偶爾壓幾張、免安裝 |
| WordPress 壓總型外掛 | 伺服器端或 API | 閉源、多為訂閱制 | 媒體庫自動處理 | 網站常駐最佳化 |
EXIF 中繼資料的取捨：壓掉體積，還要留什麼
壓縮圖片時有一個比壓縮率更常被忽略的決策點：要不要保留 EXIF 中繼資料。照片裡的 EXIF 記錄了拍攝時間、相機型號、鏡頭參數、 GPS 位置，甚至包含決定照片顯示方向的方向標記。 libcaesium 引擎提供 keep_metadata 參數讓你選擇保留或移除， Caesium 桌面版也把這個選項開放給使用者。保留中繼資料對攝影師整理作品庫、或需要回溯拍攝條件的人是必要的；但如果你要把照片放到公開網頁，移除 EXIF 既能再省一點體積，也能避免把拍攝位置或設備資訊一起曝光。
這裡有一個和前述已知問題相關的連動：前面提到直式 JPEG 轉成 WebP 時方向會被翻成橫式，根據 issue 回報，這正與 EXIF 方向資訊的處理有關。方向標記（ Orientation ）是 EXIF 的一部分，當轉檔過程沒有正確讀取或套用這個標記，相機原本記錄的直式構圖就會以錯誤的方向輸出。所以 EXIF 對 Caesium 來說，並非單純的「保留或刪掉」二選一，而是「哪些資訊要跟著壓縮結果走、哪些該在轉檔時被正確解讀」的技術課題，這也是 issue 追蹤裡有人請求把旋轉資料從其他 EXIF 中獨立處理的原因。會碰到大量直式照片的工作流程，值得特別留意這個環節。
已知問題與版本走向
一個有十年歷史的專案不可能沒有累積的已知問題， Caesium 的 issue 追蹤裡有幾條值得在下載前知道。有使用者回報 CMYK 色彩模式的圖片在壓縮時顏色會被破壞，這對印刷用途的圖檔是會直接毀掉成品的嚴重問題；也有回報直式（ portrait ） JPEG 在轉成 WebP 時方向會被翻成橫式，這牽涉到 EXIF 方向資訊的處理。另外 Linux 上的深色主題目前無法正常顯示。這幾條在 2026 年中仍開著、尚未解決。如果你的工作流程會碰到 CMYK 或大量直式照片轉檔，建議先拿非關鍵的圖測過再正式使用。
版本方面， v2.8.5 的發布說明明確標示「這可能是 v2 週期的最後一個版本」，作者已經開始投入 v3.0.0 的開發，要處理累積的大量建議與功能請求。 v3 是在既有基礎上的重整，不是砍掉重練，社群可以在專門的討論串參與方向。對現在要下載的人來說，這意味 v2.8.5 是穩定可用、但短期內大概不會再有新功能的版本；想要的新東西要等 v3 落地。專案並沒有停擺（ 2026 年仍有翻譯更新的提交進版），只是重心已經移往下一代。
適合誰，不適合誰
綜合以上， Caesium 桌面版最適合的是這樣的人：經手大量圖片、在意原始檔要不要交給雲端、希望對壓縮參數有細部控制，而且主力是 Windows 或能接受 Rosetta 轉譯的 Mac 用戶。它的本機壓縮、 GPL-3.0 開源、完整繁中介面，加上 libcaesium 引擎支援的多種格式與目標大小壓縮，對攝影師、網頁設計師、需要批次處理產品照或素材的電商工作者都是合理的工具。
反過來，如果你是 Linux 用戶且不想碰編譯，或你用的是 Apple Silicon Mac 且在意原生效能與長期相容，現階段的安裝包對你並不友善。如果你要的是會自動跟著 WordPress 媒體庫運作的常駐型最佳化，或是只想偶爾壓幾張圖、不想為此安裝軟體，那線上服務或平台外掛會比桌面工具更省事。還有一點要誠實講：官方網站另有一個線上版壓縮器（ caesium.app ），它的信任模型和桌面版完全不同，圖片一樣得先上傳到伺服器，別因為掛著同一個名字就以為它和桌面版一樣在本機處理。
最後給一個明確的判斷： Caesium 桌面版在「開源、本機壓縮、免費」這個組合裡是相當成熟的選項，十年累積的穩定度與完整中文化是它實實在在的優勢；但它不是沒有代價， ARM 原生版本缺席、 Linux 無預編譯包、一個待修的 CVE ，以及 CMYK 與 EXIF 方向的已知問題，都是裝之前要一起算進去的成本。如果你能接受這些，把它當成日常批次壓圖的主力工具是合理的選擇；如果這些限制正好踩在你的使用場景上，那等 v3 或先找替代品會更穩當。
