如何在翻譯前修復 OCR 換行與連字號斷詞問題

若要修復 OCR 換行問題，請先識別屬於同一個段落的文字，並僅將多餘的行尾符號替換為空格。對於跨行拆分的單字，請分別判斷應移除還是保留連字號： trans- 接續 lation 會變成 translation，但 well- 接續 known 則會變成 well-known。請保留變更紀錄，並將存疑的合併處與原始頁面進行比對。

切勿對整本書直接執行「移除所有換行符號」或「刪除所有連字號」。 清理後的文字摘錄看似更流暢，卻可能遺失段落、把兩個清單項目合併，或竄改了技術識別碼。我們的目標是獲得一份值得信賴的閱讀或翻譯文本，而不是追求最少數量的換行符號。

本指南從 完成文字辨識後的步驟談起。如果複製 PDF 時出現錯誤的字母或數字，請先 診斷其文字層。修改換行符號無法將辨識錯誤的 B-2O4 轉變為原本預期的 B-204.

判斷各個換行符號代表的意義

請保留原始掃描檔與未經處理的擷取內容。在工作副本中，開啟編輯器的空白字元或段落標記顯示功能。調整編輯器視窗大小：若某一行隨視窗自動重排且未包含儲存的換行符號，那純粹是螢幕自動折行，無需刪除任何內容。

儲存的換行符號則需要不同的檢查方式。請選取一個連續段落、一個標題、一份清單以及任何明顯不同的版面配置，與頁面影像進行比對。切勿單憑扉頁就推斷整個文件的結構。

空行與縮排有助於找出段落，但它們只是線索而非絕對保證。標題後可能沒有空行；縮排的行可能只是清單的延續，而非新段落；以句號結尾的短行可能是段落的最後一行，也可能只是段落中間的一個句子。

如果 OCR 匯出檔提供了排版或區塊資訊，在檢查文字時請務必保留它。僅匯出純文字可能會遺失重建這些邊界所需的關鍵線索。

區分被拆分的單詞與真正的連字號

三種視覺上相似的情況需要不同的編輯處理：

trans-          → translation
lation

well-           → well-known
known

trans\u00ADlation → translation in a verified reading copy

最後一行使用 \u00AD 將原本難以察覺的字元具象化。Unicode 明確區分了 U+00AD SOFT HYPHEN（一種選擇性的字內換行標記）與可見的連字號（例如 U+2010 HYPHEN）。這些字元彼此不能混用。 Unicode 的換行規格 也描述了換行處因語言而異的拼寫變化；單純刪除可見的連字號並串接字母往往不夠齊全。

對於一般散文，移除已確認的選擇性標記可以產出實用的閱讀版本。但若是要建立檔案級的轉錄本，請將原文另外保留：即使單字外觀看起來沒有變化，移除標記仍會改變已編碼的文字內容。

請使用 來源語言 的字典來檢查候選拼寫，然後再回頭對照文章段落。字典詞條只是佐證，並非授權你可以隨意覆寫人名、專用識別碼或歷史拼寫。在文件中重複出現的字形也有助於判斷，但 OCR 辨識錯誤同樣可能會持續重複發生。

舉例來說，我們的德文範例為：

Die Auf-
gabe ist klar.

在這個編寫的範例中，原本預期的單字是 Aufgabe; Duden 的詞條 將其斷字列為 Auf|ga|be。在此處將 Auf- 與 gabe 合併是合理的。然而，這個單一範例並非通用的德文去連字號規則，現代字典的拼寫方式也不應在無人知曉的情況下取代舊版書籍的正字法。

請將網址、目錄代碼、化學名稱、負值以及其他技術性標記視為個別的審核案例。破折號或連字號是否保留，必須遵循原文以及該標記的實際含意，而非依賴英文單字的啟發式規則。

十二個對照範例所揭示的事實

我們製作了一份 可下載的清理示範檔案 ，其中包含十二組原始字串。這些字串原本預期的用詞與結構在編寫時就已確定；隨後我們特意插入了特定的換行符號與連字假影。 這些是人工合成的文字範例，並非 OCR 引擎的直接輸出，也不是書籍掃描的結果。

刻意採用的一刀切基準方法執行了三項替換：移除「連字號加換行」、將剩餘的換行替換為空格，以及移除軟連字號。第二種做法則僅對完全相符的文字套用逐一審核批准的變更，完全不嘗試自動辨識段落或判定單字拼寫。

在 2026 年 10 月 3 日，使用 Node.js 25.2.1 執行測試治具時，粗暴基準線在 12 個範例中僅有 4 個 產生與基準完全相符的文字。而經過核准的路徑則與全部 12 個基準完全吻合，並能透過復原操作還原所有 12 個輸入。此外，它也正確回絕了過期的輸入、非唯一比對以及遺漏的比對項目。

這些結果測試的是針對 已知人工編撰基準進行精確修補套用的效果。這並不代表真實情境下的準確度：核准決策本身就已包含正確答案，且該語料庫是特意挑選用來突顯失敗案例的。我們並未測試商業清理工具、OCR 引擎、翻譯模型或 BookTranslator 的上傳流程。測試過程中亦沒有重試或排除任何樣本。

