DeeplxFile 實測：Word、Excel 大檔免費翻，引擎要自己養

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

在 Mac 上把 DeeplxFile 的原始碼整包抓下來，照它自己的程式路徑啟動內建翻譯引擎，接著連送五個翻譯請求，五個全部失敗。引擎活著、連接埠開著、程式沒有崩潰，但每個請求都拿到同一句話：API returns an empty result。網路沒問題，操作也沒錯。這顆 2024 年夏天就打包進專案的翻譯核心，已經追不上 DeepL 端點這兩年多的變化。

DeeplxFile 在 GitHub 上有超過一千顆星、91 次 fork、累計約 1.28 萬次下載，主打「免費、快速、不限檔案大小」的 Office 文件翻譯。這個承諾放在 2026 年依然成立，因為它瞄準的缺口到現在都還在：DeepL 官方免費方案不收 Excel 檔，Google 的文件翻譯有 10MB 上限。但承諾和能用之間隔著一顆停止更新的引擎。下面就把這段距離實際量一遍：哪些通道死了、死在自己手裡還是死在別人手裡、以及把它救活要花多少力氣。

這台翻譯機原本的樣子

DeeplxFile 由開發者 infrost 維護，2024 年 8 月上線，採 GPL-3.0 授權，Windows 有打包好的安裝檔，macOS 有命令列版本，也可以直接跑 Python 原始碼。它不是把檔案丟給某個翻譯服務的整合器，而是自己做苦力：把 Office 檔案解開、抽出裡面每一段文字、切成小塊送去翻譯，再把譯文組成一份新檔案。因為拆塊和重組都發生在你自己的電腦上，所以沒有服務端的檔案大小上限，這就是「不限大小」的原理。

很多人以為它只支援 Word、Excel、PowerPoint 三種檔，其實原始碼裡登記的輸入有六種：xlsx、docx、pptx、pdf、md、txt。PDF 比較特別，它靠同一作者的另一個獨立小程式先把 PDF 轉成 docx 才開始翻，而且那個轉檔服務只出了 Windows 版。純文字和 Markdown 檔則不需要拆解，直接逐行送翻。

翻譯引擎有四種模式可選。預設的 deeplx 模式用它內建的核心；直連模式繞過核心直接呼叫 DeepL 的網頁端點；瀏覽器模式用 Playwright 操控一個真的瀏覽器，模擬人類複製貼上；2025 年 2 月加入的大模型模式則讓你填自己的 API 金鑰，用 GPT 之類的模型翻，還能指定語氣風格。四條路各自獨立，接下來你會看到，它們在 2026 年的健康狀況差非常多。

Pin

引擎在跑，端點已經不認識它

實測從最正統的路徑開始：啟動專案內建的 deeplx_darwin_arm64 核心，它來自 DeepLX 專案，是一支 Go 寫的執行檔，作用是把 DeepL 網頁版的內部翻譯介面包成本地 API；Mac 版內建的是 2024 年 6 月的 v0.9.5，Windows 版是 v0.9.8.3，設定檔裡的版本標籤雖然在 2025 年 2 月被改成 1.0.4，二進位核心其實從沒換過。核心順利啟動，監聽本機連接埠，接著依它的介面規格送出五個翻譯請求，換英文換中文、換大小寫、換自動偵測，五個組合全部收到同一個 503 錯誤，訊息就一句：伺服器順利收到請求，但 DeepL 端給了空結果。

對照之下更能確定問題在哪。同一時間，用正確的資料格式直接向 DeepL 的免費網頁端點要一次翻譯，幾秒內就拿到 HTTP 200 和簡體中文譯文。同一個端點、同一個 IP、同一天，一邊通、一邊全滅，差別只在請求是誰組的。換句話說，DeepL 沒有掛，掛的是上游 2024 年 6 月之後就沒再更新過的 DeepLX v0.9.5 核心對端點協議的理解。

上游的 DeepLX 專案本身活得好好的，從 v0.9.5 到現在已經發到 v1.2.4，2026 年 8 月還在出版本，中間持續修協議相容問題。DeeplxFile 這邊的最後一次 commit 停在 2025 年 2 月 16 日，凍結前六天上游剛發 v1.0.4，這邊沒有跟上，只把設定檔裡的版本標籤換了字。專案的 issue 板上，2026 年 3 月有人反映「DeepL 似乎更新了」，到現在開著，沒有任何作者互動；2025 年中之後的 issue 全部是同樣待遇。引擎死亡這件事，不會有人來修。

直連模式死在自己的程式碼裡

deeplx 模式失效時，介面會建議你切到相容性更強的模式，而直連模式是最先該被排除的那個。它不是被 DeepL 擋下來的，是被自己的程式碼絆倒的。

翻進直連模式的原始碼會看到這一行：組請求時用 enumerate 跑迴圈，但忘了解包，導致每一段要翻的文字連同它的行號一起被塞進文字欄位。這個錯從 2024 年 8 月 19 日一次為了支援 macOS 的重構之後就在了，之後將近六個月到專案凍結，沒人動過它。實際重放這種形狀的請求，DeepL 端點直接退 HTTP 400；同一個端點、把行號拿掉、只留文字，立刻 200。一個字元的差別，決定整個模式生死。所以只要用到直連模式，每個請求從 2024 年 8 月起就注定被退件，跟請求頻繁無關，跟 DeepL 改版也無關。

