Comic2Books 漫畫轉 EPUB 工具，把 CBZ 直轉進 Apple Books

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

手上一堆 CBZ 或 PDF 漫畫檔,想搬進 Apple Books 或電子閱讀器,中間缺的就是一個轉檔器。Comic2Books 做的就是這件事:一個給 macOS 用的免費開源應用,把 ZIP、CBZ、RAR、CBR 與 PDF 轉成 EPUB。我在 2026 年 10 月 8 日把官方最新的 0.4 版下載包解開,用它內建的轉換引擎、照介面的預設參數實際轉了一本 6 頁的測試漫畫,261 毫秒完成,輸出一份結構完整的 EPUB;3 頁的 PDF 也照轉,58 毫秒。先給結論:轉換本體沒有問題,值得裝。但同一顆引擎,在 2024 年 7 月到 2025 年 9 月之間的官方下載包裡,於 Apple Silicon 的 Mac 上一次也轉不出來,介面照樣宣布完成,資料夾卻是空的。這件事的根因,是我把兩代下載包分別解開、對引擎二進位檔下了 file 指令才釘死的:0.2 版裡那顆名為 silicon 的引擎,其實編成了 Intel 架構。這篇文章把轉換本體、安裝會遇到的關卡,以及這個專案單人維護的節奏,一次攤開給你看。

轉換本體:6 頁 261 毫秒,輸出也檢查過

先交代我的測試位置,這決定你能相信哪些話。我的實測落在引擎與打包層:下載 0.2 與 0.4 兩代官方 zip、驗簽章、解開包裝,然後直接呼叫 0.4 包內的轉換引擎,參數完全比照介面原始碼裡的組法;視窗介面本身則以原始碼與官方釋出的畫面核對,沒有逐頁點按。這樣的分層不影響結論的可信度,因為在這個程式裡,轉換工作全部是引擎在做,介面只負責把選項組合成參數。

Pin

測試檔是一本自製的 6 頁漫畫:一張封面、四張單頁,外加一張 2144 乘 1448 的雙頁跨頁,包成 CBZ。轉換 261 毫秒結束,輸出 29KB 的 EPUB;把 EPUB 解開,封面、書名頁、逐頁 XHTML、樣式表一應俱全,包裡還有一份 Apple Books 專屬的顯示設定檔。PDF 那邊,3 頁的測試檔 58 毫秒轉完,封面與內頁都在。短文件就開滿 16 條工作線、吃掉約 317MB 記憶體的排法,對幾百頁的整卷漫畫是好事,對小檔案則顯得殺雞用牛刀,僅供參考。

輸出的圖片尺寸透露了一個規則:標準解析度檔位是 1200 乘 1920,但我那些 1072 寬的單頁原封不動保持了原尺寸,2144 寬的跨頁則被縮到 1200 寬。也就是說,縮放只往下、不往上,你的原始解析度若已經低於檔位,它不會硬拉大。對掃描品質參差不齊的老漫畫來說,這是合理的保守行為。

雙頁跨頁會輸出三張,不是轉壞了

那張跨頁在輸出裡變成了三張圖:縮小後的完整跨頁一張,拆開的左半與右半各一張。第一次翻到這裡很容易以為轉檔出了重複的毛病,其實這是刻意的預設:介面上勾著名為 Keep double page if split 的選項,原始碼便把「拆頁之後仍保留完整跨頁」的指示一起送給引擎。橫幅式的完整頁留給你想看整體構圖的時候,直式閱讀時讀拆開的兩半,兩種需求都照顧到。只想留拆開版本的,把這個選項關掉就行,開關就在轉換設定裡。

閱讀方向也照顧到了。日式漫畫由右往左翻,這個程式讓每一本書可以個別指定日式閱讀方向,原始碼裡是逐書一個方向的旗標,歐美左翻與日式右翻混著收藏的人不用全域改來改去。

書名打單引號,轉換會安靜地失敗

整輪測試裡最反直覺的一個發現在命名上。我照介面原始碼的組法,把書名換成帶單引號的 One Piece 104’s Special 再轉一次,引擎一啟動就吐回 bash 的語法錯誤,訊息是引號沒有配對,輸出資料夾空空如也。原因是這個程式呼叫引擎的方式:它不是直接執行二進位檔,而是把所有參數拼成一行字串,交給 bash 去跑;書名與檔案路徑用單引號包住,名字裡一旦再出現單引號,配對就從中間斷掉,整行指令直接失效。

對使用者的意義很實際:轉換失敗、錯誤訊息又長得像程式壞掉的時候,先檢查書名欄位有沒有單引號或特殊符號,拿掉重試就好。把參數拼成一行交給 bash 的呼叫方式從 2024 年首版就是如此,不過用單引號包書名是 2025 年 9 月重寫時才引入的寫法,更早的版本用雙引號,單引號書名反而轉得過。專案凍結之後,這個缺口很可能不會再修。

