PDF 轉 Markdown 時表格格式崩壞的原因（7 份檔案實測）

你將 PDF 轉成 Markdown 後表格崩了。這通常不是操作轉換工具的方式有問題，而是 PDF 本身多半沒有把可見的表格以「表格」的形式保存。這篇文章說明表格崩壞的內部機制、用 7 份實際檔案測出的崩壞型別，以及表格崩了之後該怎麼辦。

PDF 大多不把可見的表格存成「表格」

PDF 的內部內容是繪製指令的序列，不是文件結構。頁面的內容存在稱為 content stream 的資料流中，裡面只有「在這個座標放這個字元」「從這裡到那裡畫一條線」這樣的圖形運算子及其引數（參見 Adobe PDF Reference 1.7在新分頁中開啟 的 Graphics / Text 章節）。表格的框線是畫線指令，儲存格內的內容是放在那些線附近的文字。把這兩者關聯起來的資訊，在標準 PDF 中並不存在。

PDF 解析函式庫回傳的資料也能看出這一點。例如 pdf.js 的 getTextContent() 回傳的 TextItem 物件只包含 str（字串）、transform（變換矩陣）、width、height、hasEOL 等欄位，沒有任何列號、欄號或儲存格 ID（PDF.js API 文件在新分頁中開啟）。換言之，轉換工具只能依靠文字的座標和線的位置來「推測」表格結構。

例外是有的。為網頁無障礙等目的而標記了結構標籤的 PDF（Tagged PDF）可以具有 Table、TR、TH、TD 等結構元素，合併儲存格也能指定 RowSpan、ColSpan 屬性（W3C 技術文件 PDF6: Using table elements for table markup in PDF Documents在新分頁中開啟）。但這是 PDF 製作方有意標記時才會有的，一般的 PDF 不保證含有這些標籤。沒有標籤時，轉換器就只能回到座標推測。

7 份檔案用 2 種方式轉換的實測結果

座標推測失誤時會發生什麼，我們用實際的 PDF 檔案測過了。準備了性質各異的 7 份檔案——學術論文、政府技術檔案、填寫表格、統計表、簡報、中央銀行報告——透過 2 種不同原理的轉換管線執行。

• 文字抽出系：pdf.js（pdfjs-dist 6.2.108）+ pdf2md（@opendocsg/pdf2md 0.2.7）。沒有組裝表格的處理步驟。
• 結構推測系：pdf-inspector（@firecrawl/pdf-inspector-wasm 0.1.3）。分析矩形框線、字型、座標來推測表格結構。

測日期為 2026-08-02，執行環境為 Apple M5 Pro / macOS（Darwin 25.5.0）/ Node v26.3.1。7 份檔案都是含有文字層的 PDF，不包含掃描影像 PDF。樣本取得腳本、測量腳本與原始結果資料在本網站的 scripts/benchmarks/pdf-table-extraction/ 中。

從這組測量結果可以看出，兩系崩壞方式恰好相反。文字抽出系在 7 份檔案中表列數全為 0，也就是說完全沒有產出表格。結構推測系則一定會產生表格，但列數多不等於提取正確。

有一個例子說明為什麼不能只看列數判斷成敗。多欄中央銀行報告的標題和正文全部被塞進表格儲存格，崩壞嚴重，但表列占整體輸出的比例是 0.43。而真正含有表格的稅務填寫表單，表列比例是 0.45。這兩個數值用單一閾值無法區分。換句話說，表格列數多不代表表格提取正確。

崩壞型別 1 — 表格消失，只剩散文排列

第一種崩壞是表格完全沒有以表格形式出現。儲存格內的文字仍然被抽出，但行列的區分完全消失，數值和項目名稱像一般文章一樣連在一起輸出。實測中文字抽出系就是這種行為，7 份檔案的表列數全為 0。

這種崩壞有一個好處：一眼就能看出結果崩了。「該有表格的地方沒有表格」這件事很明顯，所以你比較容易回去看原檔案、手動處理。