順帶一提，繁體中文在這條路上也拿不到。把目標語言設成繁中代碼向免費端點要翻譯，收到的同樣是 400；同場測簡體代碼則正常。DeepL 的免費 API 通道不吃繁中目標，想免費拿到繁體輸出，只剩瀏覽器模式這條路，因為 DeepL 網站版的語言清單裡確實有繁體中文這個選項。

最反常的發現：來源語言選單是裝飾品

介面上明明有十二種來源語言可以選，但讀完主程式碼你會發現，那個下拉選單從 2024 年 10 月的 v0.5.7 之後就是個擺設。程式裡有一段把繁中、簡中換成通用中文代碼的判斷式，寫錯了寫成恆真：不管你選英文、日文還是法文，原始語言都會被換成 zh 再送出去。目標語言不受影響，但來源語言永遠是中文。

這個 bug 在 2024 年 9 月初寫進原始碼、10 月底隨 v0.5.7 首次出貨，一路活到最後的 v0.5.11，三個多月後專案凍結，至今沒修。它最微妙的地方在於後果不明顯：DeepL 端多半會自己偵測實際語言，翻譯結果看起來仍然正常，所以一千多顆星、上萬次下載，沒有人為它開一張 issue。要不是把每一行送出去的參數攤開對照，這種靜靜躺著的錯不會被任何人發現。

免費的形狀：寄生在非官方接入上

把四條通道的生死攤開，就能看懂這個工具「免費」的本質。它從頭到尾沒有跟 DeepL 簽任何約：內建核心是把 DeepL 網頁版的內部介面包一層，直連模式是自己組網頁版的請求格式，瀏覽器模式是開一個真瀏覽器去用人家網站。三條免費路全部寄生在 DeepL 給瀏覽器用的非官方接入上，DeepL 沒有義務為它們保持穩定，改版即斷，斷了也沒有賠償。

免費也有限流的時候。實測過程中，短時間內連續幾發請求之後，IP 就被 DeepL 暫時封鎖，訊息明白寫著請求太頻繁。README 自己也承認這件事，還把「請求頻繁」四個字寫進了錯誤提示。所以「不限檔案大小」是真的，但「不限大小」不等於「可以連發」：檔案多大都吃得下，因為拆塊在你電腦上做；速度多快則要看 DeepL 臉色，撞到封鎖就必須等冷卻。分塊本身還有個英文中心的設計：切塊以空格斷詞計數，一千個詞切一刀，純中文的檔案一行只算一個詞，讀碼可以推知中文來源檔會堆到快一千行才切第一刀，單塊體積遠比英文檔大。

Windows 和 macOS 拿到的是不同的機器

釋出清單暴露了另一個容易被忽略的事實：這個專案對兩個平台的照顧差很大。最新的 v0.5.11 在 2025 年 2 月 11 日發布，只出了 Windows 安裝檔，full 版 91MB 帶完整瀏覽器核心，下載 7,142 次，是全專案下載次數最多的一個檔案。macOS 的預編譯版則停在 2024 年 9 月，檔名寫著 v0.5.6，比 Windows 落後四個發布，沒有大模型模式，設定檔還是舊架構。

Pin

macOS 版的預設值也值得看清。瀏覽器模式跑不起來時，它會去拉你系統裡的 Edge，而且預設帶著你真實的使用者設定檔連線；更狠的是，它啟動前會先把所有正在跑的 Edge 行程全部終止，介面也只在事前彈一個警告視窗叫你存檔。也就是說，用 Mac 版翻一份文件，代價可能是你開著的所有 Edge 分頁一起關掉。另外，倉庫裡其實沒有附瀏覽器核心，只有一個放核心用的佔位空檔案，完整核心只存在於 Windows 的 full 安裝檔裡；macOS 想用瀏覽器模式，README 的要求是自己先裝 Edge。至於 Linux，原始碼裡選執行檔的邏輯寫成 macOS 和 Linux 共用一條判斷，Linux 使用者從原始碼跑，程式會去執行那顆 macOS 的二進位檔，直接失敗，除非自己另外架好翻譯伺服器再指過去。

把它救活的三條路

現在想用 DeeplxFile，有三種救法，成本差很多。

最乾淨的是自己架一顆新心臟。上游 DeepLX 的 v1.2.4 仍在維護，一支執行檔就能在本機跑起來，而 DeeplxFile 的設定檔裡本來就有自訂伺服器欄位，把位址填進去，它就不再用內建的那顆舊核心，改打你自己架的新版。實測中這條路的介面完全接得上，實測當下 IP 已被 DeepL 暫時封鎖，沒能當場跑完一輪完整翻譯；但兩邊的介面規格是同一份，這條路是四條通道裡最有希望長期活著的。不想裝在自己機器上的人，也可以把欄位指向任何你信任的 DeepLX 服務，不過檔案內容會流經那台伺服器，這一點要想清楚。