它曾在 Apple Silicon 上無聲地全壞了九個月

開場提到的那件事,按時間順序排開是這樣的。2024 年 7 月,作者在三天內發了 0.1 與 0.2 兩版。同年 12 月 10 日,有使用者在專案的問題討論區開了一題,標題直指所有轉換在 macOS 15.2 上全部失敗:程式瞬間宣布完成,輸出檔案卻不存在,與任何設定都無關。這一題躺了九個月。2025 年 9 月 19 日,開這一題的 LouisPiper 自己把根因挖了出來,他在討論串裡自稱對寫程式非常業餘:安裝包裡那顆標了 silicon 的引擎二進位檔,實際是編成 x86 架構的。他自行重編了 ARM 版本換進去,轉換就活了。作者次日自己重編、發布 0.3 修正,並在討論串裡明確說了:引擎版本維持 2.7.2 不動。

我在這裡補上二進位層的證據:file 指令顯示,0.2 下載包裡的 go-comic-converter-silicon 是 Mach-O x86_64,而 0.4 包裡的同一顆名稱的檔案是 arm64。換句話說,在沒有安裝 Rosetta 2 轉譯層的 Apple Silicon Mac 上,那個時期的官方版本等於沒有可用引擎;有裝 Rosetta 的機器靠轉譯繼續能跑,同一個安裝包在不同機器上行為不同,讓問題更難被一眼看穿。至於為什麼 12 月才爆、介面為何顯示完成,該討論串沒有細究,我也沒有 15.2 環境可以重現,這部分以討論串原文為準。

這段歷史對你判斷這個工具的價值很有用,而且兩面都要看。壞消息是它證明了這個專案的故障是安靜的:沒有錯誤碼、沒有公告,壞九個月,修復的診斷工作來自社群而非作者。好消息是它也證明了東西本身有人在乎:一位業餘使用者願意花時間找根因,作者隔天就接手修正,九個月的死寂在兩天內閉合,2025 年 9 月那一波還把整個程式翻新到對應新版 macOS。這是單人開源專案最典型的體質:上限與下限都繫在同一個人身上。

README 上的智慧裁切,介面裡找不到

下載前若照著 README 評估功能,有兩項會與實際拿到手的東西對不上。README 說這個工具有智慧裁切,還支援移除偶數頁碼;但翻遍設定畫面的每一個開關,沒有裁切這一項,而原始碼在組參數時硬寫了停用裁切的指示。引擎本身確實有完整的裁切能力,說明文件裡四邊各自的留白比例、裁切上限、觸發條件一應俱全,只是被這層外殼整個關掉了。掃描本白邊較厚的人,得在轉檔前先用別的工具處理。

同樣的落差也發生在拖放匯入。0.4 發布一個月後,專案的最後一筆提交把拖放功能整段程式碼移除,提交訊息只有一行,說這是修正,沒有交代原因;但那筆修正只存在於原始碼,官方下載停留在 0.4,包裡仍然帶著這個被作者自己放棄的功能。實際使用時,匯入走工具列的加號按鈕,點按後開檔案選擇器,可多選,這條路在原始碼裡是穩定的。下載包落後原始碼一個版本這件事,也提醒我們看這類專案時以最新提交為準,別只看 release 頁。

更早還有一個未遂的要求:2024 年 7 月有人希望開放自訂輸出解析度,作者表示這功能該由他去上游引擎開提交,這一題後來不了了之。到今天,輸出解析度仍然只能從預設檔位裡挑。

第一次打開被 macOS 擋下,先別急著刪檔重下載

0.4 安裝包的簽署狀態值得先知道。用系統工具檢查,這個程式有簽署、有開發者團隊編號,也開了強化執行階段。但同一個檢查的結論是系統不放行。原因是簽名用的憑證屬於開發階段用的 Apple Development 類型,不是對外分發軟體該用的 Developer ID,更沒有經過蘋果公證。翻成白話:下載沒有壞,你遇到的是簽章型式的必然結果。

實際畫面會是這樣:第一次打開,macOS 告訴你無法檢查這個程式是否含惡意軟體,然後拒絕執行。放行的方法是在 Finder 對著程式按右鍵選開啟,或到系統設定的隱私權與安全性頁面按強制開啟。對個人開源專案來說這是常見狀態,開發者年費繳了、憑證卻用開發版,通常不是惡意跡象;但若你的 Mac 是公司管理的工作機,資訊部門的政策可能直接判死刑,這種環境先別浪費時間。

離線、沙盒,以及直接內建的裝置檔位