但有一個副作用。表格的每一列可能被錯誤地升級為 Markdown 標題（#、## 等）。實測中多層統計表用文字抽出系轉換後產出了 1360 個標題，而原檔案中實際的標題目視數約 4 個。如果你轉換後的 Markdown 目錄膨脹到數百項，就要懷疑這個副作用。

崩壞型別 2 — 表格形式還在，但儲存格配置錯亂

第二種崩壞是 Markdown 表格語法本身是完整的，但哪個值該進哪個儲存格搞錯了。實測中結構推測系屬於這種。多層統計表被轉成 405 列的表格，但多年的統計數值全部擠進同一個儲存格。

|15～ 64歳 6625 5878 6678 5893 6732 5912 …|15～ 24歳 595|25～ 34歳 1168|

這種比第一種危險得多。管線符號（|）和分隔行（---）都正確，所以 Markdown 檢視器會把它渲染成整齊的表格，你可以直接貼進報告或文件。但如果某個數值偏了隔壁一欄，沒有對照原檔案的讀者很難察覺。表面上看起來沒壞、實際上嚴重失真——這點讓它比第一種崩壞更需要警惕。

圖形或多欄正文被誤判為表格的情況

結構推測也會把不是表格的元素誤判為表格。實測中確認了 2 個典型案例。

NIST Cybersecurity Framework 2.0 的圓環圖（Fig. 1 CSF Core structure）中，沿圓弧排列的文字被辨識為表格儲存格，而且首字遺失：

| Fig. 1. CSF Core structure |||
| --- | --- | --- |
| DENTIFY | ROTECT | ETECT ESPOND |

正確的詞是 IDENTIFY、PROTECT、DETECT、RESPOND。沿圓環曲線排列的文字被拆分，首字母被當成獨立元素處理，結果變成沒有意義的詞。

另一個案例是整份檔案變成一個巨大的表格。多欄中央銀行報告中，標題和正文段落全部進入了表格儲存格：

|||||2025 年５月１日|
| --- | --- | --- | --- | --- |
||【基本見解】|1|經濟・物價情勢的展望（2025 年４月）＜概要＞|日本銀行|

這份檔案中結構推測系只產出了 1 個標題，就是檔案末尾的「以上」。因為多欄版面被整體解釋成了多列的單一大表格。

換轉換方式能修的崩壞，和修不好的崩壞

有沒有必要換轉換工具或方式，取決於崩壞的根本原因。

一般傾向是：「有沒有表格出現」換方式會改變。但「出現的表格是否正確」在原 PDF 沒有結構資訊時，用任何方式都只是推測，換工具也無法保證準確性。

要確認你的 PDF 屬於哪種崩壞，最確定的方式就是實際轉一次看看。PDF 轉 Markdown 工具 在瀏覽器內部完成所有轉換處理，檔案不會傳送到任何外部伺服器，你可以安全地測試結果。

修復崩壞表格的方法

轉換結果務必與原件比對

含有表格的 PDF 轉換成 Markdown 後，不要直接使用，一定要跟原 PDF 逐一比對。特別是崩壞型別 2，光看畫面無法察覺，原件比對是唯一可靠的偵測手段。

比對的順序建議如下：

1. 確認列數和欄數與原件一致。
2. 檢查標頭列的項目名稱是否與原件順序相同。
3. 將每列首格和末格的值與原件比較。偏位通常先出現在兩端。
4. 原件中有合併儲存格的區域，要個別確認。Markdown 表格無法表達合併儲存格，所以一定會以某種形式被變形。

數值表格建議重做而非修補

金額、測量值、統計數值這類一個儲存格偏了就會改變意義的表格，重新製作比修補錯位的 Markdown 表格更快更安全。從原 PDF 複製表格文字，貼進試算表（Excel 等）整理後，匯出為 CSV，再用 CSV 轉 Markdown 工具 轉換，儲存格之間的對應關係就能精確保持。