下載 實際的輸入／輸出與修補記錄檔 以及 重現步驟指南。該 JavaScript 程式碼完全在本地端執行，無須任何依賴套件或網路呼叫，只會輸出結果，不會改寫您的檔案。其內建的檢查機制可防止核准的修改被誤套用至其他文字上，但無法判斷該修改在語言學上是否正確。

一次只清理一個確認無誤的區塊

請先從一段閱讀順序與段落邊界皆已明確的簡短散文區塊著手。切勿直接從包含圖說、引文、清單與註腳的完整章節開始處理。

1. 保留原始副本並記錄來源位置。 讓每個審閱過的段落都附帶其檔案名稱、頁碼、段落或區塊編號，以及所屬語言。
2. 優先標記結構邊界。 將標題、清單項目、詩歌、表格與程式碼從一般散文中抽離出來獨立處理。若您稍後打算移除頁碼標記，請確保將頁碼參照保留在正文閱讀內容之外。
3. 合併該區塊內一般的字間換行。 將每個確認過的換行替換為空格。檢查單字之間沒有黏在一起，且原本存在的空格也沒有變成干擾閱讀的連續重複空格。
4. 分開審閱遭斷字拆分的單字。 檢視完整的語彙元及其周圍語境。記錄為「移除排版連字號」、「保留原有連字號」或「待確認」。切勿將待確認的候選項目直接視為已核准的變更。
5. 在接受變更前務必檢查 diff 差異。 將每個移除的換行分界或連字號與原始文字進行比對。將清理後的版本以新檔名儲存，並一併記錄修改決策。
6. 重新開啟並從儲存的結果中複製文字。 務必檢查即將實際使用的檔案，而不只是編輯器的預覽畫面。

若擷取的文本篇幅較短，使用追蹤修訂手動編輯或進行前後對比可能就足夠了。若是較長的文本，修補清單應記錄確切的原始子字串、替換內容、位置、原因及審核者。使用來源總和檢查碼（checksum）有助於防止在輸入內容變更後誤套用先前的核准結果。

如果您的編輯器提供保留段落的清理模式，請在結構複雜的區塊上測試該模式，而非僅用於流暢的散文段落。若 OCR 當初將段落分界誤判為單一換行符號，保留雙換行符號便無法恢復原本的段落邊界。在深入檢查表格和程式碼之前，請勿隨意刪除縮排或合併所有空格。

掌握何時該回頭對照頁面影像

法文標點符號清楚說明了為何「句尾偵測」不等同於「段落偵測」。在我們撰寫的範例中， Il attend… 與 Le lendemain, il part. 屬於不同的段落。單憑省略號並不足以確立該分界。 魁北克法語局（Office québécois de la langue française）針對省略號（points de suspension）的指引 指出其用途包含表示話語中斷或思緒未盡；請結合頁面版面結構來判斷是否應與下一行合併。

若遇到以下疑義情況，請務必回頭對照原始頁面影像：

如果有多個頁面出現相同的問題，請在整個文件中搜尋該模式並逐一檢查符合項。若是原文文字、閱讀順序或整段內容有誤，請停止正規化，並重新檢查文字辨識或擷取流程。針對跨多種語言的辨識需求，請改用獨立的 多語言 PDF OCR 工作流程.

翻譯前請先驗證清理後的原文

將修改後的區塊與原始頁面進行比對，接著檢查另一個區塊以及擷取內容中出現的每一種不同結構類型。請務必將已知的失敗案例保留在審查清單中。抽樣檢查僅能證明已核對段落的正確性，並無法保證整本書的其餘部分毫無差錯。

• 確認人名、數字、日期與代碼仍與原文一致。
• 檢查所有已移除的連字號，以及跨換行重組的任何拼法。
• 比對段落、標題、清單項目與詩行邊界。
• 確認跨頁轉換時首行與末行皆完整保留。
• 搜尋尚未確認的待處理項目，並將其記錄在審查日誌中以供追蹤。
• 確認最終儲存的版本就是接續進入下一個工作流程的版本。

如果您只需要可搜尋的文字或筆記，那麼這份經過驗證的擷取內容可能就是最終成品。您並不需要透過翻譯來進行修復。

如果您需要將文件轉換為另一種語言，請將驗證無誤的內容準備為支援的文件格式，並使用 全書文件翻譯工作流程。BookTranslator 的 OCR 模式是根據辨識出的內容重新建構翻譯後的 PDF，而非完全複製原始頁面版面；它並非外部文字清理編輯器，也無法保證原文中的每個換行都被正確解析。詳情請參閱 掃描版 PDF 指南 說明了何時需要進行辨識。

請保留原始頁面與清理記錄，以利 最終的 PDF 翻譯品質審查。通順流暢的譯文無法告訴你原文是否原本就包含真正的連字號，也無法顯示兩句看起來連貫的句子其實屬於不同的段落。