隱私面倒是乾淨得少見。這個程式的權限只有應用程式沙盒與讓你自選檔案的讀寫兩條,沒有開放任何對外連線的權限,整個專案的原始碼裡也找不到網路請求的程式碼;轉換全程在你自己的機器上完成,沒有帳號、沒有遙測,檔案不出你的機器。漫畫掃描本常常是私人收藏,這一點對在意檔案流向的人是看得到的加分。

檔位不用自己設,清單直接內建,涵蓋面比多數同類工具寬:平板用的標準與高解析度兩檔,Kindle 從最老的機種一路到 1860 乘 2480 的 Scribe,Kobo 從 Mini 到 Elipsa 全系,外加 reMarkable 一代與二代。選了 Kindle 預設又勾了寄送 Kindle 相容時,程式會自動把輸出上限壓在 200MB,README 說這是為了配合 Amazon 的寄送服務而設計的,寄電子書給 Kindle 的人不用自己算大小。畫質步進器 70 到 100、無損 PNG 切換、自動對比或手動對比加減一百級,該有的都在;設定會存檔,重開程式不用重選,這是 2025 年 9 月那波翻新加上的。要留意的一個預設差異:引擎命令列的灰階預設是開啟(對電子紙最合適),這個介面把預設改成關閉,彩色書不受影響,但電子紙使用者記得自己打開,檔案會更小、翻頁也更流暢。

限制集中在這裡:凍結一年、單人維護與沒測到的部分

專案現況一次講清楚。最後一筆提交停在 2025 年 10 月 25 日,到這篇查核為止約十二個月沒有動靜;四個問題加一個 PR 全部關閉,目前掛零;83 顆星、7 個分支,四個版本的下載次數合計三百多次。作者是醫學系學生,個人頁面的自我介紹寫著熱愛寫程式的醫學生,九個公開專案裡這個的星數排第二,也是他唯一的 macOS 應用。引擎被釘在 2024 年 5 月的 2.7.2。上游的 go-comic-converter 已經發展到 3.0.4(2026 年 9 月,換了新的 PDF 閱讀器),2025 年 9 月大翻修時作者有機會升級而明確選擇不升。PDF 轉檔的新修正,除非專案復工,經由這個介面等不到。

Pin

沒測到的部分同樣列清楚:整卷數百頁的大檔表現、Windows 與 Linux(這是純 macOS 程式,系統門檻 14.0 以上)、以及裝置端的實際閱讀效果,我只驗到 EPUB 檔案結構這一層,沒有在任何閱讀器上翻過它。介面只有英文,沒有在地化檔案。

退路是存在的。上游的 go-comic-converter 本身就是一個命令列工具,2026 年 10 月仍持續有提交,功能比這個介面暴露出來的更多。這個圖形介面哪天真的停擺,直接用上游指令是一條走得通的路。這個判斷來自上游持續存在且獨立可用的事實,我沒有把上游全部功能測過一輪。

把 CBZ 收進 Apple Books 可以裝,超出介面的需求有別的路

該裝的人很明確:用 Mac、手上有 CBZ、CBR 或 PDF 漫畫想進 Apple Books 或 Kindle、Kobo、reMarkable,不想付錢也不想把私人收藏上傳雲端。轉換快、輸出正常、全程離線,這幾件事都經過實測。成功的樣貌是:轉完後在目的資料夾看到 EPUB,解開後書名頁與封面都在,拖進 Apple Books 應該就有封面可翻;跨頁書出現三張一組的內頁屬於正常行為。轉換失敗時,先查書名單引號,再看下載來源是不是 GitHub 官方頁,中文圈流傳的第三方載點不在維護範圍裡。

需求超出這個介面的,分幾條路走。要裁白邊,上游命令列工具辦得到,代價是記參數;自訂解析度則上游同樣只有預設檔位,想完全控制尺寸得另找工具。整理漫畫檔案、清掃描頁廣告、批次打包 CBZ 這類前置工序,KOMA 開源漫畫整理工具箱實測過,正好補上這個程式不管的部分。閱讀端若想脫離 Apple Books,Windows 與 Mac 都能跑的Reeden 電子書閱讀器是買斷制的另一個選擇。想一次看更多 macOS 上的開源小工具,也有人整理過一份持續維護的清單,這個程式所在的生態系比它本身熱鬧。

授權與專案狀態

外殼與引擎都是 MIT 授權,前者版權屬 Manuel Di Donna,後者屬上游作者 Celogeek,原始碼全程公開,要自己編譯或改造都合法。本文查核與實測完成於 2026 年 10 月 8 日,對象是 GitHub 官方頁的 0.4 版安裝包與當時的原始碼狀態;單人專案的現況會變,下載前看一眼最新提交日期,是對這類工具最起碼的健康檢查。