另一條是瀏覽器模式。它不依賴 DeepLX 核心，直接開瀏覽器操作 DeepL 網站，天生免疫核心斷代問題，也是免費通道裡唯一能選繁體中文輸出的路；代價是速度慢、佔資源，以及前面說的 Edge 副作用。README 稱它相容性最強，issue 板上「翻譯行數不符、不斷刷新重試」的反覆抱怨也集中在這條路上，穩定性要自己承擔。這條路我沒有實際跑，Mac 上要先自己裝好 Edge 才有得測。

還有一條是大模型模式，填自己的 API 金鑰走 OpenAI 相容介面，能指定翻譯風格是它獨有的優點。但它有兩個門檻：這個模式只存在於 2025 年 2 月的 v0.5.11，也就是只有 Windows 安裝版有，macOS 預編譯版沒有；而且原始碼用的是 2023 年世代的舊版 openai 套件介面，作者自己在 issue 裡證實要配 0.27.8 版才跑得動，現在灌新版套件只會直接報錯。

拆開再組起的代價：格式與對不上的行數

拆檔重組是有代價的。我用工具自己的模組跑了一輪完整流程：造一份測試文件，抽出文字、分塊、送翻譯（翻譯段用本機替身引擎，單驗拆解與重組）、產出翻譯版檔案。結果印證兩件事。第一，譯文在寫入前每一行都會被去掉頭尾空白，所以相鄰兩段文字之間的分隔空格會憑空消失，講究排版的文件翻完間距會走樣。第二，文件裡被切碎的文字段（同一句話因為格式標記被拆成兩段的那種）會各自獨立送翻，前後文就斷了，機器翻這種碎片向來容易出戲。

還有更隱形的：翻譯失敗不會停機，程式會把失敗的區塊原文逐行加上 Error 前綴直接寫進譯文檔裡，然後繼續翻下一塊。一份大文件翻完，中間夾幾段沒翻過的原文是常態，用的人必須自己檢查。Excel 另有專屬行為：譯文行數和抽出時對不上時，它只印一行警告，接著用截斷方式替換前段譯文、剩下的保留原文，照樣輸出一份自稱翻譯完成的檔案。

集中限制：隱私、斷代與格式代價

對照官方方案，這個工具的定位其實很清楚。DeepL 官方免費方案不收 Excel，譯後檔案還不能編輯，要編輯得升級付費；Google 文件翻譯收 10MB、PDF 收 300 頁。DeeplxFile 確實補上了「免費、大檔、Excel」這一格，而且譯文直接就是可編輯的原始檔。代價這邊，最先該問的是隱私：不管哪條通道，你的檔案內容都會以純文字形式整份送到 DeepL 的伺服器（大模型模式則是送到你填的那家 API），商務文件或合約這類內容，送上非官方通道前值得三思。穩定性同樣打折扣，核心斷代加 IP 封鎖，等於把可用性押在一個隨時會變的免費端點上。維護的問題前面已經看到了，專案凍結超過一年半、2025 年中後 issue 零互動，所有問題都只能自救。至於格式，空格消失、碎片翻譯、Error 行混入，都是前面實際驗過的行為。

判斷：誰該自救，誰該繞開

如果你會自架服務、手上有一堆 Excel 大檔要翻、而且內容不敏感，DeeplxFile 加一顆自己架的 DeepLX v1.2.4，現在仍然是最省錢的組合，一次設定、長期使用，這是它值得救的場景。成功的樣子很具體：填好伺服器位址後，送一個短句請求能拿到譯文，就代表換心成功，接下來就可以餵大檔了。

如果你不想碰命令列、用的是 Mac、或檔案內容敏感，直接繞開是更合理的選擇。要翻 PDF 論文，PDFMathTranslate 和 BabelDoc 這類專門的開源方案更合適；想要不依賴雲端的穩定翻譯，自架 MTranServer 的離線模型沒有斷糧風險；只想偶爾翻幾頁的人，DocTranslator 這類線上文件翻譯服務省事得多。DeeplxFile 的最大價值就在免費又能吃大檔 Excel 的交集上，離開這個交集，它的維護現況撐不起推薦。

授權與專案狀態

DeeplxFile 採 GPL-3.0 授權，原始碼完整公開，2024 年 8 月建立，專案在 2025 年 2 月 16 日之後就沒有再動過。內建的 DeepLX 核心是其上游 2024 年 6 月的 v0.9.5 版，上游至今仍活躍。下載 Windows 版請認明 GitHub releases 的官方資產，中國大陸鏡像站的可信度自己斟酌。GPL-3.0 對一般使用者幾乎沒有門檻：自己翻文件、公司內部使用都不觸發授權義務，只有當你把修改過的版本再對外散佈，才需要連原始碼一起公開。另外，倉庫已經有 91 個 fork，若有人願意接手維護，接著做的成本比從頭造一個低得多，想等它復活的人可以盯著 fork 動態。