Pandoc 無法直接將 PDF 轉換為 Markdown，因為它沒有 PDF 輸入讀取器；PDF 必須先轉換成 Pandoc 能讀取的可編輯來源格式。
PDF 與 Markdown 描述的是不同的結構。PDF 呈現的是定位於頁面上的內容，通常不會保留來源應用程式的標題樣式，而 Markdown 則會標示標題、段落、清單、連結、程式碼與表格。Pandoc 可以在已辨識的文件格式之間進行轉換，也能輸出 PDF，但無法將 PDF 作為輸入匯入。
因此，實務工作流程包含兩個階段：先從 PDF 還原可編輯的內容與結構，再使用 Pandoc 將該中間檔案轉換成 Markdown。原始 DOCX 不需要第一階段，而僅含影像的 PDF 則需要 OCR。
直接使用 PDF 指令失敗的原因
諸如 pandoc input.pdf -f pdf -t gfm -o output.md 的指令無法運作，因為 -f 選項會指定輸入格式，而 PDF 並不是 Pandoc 支援的輸入格式。這是輸入格式的限制，而不是檔案損毀的問題。
文字擷取會帶來另一類挑戰。以文字為基礎的 PDF 可能會擷取乾淨的字詞，卻將多欄內容、連續文字、表格儲存格或標題壓平為一般行。掃描式 PDF 則會在這些結構問題之外增加辨識錯誤。OCR 可以讓字元變得可用，但無法可靠判斷哪些文字是標題、哪些標籤與數值相關，或哪些儲存格構成表格。仍然需要結構化的中間檔案或人工編修。
選擇最可靠的來源
請根據實際擁有的檔案選擇轉換路徑：
| 可用來源 | 第一階段 | Pandoc 輸入 | 預期結果 |
|---|---|---|---|
| 原始 DOCX | 無 | DOCX | 最有可能保留明確的標題、清單與表格 |
| 以文字為基礎的 PDF | 擷取為 DOCX 或 HTML | DOCX 或 HTML | 閱讀順序與階層結構取決於擷取工具 |
| 掃描式 PDF | 透過 OCR 轉為 DOCX 或 HTML | DOCX 或 HTML | 預期需要修正 OCR 錯誤與不完整的結構 |
| 簡單的純文字 PDF | 擷取為純文字 | 文字 | 適用於段落，但原始階層結構已不存在 |
原始 DOCX 是較理想的選擇，因為其標題與表格結構可能已經明確標示。對於只有 PDF 的資料，相較於純文字，DOCX 或 HTML 能提供 Pandoc 更多的語意資訊。如果需要另一步驟說明這種中間檔案方法，請參閱透過 DOCX 將 PDF 轉換為 Markdown。
透過可編輯來源使用 Pandoc 將 PDF 轉換為 Markdown
- 確認 Pandoc 已可用。 安裝適用於您作業系統的 Pandoc，在包含檔案的資料夾中開啟終端機，然後執行 pandoc --version。如果系統無法辨識該指令，請完成安裝或修正可執行檔路徑，再繼續進行。
- 建立可編輯的中間檔案。 如果存在原始 DOCX，請優先使用。否則，請使用能產生 DOCX 或 HTML 的擷取工具處理 PDF。對於以文字為基礎的 PDF，其中一種可行的 HTML 轉換方式是 pdftohtml -stdout input.pdf > extracted.html。對於僅含影像的 PDF，請使用 OCR，並將結果匯出為 DOCX 或 HTML，而不是另一個 PDF。
- 檢查並修復中間檔案。 請在文字編輯器、文件編輯器或瀏覽器中開啟該檔案。檢查閱讀順序、移除擷取產生的雜訊，並將真正的章節標題轉換為 HTML 標題元素或 Word Heading 1–6 樣式。將包含合併儲存格、巢狀表格或不一致列數的表格壓平或重新建立。
- 對中間檔案執行 Pandoc。 對於 DOCX，請使用 pandoc source.docx -f docx -t gfm --wrap=none -o output.md。對於 HTML，請使用 pandoc source.html -f html -t gfm --wrap=none -o output.md。明確指定格式的旗標可避免 Pandoc 必須自行推測輸入類型。
- 將結果與 PDF 比較。 在 Markdown 編輯器中開啟 output.md，逐一核對每個標題、表格、清單、連結、程式碼區塊與段落是否符合來源頁面。請修正 Markdown 中的擷取錯誤；如果在修復中間檔案的結構時較容易修正，則可返回中間檔案處理。
- 發布前完成最終定稿。 移除暫存註記與損壞的內容，然後將已審閱的檔案儲存至您的儲存庫、CMS、文件網站、筆記應用程式或靜態網站工作流程。
常見中間格式的 Pandoc 指令
相同的基本模式適用於數種來源類型：指定輸入、使用 -f 選擇其格式、使用 -t gfm 選擇 GitHub-Flavored Markdown，並使用 -o 寫入結果。
- DOCX： pandoc source.docx -f docx -t gfm --wrap=none -o output.md
- HTML： pandoc source.html -f html -t gfm --wrap=none -o output.md
- 純文字： pandoc extracted.txt -f markdown -t gfm --wrap=none -o output.md
--wrap=none 選項可避免 Pandoc 換行處理長的 Markdown 行。如果目的地要求嚴格使用 CommonMark，而非 GitHub-Flavored Markdown，請將 gfm 替換為 commonmark。純文字無法提供可靠的標題階層，因此在轉換前，請加入 Markdown 標題符號或使用結構化的中間檔案。
在 Pandoc 讀取前重建結構
PDF 擷取可以辨識字詞與大致位置，但不會保留文件語意。大型粗體的一行可能是標題、標籤，或只是特別強調的文字。若要讓 Pandoc 的結果可預測，請使用明確的 HTML 標題元素，例如 h1 到 h6，或在 DOCX 中套用 Word Heading 1 到 Heading 6 樣式。不要只依賴字型大小、粗體或視覺醒目程度。
基本 Markdown 表格在來源為矩形結構時效果最好。請保留一個標頭列，並讓每一列的儲存格數量保持一致。合併儲存格、巢狀表格與不一致的列數無法在簡單的垂直線表格中忠實呈現，因此請在執行 Pandoc 前，將它們重新建立為個別表格或易讀文字。通常而言，在中間檔案中修正結構，會比反覆修補最終的 Markdown 產生更乾淨的結果。
僅在頁面需要時執行 OCR
當 PDF 包含沒有可選取文字的掃描頁面影像時，就需要 OCR。已經提供可選取字元的 PDF 並不一定需要 OCR，而對乾淨文字執行 OCR 反而可能引入錯誤，而非改善結果。對於掃描文件，請先透過 OCR 轉為 DOCX 或 HTML，檢查結果，然後再將該檔案傳給 Pandoc。
OCR 輸出仍然需要審查。請檢查名稱、數字、標點、行序、欄位邊界與表格標籤。光學辨識無法還原原始 Word 標題樣式、超連結、註解、追蹤修訂或其他互動結構。如果頁面包含複雜表格或不可靠的閱讀順序，手動重建可能比硬將擷取的內容塞入 Markdown 更準確。
來源還原後使用本機 DOCX 捷徑
如果有 DOCX 版本，而且您想要以瀏覽器為基礎的結構草稿，又不想安裝 Pandoc，DOCX to Markdown Converter 可以從一個 .docx 文件建立 Markdown 檔案。它不是 PDF 讀取器，因此只有在原始 DOCX 存在，或其他程序已產生 DOCX 複本時才能使用。
支援的瀏覽器工作流程
- 從您的裝置中選擇一個 .docx Word 文件。
- 檢查本機 Markdown 預覽，特別留意標題與表格輸出。
- 下載 .md 檔案，並在 Markdown 編輯器中進行任何編修調整。
此轉換器會在本機處理文件，不會上傳文件。只有明確的 Word Heading 1–6 段落樣式會從 1 個井號到 6 個井號轉換為 Markdown 標題。一般段落會維持為文字，自訂樣式不會提升為標題。簡單的矩形表格會轉換為以第一列為標頭的垂直線表格；合併、巢狀或不一致的表格則會改用易讀的分隔符文字呈現。定位點與換行會保持可見，而不會在未告知的情況下移除。
這刻意是結構轉換，而不是 Word 的視覺複本。字型、間距、欄位、頁碼、影像、圖表、註解、追蹤修訂、功能變數、引用、文字方塊與佈景樣式都不在其功能範圍內。受密碼保護、損毀、不支援、體積過大或格式異常的套件會被拒絕或停止轉換，而不會產生誤導性的結果。可下載的 Markdown 是起始草稿，因此發布前請先審閱。
發布前檢查輸出
指令成功執行，只能證明 Pandoc 已讀取中間檔案，並不代表 PDF 的每個細節都已還原。請有系統地審查結果：
- 標題： 確認每個標題都代表真正的章節，而且其層級符合文件的階層結構。
- 表格： 檢查標頭列、儲存格對齊，以及複雜的來源表格是否已正確壓平。
- 清單與連結： 修正依賴 Word 特定行為的編號，並驗證每個目的地。
- 閱讀順序： 將多欄內容與 PDF 比較，尤其是在 OCR 或 HTML 擷取之後。
- 字元： 找出 OCR 錯誤、損壞的符號、錯置的標點與受損的空白字元。
- 視覺元素： 另行確認影像、圖表、註腳，以及文字導向的轉換可能省略的其他內容。
審查期間，請將原始 PDF 與 Markdown 放在一起。目標不是讓轉換後的檔案在螢幕上看起來完全相同；而是為目的地保留有用的內容與結構，同時讓所有無可避免的損失清楚可見。