雙語混合 PDF 的 OCR 技巧：分開檢查中文、英文與數字

若要對雙語混合的 PDF 進行 OCR 光學字元辨識，請先確認頁面上的文字系統，選擇支援相關辨識語言的 PDF 處理工具，接著比對擷取出的文字與原始影像。 請分別獨立檢查中文內文、英文單字、數字以及標籤欄位的對應關係。 能搜尋到英文標題，並不代表中文內文就已經成功被辨識出來。

多加一種辨識語言值得測試，但不保證一定會更好。在我們的小型中英混排測試中，加入英文雖然修正了一個英文標籤，卻破壞了一句原本在純中文設定下能正確辨識的句子；而且在兩種設定下，工具都無法從帶框線的簡單表格中擷取出文字。

這並不是全盤否定多語言 OCR 的效果，而是提醒大家：評估標準應該放在最終產出的文字品質，而非勾選了多少種辨識語言。

第一步：先釐清是「文字遺失」還是「辨識錯誤」

請保留原始檔案不要修改。在副本中挑選一個具代表性的頁面，選取一句話並貼到純文字編輯器中。記得同時測試一段中文與一段英文，不要只複製文件標題。

文件是否已有文字圖層至關重要。舉例來說， NAPS2 的 OCR 說明文件 指出，若匯入的 PDF 頁面本身已包含文字，系統將不會重新處理。因此在那樣的工作流程中，重新匯入辨識拙劣的頁面並不是可靠的修復方式。

如果問題的根源在於掃描解析度過低、頁面彎曲或歪斜，在評估語言設定的差異前，必須先修正這些版面問題。我們的完整 掃描版 PDF 處理指南 介紹了相關的前置準備與後續的翻譯階段。

選擇辨識語言，而非翻譯目標語言

辨識要解決的是「頁面上包含哪些字元？」，而翻譯要解決的則是「這些內容以另一種語言呈現時該如何表達？」。切勿要求 OCR 擅自將繁體中文轉換為簡體、翻譯英文引言，或是改寫不熟悉的識別碼。

先快速列出以下清單：

• 中文字形： 簡體、繁體或兩者皆有，包括標題與註釋。
• 拉丁字母文字： 英文句子、作者姓名、參考文獻、縮寫及型號。
• 受控值： 日期、小數點、單位、負號、識別碼以及區分大小寫的代碼。
• 版面區域： 正文、表格、圖表說明、註腳或獨立語言的附錄。

例如，一份繁體中文報告可能包含英文摘要與參考文獻；一個簡體中文章節可能包含帶有 A-01, 23.5與 °C的表格。這兩種情況都不能只藉由檢查最長的中文段落來評估辨識品質。

Tesseract 在其 chi_sim, chi_tra及 eng 模型於其 官方模型存放庫中。其 指令文件 支援多語言組合設定，並指出語言順序可能會影響辨識結果。這些僅是設定上的可行性，並不保證每增加一個模型就一定能提升效果。

若您的文件包含日文直排欄位與振假名，請參考 日文直排 OCR 指南。那是完全不同的排版與註釋處理問題，而不僅僅是多勾選一種語言那麼簡單。

使用真正支援 PDF 的工作流程

桌面端方案：NAPS2

NAPS2 提供了將掃描版 PDF 轉換為可搜尋檔案的官方指引步驟：

1. 匯入檔案副本並開啟其 OCR 設定。
2. 下載文件所需的識別語言套件。
3. 選擇 多種語言 並勾選相關語言。
4. 啟用可搜尋 PDF 的 OCR 功能，並另存為新檔案。
5. 重新開啟該檔案，將複製出的中文、英文及數字文字與頁面可見內容進行對比。

只有在下載了多種語言後，多語言選項才會出現。上述步驟依據 NAPS2 官方指南整理；我們並未針對本文專門進行 NAPS2 的實際測試。

命令列方案：OCRmyPDF

對於純圖片的簡體中文/英文 PDF，根據官方文件提供的範例如下：

ocrmypdf -l chi_sim+eng --output-type pdf \
  --sidecar recognized.txt input.pdf searchable.pdf

請先安裝所需的 語言套件 。若要測試繁體中文，請使用 chi_tra ，切勿預設這兩種字體可以通用。

