線上翻譯 PDF，不弄壞表格與欄位
加入 Chrome 
TABLE OF CONTENTS
句子讀起來通順還不夠——當數字落在錯誤的表頭底下，或右欄接著錯誤的段落時，問題依然存在。如果你用線上工具翻譯 PDF，表格與欄位通常是最先壞掉的地方，卻也是最不容易在快速掃視時被發現的地方。
為什麼線上 PDF 翻譯會弄壞表格與欄位
PDF 把字符存成座標，它不像 Word 或 HTML 那樣記錄「這是 A 欄」或「這個儲存格屬於那個表頭」。線上工具仍得先擷取文字、翻譯，再把它放回一個原本就不是為了重新排版而設計的頁面。
以下三種失誤模式一再出現：
- 閱讀順序與視覺順序不一致。 在雙欄頁面上，你的眼睛會先讀完左欄才移到右欄。若擷取工具從頁面頂端一路往下掃，就可能把左右兩欄同一高度的文字接成一句毫無意義的話——例如 「營收較去年同期成長 12%，主要來自董事會通過人事凍結」，而這兩段其實分屬不同欄位，只是剛好位在同一高度。W3C 的 PDF3 技術 也針對輔助技術說明了同樣的風險：結構不正確時，多欄頁面可能被當成單欄，從左到右橫跨兩個欄間空白一路唸下去。
- 表格只剩線條與方框。 許多 PDF 把表格框線畫成向量圖形，並把每個儲存格當成獨立的文字片段存放。如果工具只翻譯字串而不重建格線，即使每個字都「正確」，標籤與數字也會混成一團。
- 文字放不下。 翻譯後的文字通常比原文長。Andiamo! 的文字擴張表 指出，英文→法文約增加 +15% 到 +20%，英文→德文約增加 +10% 到 +35%。W3C 的文字長度指引 進一步說明，簡短的標籤擴張幅度最大——而這些字串正好位在狹窄的表頭與欄間空白裡。固定儲存格寬度與狹窄欄位接著就會造成裁切、換行成過高的列，或把內容擠到下一頁。
Google Cloud Translation 的文件翻譯說明 對同樣的弱點說得很直接：複雜的 PDF 版面在資料表格、多欄版面與帶標註的圖表上可能遺失格式——而掃描式 PDF 流失的內容又比原生 PDF 更多。
若想了解任何文件翻譯（不限於 PDF）之後的表格檢查模式，請參閱文件翻譯時表格會發生什麼事。純掃描的檔案請先從OCR 與掃描 PDF 的版面保留開始，而不是這一頁。
三種線上做法比較
你不需要桌上出版排版軟體也能得到可用的結果。但你需要挑對線上做法，讓它與表格、欄位的難度相符。
| 做法 | 最適合的情況… | 表格 | 多欄頁面 | 主要風險 |
|---|---|---|---|---|
| A. 把文字貼進對話式翻譯工具 | 你只想快速掌握一小段文字的大意 | 差——格線直接消失 | 差——閱讀順序全靠猜 | 文字通順，版面卻不能用 |
| B. 把 PDF 上傳到具版面感知能力的線上翻譯工具 | 原生 PDF 且含真實文字；你希望在瀏覽器裡拿回翻譯好的 PDF | 若工具會重建儲存格，機會不小 | 取決於欄位偵測能力 | 狹窄儲存格溢出；對凌亂的掃描檔較弱 |
| C. 線上轉成 DOCX、翻譯、再匯出 PDF | 密集表格或小冊子式欄位，且之後一定得編輯 | 控制力最強——是真正的表格物件 | 若轉檔工具保留了欄位就很強 | 轉檔仍可能誤讀純視覺的表格 |
做法 A 適合確認意思。但當交付物就是 PDF 本身時，它並不是對的工具。
做法 B 是常見的「線上翻譯 PDF」流程：上傳 → 選擇語言 → 下載。優先選擇會回傳可開啟、可檢查之重建 PDF 的工具，而不是只給一份純文字。付費處理整份檔案之前，先抽查最難的表格與欄位交界處。
做法 C 用一次額外轉檔換取可編輯的結構。Microsoft Word 的「開啟 PDF」功能（以及類似的線上轉檔工具）可以把畫出來的欄位變成真正的節，把畫出來的格線變成 Word 表格。接著你翻譯 DOCX 並匯出新 PDF。當做法 B 的預覽仍顯示儲存格塌陷或欄位交錯時，就改用這個做法。
如何線上翻譯 PDF 而不弄壞表格與欄位
步驟 1——確認是原生文字還是掃描檔
在任何 PDF 檢視器中，試著選取一段表格儲存格或欄位裡的段落。
- 如果文字可以反白選取，表示你有一個原生文字層。優先採用具版面感知能力的上傳（做法 B）或 DOCX 來回轉檔（做法 C）。不要在文字乾淨的 PDF 上硬跑 OCR——那等於用猜測取代原本精確的字元。
- 如果頁面表現得像一張圖片，那就是掃描檔。請先做 OCR，然後預期表格與欄位會有更多偏移。參閱掃描 PDF 的 OCR 指南。
步驟 2——處理整份檔案前，先壓力測試難搞的頁面
先打開那些決定成敗的頁面：
- 每一個資料表格（尤其是合併表頭與數值欄）
- 第一個雙欄跨頁
- 側欄、註腳，以及橫跨兩欄的全寬標題
- 任何標籤短於五個字的頁面（擴張風險最高）
複製一頁具代表性的頁面（或使用工具的範例預覽），檢查閱讀順序：左欄最後一句應該接到右欄第一句，而不是接到圖說或側欄。
步驟 3——執行具版面感知能力的線上翻譯（或走 DOCX 流程）
對大多數原生 PDF 而言，請上傳到會重建結構、而不是把結構剝掉的線上文件翻譯工具。OpenL 的 PDF 翻譯工具 的設計目標是在支援範圍內保留表格、圖片、字型與頁面版面，並提供每日免費預覽，讓你可以在付費處理整份檔案前，先用範例判斷表格與欄位。
如果預覽仍顯示格線破損或欄位交錯，就改用做法 C：在線上或 Word 裡把該 PDF 轉成 DOCX、翻譯 DOCX、手動修正儲存格寬度與欄位分界，然後匯出 PDF。
步驟 4——用檢查清單（而不是隨意掃視）審閱表格與欄位
在下載回來的檔案上，依序檢查以下項目：
- 欄位銜接 — 左欄結尾 → 右欄開頭仍然讀得通。
- 表頭 ↔ 儲存格對齊 — 每個標籤仍位在正確數值的上方或旁邊。
- 合併跨距 — 跨欄表頭仍涵蓋原本預定的群組。
- 數字與識別碼 — 數字、單位、負號與代碼維持不變，除非你刻意做了在地化。
- 溢出 — 狹窄儲存格裡沒有被裁掉的最後一行；沒有文字壓在框線或圖形上。
- 全寬元素 — 原本橫跨兩欄的標題與註記仍橫跨兩欄。
Microsoft 針對 Word 表格的無障礙指引建議採用簡單的矩形格線：合併、分割與巢狀儲存格對人和軟體來說都更難保持一致——同樣的結構在 PDF 來回轉檔後也特別脆弱。當表格至關重要時，優先走可編輯的 DOCX 流程，好讓你還原乾淨的格線。
步驟 5——當 PDF 本身就是錯誤的來源時，往上游找原始檔
如果表格層層巢狀、欄位繞著圖形流動，或檔案是平面化的設計輸出，那麼線上翻譯 PDF 只會不斷和格式搏鬥。請索取 Word、InDesign 或試算表原始檔，翻譯那份檔案，再匯出新 PDF。當版面真的能重新排版時，較長的譯文也更容易容納——更多說明請見為什麼翻譯後的文件會變得更長。
快速決策指南
| 你的 PDF 看起來像… | 建議從…開始 |
|---|---|
| 原生文字、單純的單欄本文、一個乾淨的表格 | 線上具版面感知能力的上傳＋預覽 |
| 原生文字、雙欄或數個表格 | 線上上傳；若預覽失敗，改用 DOCX 來回轉檔 |
| 頁面的掃描檔／照片 | 先走 OCR 流程 |
| 框架緊湊的行銷小冊 | 有可編輯原始檔就用；否則以 DOCX 修補 |
溫和的第一步：上傳一頁包含你最頭痛表格與一處欄位交界的頁面到 doc.openl.io/translate/pdf，預覽儲存格與欄位落版的情況，然後再處理整份文件。
Sources
- PDF3: Ensuring correct tab and reading order in PDF documents — W3C WAI — 說明缺乏正確結構時，多欄內容會出現閱讀順序錯誤
- Text size in translation — W3C Internationalization — 為何簡短標籤擴張最多，以及固定寬度的儲存格為何會溢出
- Expansion and contraction factors — Andiamo! — 規劃表格與欄位餘裕時採用的語言組合擴張幅度
- Translate documents — Google Cloud Translation — 官方說明複雜 PDF 可能遺失表格與多欄版面；掃描檔流失的內容比原生檔更多
- Make your Word documents accessible — Microsoft Support — 建議使用簡單表格；合併或分割儲存格會破壞結構
- AI PDF Translator — OpenLDoc — 線上 PDF 翻譯，保留表格與版面，並提供每日免費預覽