如果你想確認 Markdown 表格語法（管線符號的位置、分隔行、對齊冒號、儲存格內管線符號的跳脫寫法），可以參考 GFM 規格 Tables extension在新分頁中開啟。表格語法不是 CommonMark 核心規格，而是 GitHub Flavored Markdown 的擴充規格，所以貼上目標的平台是否支援 GFM 表格也值得一併確認。本文站也有 Markdown 表格語法：對齊、儲存格內換行與轉義總整理 一文，整理這些細節。

哪些 PDF 容易崩壞、哪些相對安全

這份清單不是絕對保證，而是用來事前降低表格崩壞風險的基準。

轉換前確認

• 在 PDF 檢視器中用滑鼠拖曳選取表格內的文字，看是否能選取。選不了就是沒有文字層的影像，不適合轉換。
• 表格是否有明確的框線。沒有框線的表格，儲存格邊界的推測會更困難。
• 頁面是否為單欄。雙欄或三欄版面可能讓正文欄本身被誤判為表格。
• 表格是否跨頁。跨頁的表格大概率會被拆成每頁各一個表格輸出。
• 是否有合併儲存格。Markdown 表格語法沒有合併儲存格的寫法，一定會變形。
• 表格內是否混有圖形或圖示。圖形中的文字可能被當成表格儲存格抽入。

轉換後要懷疑的跡象

• 每列的欄數不一致。代表列與列之間的邊界推測在搖晃。
• 空白儲存格異常多，或分隔行前方出現 ||||| 這樣只有分隔符沒有內容的行。
• 標題（#）數量異常多。表格內的正文列可能被誤判為標題。
• 出現意義不明的詞，像實測中的 DENTIFY 那樣，是文字被拆斷的跡象。
• 表格儲存格內整段塞進明顯是正文的長句。

掃描 PDF 沒有文字資訊，無法轉換

用掃描器或相機拍紙本文件製作的 PDF，整頁就是一張圖片。眼睛看得到文字，但檔案內部沒有文字資料。這種情況下，根本談不上表格崩不崩壞——可抽取的文字本身就沒有。

這類檔案需要的是光學文字辨識（OCR），不是格式轉換。FormatArc 的 PDF 轉換工具沒有內建 OCR 引擎，所以對這類掃描 PDF 會顯示「無法轉換」的提示訊息，不會回傳任何猜測性的輸出。明確告知無法轉換，比產出可能錯誤的資料更安全。

要確認你的 PDF 是不是掃描件，在檢視器中拖曳文字試試。選不中就代表是圖片。

常見問題

換一個轉換工具，表格就能正常嗎？

取決於崩壞原因。如果完全是因為工具不支援表格組裝導致表格沒出現，換到帶有結構推測功能的工具至少能產出表格形式。但如果問題是儲存格配置錯位，在原 PDF 沒有結構資訊的情況下，任何工具都靠座標推測，沒有保證能修正。

Tagged PDF 就不會崩嗎？

如果結構標籤正確標記了，就可以直接從檔案中讀取 Table、TR、TH、TD 結構，不需要推測。但標籤有沒有是 PDF 製作時決定的，讀取的一方無法選擇。而且即使有標籤，內容也可能與實際視覺版面不一致。

掃描 PDF 也能轉換嗎？

FormatArc 不行。掃描 PDF 沒有文字層，需要 OCR 處理，而這個工具不支援 OCR，所以會顯示無法轉換的提示。

有辦法只抽出表格嗎？

沒有專門從 PDF 中只切出表格的功能。但可以從原 PDF 選取表格區域、複製到試算表整理後儲存為 CSV，再轉換為 Markdown，就能完整保留儲存格的對應關係。處理數值表格時，這條路最可靠。

總結

PDF 的表格在轉 Markdown 時崩壞，根本原因是 PDF 多半沒有把可見的表格保存為可重用的邏輯結構，轉換工具只能從文字和線的座標推測結構。實測中確認了兩種崩壞：完全不產出表格、以及表格形式保留但儲存格配置錯誤。後者外表看不出來有問題，所以含有表格的 PDF 轉換後務必與原件比對。

想確認你的 PDF 會怎麼轉，用 PDF 轉 Markdown 工具 試試看。所有檔案都在瀏覽器內部處理，不會傳送到任何外部伺服器。