這份 OCRmyPDF 操作手冊 詳細說明了 PDF 及附屬文字檔（sidecar）的輸出機制。附屬文字檔不一定包含整份文件的內容：原本就含有文字的頁面，或在 OCR 過程中被略過的頁面，其文字可能不會收錄其中。請務必直接檢查輸出的 PDF 本身。若原本就存在錯誤的 OCR 結果，則需要刻意執行重新辨識流程；在尚未了解其變更影響之前，請勿強制將每一頁都點陣化。

這是基於官方文件的參考方案，並非我們實際測量過的測試環境。我們並未在此運行 OCRmyPDF。

原生 Tesseract 需要先渲染頁面

請勿將 tesseract input.pdf ... 當成 PDF 閱讀器來使用。 Tesseract 不接受 PDF 輸入，即使它可以生成 PDF 輸出格式。 Tesseract.js 在 PDF 輸入方面也有相同的限制：必須先使用 PDF 函式庫渲染頁面，然後再對影像進行辨識。

這正是我們在下方實驗中採用的方法。它會產出文字和 TSV 格式的佐證資料，而非經過測試的可搜尋 PDF 輸出檔。

十次本機 OCR 呼叫的實測結果

我們建立了一個 三頁的純影像 PDF ，內容包含：

1. 帶有英文引用、識別碼、小數及單位的簡體中文段落；
2. 相對應的繁體中文頁面；
3. 一個包含三行資料的小型中英對照表格。

這些文字與數值均為自行編寫的教學範例，並非客戶檔案或真實量測數據。每個段落目標包含 124 個非空白字元（code point），其中包括 41 個漢字。表格則包含 79 個非空白字元。

該 PDF 的原始頁面無法擷取任何文字。我們使用 Poppler 26.08.0 以 300 dpi 進行渲染，產出 1600×1000 像素的影像。字型大小為 Noto Sans CJK SC/TC Regular 48 像素。所有標點符號均取自該字型的標準橫排字形。

在 2026 年 9 月 8 日，我們於 macOS ARM64 環境下於本機執行 Tesseract.js 7.0.0 與 tesseract.js-core 7.0.0。官方的 tessdata_fast 模型固定在 commit 87416418657359cb625c412a48b6e1d6d41c29bd。每次呼叫均使用 OEM 1 和單一均勻文字區塊設定 PSM 6，並在各個語言比對中使用相同的頁面影像。

每個段落頁面分別測試了四種語言組合配置，表格則測試了兩種。全部十次呼叫均順利完成；我們沒有捨棄任何結果，也沒有在查看輸出後調整任何參數。完整的 輸入內容、模型雜湊值、版本與原始結果 以及 重現步驟說明 已公開提供。

一項設定可能修復了某個欄位，卻破壞了另一個欄位

在繁體中文頁面上， chi_tra 依序保留了全部 41 個漢字，但仍出現了非中文的錯誤。例如，它將英文標籤 Document ID 誤識為 Document 1ID ，且辨識錯了度數符號。

加入 eng 雖然恢復了 Document ID，但溫度與質量相關句子的一部分卻變成了看似拉丁字母的殘缺字元：

Expected: 樣本溫度為 23.5 °C，質量為 1.08 kg。
Observed with chi_tra+eng: RA MEA 23.5°C > HBA 1.08 kg。

該行中的數字被保留了下來，但周圍的中文卻損毀了。如果只檢查 23.5 與 1.08 ，就會完全忽略這個損壞。

簡體中文頁面則呈現出不同的權衡取捨。加入英文後恢復了 BK-2026-A07（僅設中文時被辨識為 BK-2026-AO7），但同時也將其他位置的 与 改成了 5 。此外，外觀容易混淆的識別碼 O0I1-l 依然辨識錯誤。

以下診斷結果說明了我們為何無法直接判定勝者：

「漢字序列編輯距離」僅比對中文字元，不對英文、標點符號或空格計分。「找到的保護字串」僅用於檢查預定義的識別碼、數字、單位與參考標記是否存在，並不驗證它們的位置或相對關係。純英文輸出結果展示了這個陷阱：大部分保護字串皆存在，但卻完全沒有傳回任何中文字元。

