PDF 複製貼上文字錯誤？先診斷文字層
PDF 看似正常，複製出來的文字或數字卻錯誤？使用四個範例檔案來識別文字層的問題，並選擇可驗證的修復方法。
如果 PDF 看似正常但貼上錯誤的文字，請停止使用貼上的版本作為來源。首先，將一小段內容（名稱、句子和數字）與可見頁面進行比較。下一步取決於檔案是沒有可擷取的文字、字元對應不正確、隱藏的 OCR 層不準確，還是閱讀順序有問題。對整份文件執行 OCR 並不是解決這四種情況的最佳第一步。
最危險的錯誤不是亂碼，而是看似合理的文字：例如頁面上顯示 18 notebooks ，而擷取出的文字卻是 13 notebooks。我們建立了四個可下載的 PDF，讓這種差異一目了然，且無需使用任何人的私人文件。
從簡單的複製與比對檢查開始
保持原始檔案不變並開啟工作副本。將一個短選取範圍貼到純文字編輯器中，然後逐字逐字元與頁面進行比對。在不同的頁面上重複此操作，若可能的話，也在第二個 PDF 閱讀器中進行。這是一項診斷檢查，並不能證明文件的其餘部分完全正確。
| 發生的情況 | 要調查的方向 | 第一個有用的動作 |
|---|---|---|
| 無法選取任何內容，或貼上結果為空 | 頁面可能只包含圖片 | 檢查閱讀器選取的是頁面圖片還是文字 |
| 字母會一致改變，但在頁面上看起來很正常 | 字元編碼或擷取對應 | 比較另一個閱讀器的輸出結果；尋找原始來源檔案或更好的匯出方式 |
| 大多數文字都可讀，但名稱或數字錯誤 | 文字層不準確，包含舊的 OCR 產生的結果 | 將擷取的段落與可見的掃描結果進行比對 |
| 字母正確，但欄位、圖說或註腳的順序錯誤 | 版面配置與閱讀順序擷取 | 分開測試單一欄位或段落 |
| 複製功能已被停用 | 文件權限或閱讀器行為 | 檢查檔案權限並向來源索取可用的副本 |
這些只是線索，並非單憑一個徵兆就能辨識出所有 PDF 的內部結構。Adobe 的 內容重複使用指南 區分了純圖片內容與複製限制。兩者皆不應自動被視為損壞的文字圖層。 pypdf 擷取指南 則分別描述了圖片、文字擷取，以及處理表格和間距時的困難。
對於長篇書籍或報告，請記錄發生各個問題所在的 PDF 頁碼。乾淨的封面並不能告訴您附錄、掃描插頁或雙欄章節是否能正確複製。
四份 PDF：頁面顯示與擷取結果的對比
我們的測試頁面包含四行原始文字，其中包括：
此檔案庫包含 18 本筆記本。
項目 B-204 於 5 月 6 日送達。
我們製作了一份正常的數位 PDF，並刻意建構了另外三種替代版本。接著我們使用 Poppler 與 pypdf 擷取其文字。兩款擷取工具對此測試中的每個檔案都傳回相同的文字。
| 下載 PDF | 我們是如何建構它的 | 實際擷取結果 |
|---|---|---|
| 正確的數位文字 | 帶有嵌入字型的正常可見文字 | 18 notebooks; B-204; 6 May |
| 錯誤的 Unicode 對應 | 變更了擷取對應，但未改變可見字形 | 13 notebooks；數個小寫 a 字元變成了 x |
| 錯誤的隱藏文字 | 故意在頁面圖片上方放置了錯誤的隱形文字 | 13 notebooks; B-2O4; 8 May |
| 純圖片頁面 | 使用了沒有文字層的相同頁面圖片 | 空白文字輸出 |
看起來正常的數位頁面可能會複製出錯
在我們的比較中，前兩個 PDF 渲染出的像素完全相同，但它們提取出的文字卻不同。在第二個檔案中，我們刻意改變了 ToUnicode 對應關係：用於將儲存的字元代碼對應到 Unicode 文字的資訊。可見的數字維持 8，而提取結果卻傳回 3。「 pypdf CMap 說明文件 」說明了這個對應機制。
這展示了一種失效機制，並不是聲稱每個亂碼 PDF 都有相同的缺陷。單單一個缺少的 ToUnicode 項目並不是我們的診斷結果，手動編輯對應關係也不是通用的讀者端修復方法。
可搜尋的掃描檔可能包含錯誤的單字
第三和第四個 PDF 彼此渲染出來的結果也完全相同。一個包含錯誤的隱形文字；另一個則完全沒有。在第三個檔案中，提取結果默默地同時更改了數量與日期。程式碼 B-2O4 包含字母 O，而不是圖片中顯示的數字 0 。
這些錯誤是我們自己插入的，用以代表隱藏文字層可能包含的不匹配情況。OCR 引擎 並未 產生它們。第四個檔案則顯示相反的情況：一個可讀的頁面圖片，但這些文字提取器卻無法傳回任何內容。這與 pypdf 記錄的限制一致：它會提取現有的 PDF 文字，但無法辨識圖片內部的文字。
這項測試確立了什麼——以及它沒有確立什麼
在 2026 年 9 月 10 日，我們使用 Poppler 26.08.0 和 pypdf 6.10.0 檢查了四個單頁檔案。視覺比較使用 144 dpi 的 Poppler。像素一致性維持在 兩組配對之內，而非跨越所有四個檔案：基於影像的那組配對經過了額外的渲染步驟。
這是受控的演示，而非 OCR 準確度基準測試。它並未測試多語言識別、複雜佈局、Acrobat 修復、OCRmyPDF 修復或 BookTranslator 上傳。這些是具有已知錯誤的建構範例，而非盲測評估。
這些 原始文字與像素結果, 、重現步驟說明以及 生成器 均隨檔案提供。它們使用未經修改的 Noto Sans 字體及其隨附的開源字體授權。
選擇干擾最小的下一步
以下修復路徑源自官方文件與實際診斷。它們 並非來自我們四個檔案實驗的修復結果。請在副本上操作，並在替換任何您依賴的內容之前驗證輸出結果。
如果您擁有原始文件，請先嘗試重新匯出
從原始文書處理、出版或排版檔案重新產生的 PDF 是很有用的首選方案。請仔細比對出錯的段落。不要假設新的檔名或成功的匯出就代表其文字現在是正確的。
對於從檔案館或出版商取得的資料，請檢查是否存在另一個包含文字的版本。請保持版本與頁碼參考一致：不同版本的較清晰檔案可能無法保留您需要的段落。
如果掃描件有少數識別錯誤，請檢查這些單字
Acrobat 在 掃描與 OCR → 修正識別的文字下記錄了一個工作流程。它讓您可以對照掃描影像來檢查標記為可疑的單字，並修正識別出的文字。請遵循 Adobe 目前的修正說明 以操作您版本中的介面。
不要將空的可疑清單視為完整性測試。請獨立比對您將引用或翻譯的姓名、日期、識別碼和數量。我們故意出錯的 13 notebooks 這個例子說明瞭為什麼可讀的輸出是不夠的。
如果隱藏文字整體出錯，請區分重做與強制執行
對於使用命令列工具的讀者，OCRmyPDF 針對已包含文字的頁面提供了不同的處理路徑：
--redo-ocr會移除現有的非列印 OCR 文字並重新辨識，同時排除可列印文字免受 OCR 影響。--skip-text會跳過包含文字的頁面。這並不是修復現有錯誤文字層的方法。--force-ocr會將頁面內容點陣化，並對產生的影像執行 OCR。
這些行為說明於 OCRmyPDF 的現有文字錯誤說明文件中。在版本 17 中，等效的選項也可透過 --mode取得；舊的旗標仍然是別名。
這其中有代價與例外情況。重做無法識別每一個歷史 OCR 排版；某些檔案會在技術上可列印的文字上放置不透明影像。強制執行則會將可列印文字與向量內容變成像素，並將互動式內容平面化。重做與強制執行也會丟棄現有的結構樹，而不是重建它。請在選擇其中任何一個之前，先參閱 OCRmyPDF 的進階說明文件 。
因此，修復後的萃取結果並不是無障礙功能的通過。如果文件需要標題、閱讀順序或無障礙圖形，請使用獨立的 已翻譯的 PDF 無障礙檢查.
如果頁面或語言有所不同，切勿假設單一設定適用於所有情況
列出哪些頁面已經包含可信賴的數位文字，哪些頁面需要識別。在設定 OCR 之前，請檢查受影響頁面上的語言。我們的 混合語言 PDF OCR 指南 涵蓋了語言選擇；這與判斷舊文字層是否錯誤是不同的決定。
如果完全沒有文字層，請移至 掃描版 PDF 工作流程。重複嘗試另一個純文字萃取器並不會讓 pypdf 識別影像中的文字。
在使用替換文字之前進行驗證
使用 可下載的文字圖層檢核表 ，以便並排檢視可見參考資料、先前的擷取內容以及替換的擷取內容。從已知的失敗處開始，然後測試不同的段落以及任何明顯不同的頁面排版。
- 字詞： 逐字比較名稱與不熟悉的術語。
- 數字： 檢查數量、小數點、日期以及識別碼，例如
B-204. - 順序： 跨換行符號閱讀完整段落；分別檢查欄位和附近的說明文字。
- 完整性： 確認您需要的頁面和段落沒有被遺漏。
- 檔案行為： 重新開啟儲存的替換檔案並重複複製測試。如果您依賴書籤、連結或無障礙結構，請一併檢查這些項目。
傳遞選定的段落只能提供該等段落的佐證，並不能證明整個檔案沒問題。請保留原始頁面影像作為參考，特別是在校對引文或不熟悉的語言時。
確認來源可信後再進行翻譯
如果您的目標是引用段落或做筆記，經過驗證的擷取內容可能就是終點。您不需要翻譯服務來完成該項任務。
如果您需要閱讀整份其他語言的文件，請將驗證過的檔案作為 PDF 翻譯的起點。BookTranslator 的 OCR 模式會從辨識出的內容重建翻譯後的 PDF；它並不保證能修復任何現有的文字層或完整重現原文件的頁面排版。
在翻譯步驟中保留參考頁面。此處檢查過的相同數量與識別碼將用於 最終的 PDF 翻譯品質保證（QA）階段。流暢的翻譯本身無法告訴您，其來源應該是 18 而不是 13.