完整的 比對 CSV 檔案 也記錄了全文編輯距離。比對過程採用 Unicode NFC 並移除空白字元；不會修正標點符號、變更大寫小寫、轉換繁簡中文，亦不會重新排序字元。顛倒語言順序會改變這些文章輸出中的空格，但不會改變正規化後的字元序列。此觀察結果並非適用於所有語言順序的通則。

空白表格不等於擷取成功

兩次表格呼叫均未傳回任何文字，儘管執行完畢且未出現 OCR 執行錯誤。加入中文並未能挽救固定統一文字區塊的處理配置。

我們並未測試其他分割模式、單元格裁切或表格辨識引擎。因此，該結果並 不 證明 Tesseract 無法讀取表格。這僅表明在我們所使用的設定下，單純更換識別語言並不能解決此樣本的問題。

對於真實表格，必須要求完整的對應關係 Temperature → A-01 → 23.5 → °C，而不僅僅是在頁面某處找到四個詞元（token）。如果輸出為空白或無法驗證對應關係，請不要再將其視為值得信賴的轉錄結果。請改用具備版面感知能力的工作流程，或參考原始圖像手動轉錄必要的儲存格。

本實驗無法證明的局限

這些測試頁面是由單一字型家族生成的 3 頁乾淨合成檔案，並僅由單一撰稿人代理進行審查。本實驗並未包含雙盲人工審查、實際生產環境的文件語料庫，亦未測試模糊掃描件、手寫字跡、複雜表格、直排文字或古籍罕見字。

這些結果適合作為反例，駁斥無條件「加入更多語言」的做法。但它們並非 OCR 引擎的排名、總體準確率指標，也無法預測您手頭 PDF 的處理效果。這並非 BookTranslator 的評測，且該純圖像來源 PDF 也並非已經完成 OCR 的閱讀複本。

對您自己的檔案進行四步驟驗收檢查

下載 空白審查表。選擇包含實際難點的頁面，在處理整份檔案之前執行以下檢查：

1. 中文文字： 比對完整的句子，包含罕見字以及預期的簡體/繁體字形。切勿私下將錯誤字元默認修正為您預期的文字。
2. 英文與識別碼： 仔細檢查作者姓名、參考文獻、縮寫、大小寫以及形近字，例如 O/0 或 I/l/1。不熟悉的代碼並不是可以隨意自動校正的普通單字。
3. 數字與單位： 比對每個數值及其正負號、小數點、單位與標籤。 0.05 與 0.50 必須保持區隔；只辨識出 23.5 而遺漏了正確單位仍算不完整。
4. 結構關聯與完整性： 檢查每個段落或表格列是否落在預期位置。確認圖表說明、註腳以及次要語言的簡短段落均已保留，而非僅保留正文主體。

記錄原始文字、觀察到的結果、頁碼/區域以及所需採取的措施。當某種設定改善了一項檢查卻劣化了另一項時，請同時保留這兩項觀察紀錄。切勿僅憑單一信心評分或平均字元數就判定檔案驗收合格。

請將結果分為三種：可直接用於特定目的、需要針對性修正，或是暫時不可信。單純查閱資料可能只需要核對某個段落；但若要製作完整的閱讀副本，則需要確保整份文件都準確無誤，而不僅僅是扉頁乾淨即可。

確認原文內容無誤後再進行翻譯

如果搜尋功能和可複製的原文就已能解決您的問題，到這一步即可停止。OCR 已經完成了它的任務，是否翻譯則是另一個獨立的決定。

如果您需要以另一種語言閱讀整份文件，請保留原始掃描檔和校正後的文字作為參考，然後遵循 掃描版 PDF 翻譯工作流程。對於符合條件的檔案， BookTranslator 的 PDF 翻譯工具 可以作為下一步。它的 OCR 模式著重於重組翻譯後的內容，而非保證與原始頁面排版完全一致；這並不能免除您檢查識別出的文字與表格關聯的需求。

翻譯完成後，請使用 PDF 翻譯品質檢查清單 來區分究竟是原文識別錯誤，還是翻譯或排版錯誤。如果找錯了修正的環節，看似通順的錯誤就會一路殘留到最終檔案中。