VS Code 本身並未內建 PDF 轉 Markdown 的轉換器，因此可靠的做法是先在 Word 或其他相容的編輯器中將 PDF 轉成 .docx 檔，然後把那份 .docx 餵給一個在本機、瀏覽器中運作的 DOCX 轉 Markdown 工具，整個過程資料都不會離開你的裝置。這個瀏覽器工具會讀取 .docx 內部的 Office Open XML 封裝，擷取主要文件結構，並輸出一個可下載的 .md 檔，你可以直接在 VS Code 中開啟進行編輯修訂。由於每一個位元組都留在你的機器上，這個工作流程特別適合草稿、內部報告，以及你不想上傳給第三方的筆記。最終產生的 Markdown 是結構性而非視覺性的:明確的 Word 標題會變成 Markdown 標題，一般段落維持為段落，簡單的矩形表格會變成管線表格;而自訂字型、頁碼、欄位、圖片、追蹤修訂和複雜樣式則會刻意略過，不會去猜測它們的內容。請在 VS Code 中開啟產生的檔案，確認標題、連結、清單和表格標頭後再發佈。
為何 VS Code 本身無法直接把 PDF 當成 Markdown 開啟
VS Code 是一個對磁碟上既有 Markdown 檔案支援度很強的程式碼編輯器，但它並不包含能渲染任意 PDF 頁面內容的引擎。直接開啟 .pdf 檔時，你看的是原始的 PDF 預覽，而不是可編輯的 Markdown。擴充套件可以在使用者提供的文字外面包一層 Markdown 預覽，但沒有任何擴充套件能單靠 PDF 物件流，自行重建出 Word 風格的標題階層、矩形表格格線，或一段內文文字。因此，這個問題最可靠的做法就是兩步驟:先從 PDF 產出結構化、可編輯的中繼檔，再在本機把那份中繼檔轉成 Markdown。
最常見的中繼檔格式就是 .docx，因為 Word 和幾套辦公室軟體都能開啟 PDF 並重新存成 Word 文件。這個重新存檔本身已經是有損的:圖形、沒有 OCR 層的掃描文字、自訂字型和精確的分頁都不會被帶過去。會保留下來的，正是下一步實際需要的結構骨架，也就是段落邊界、文件作者使用樣式庫時所設定的明確標題樣式，以及矩形表格格線。掌握這份骨架後，本機轉換器就能產生比任何從字級或粗體猜測結構的工具都更接近原始草稿的 Markdown。
本機 DOCX 轉 Markdown 轉換器實際做了什麼
DOCX 轉 Markdown 轉換器會接收一份 .docx Word 文件，並在你的瀏覽器中將其轉成實用的 Markdown 草稿。它會用 JSZip 載入器讀取 Office Open XML 封裝，透過標準的 DOMParser 解析主要文件的 XML，然後把明確的 Word Heading 1 到 Heading 6 段落樣式對應到從 # 到 ###### 的 Markdown 層級。一般段落維持為一般段落，簡單的矩形表格則會輸出為 Markdown 管線表格，並以第一列作為表格標頭。儲存格內部對 Markdown 有特殊意義的字元會經過跳脫處理，以免儲存格裡的管線字元破壞表格語法。
這個工具刻意拒絕自行捏造看不到的結構。它不會從字級或粗體文字去猜測標題層級，所以從未使用 Heading 1 樣式的自訂樣式標題會維持為一般段落，而不會被悄悄升級。合併儲存格、巢狀表格、列數不一致的情況，以及複雜的清單編號，則會退回為易讀的 Tab 分隔文字，而不是硬塞進去一個會失真表達資料的 Markdown 表格。Tab 與換行會以可見的形式保留。版面配置、圖片、註解、追蹤修訂、欄位、引註、文字方塊、自訂字型和主題樣式都被明確排除在合約範圍之外;這個轉換器處理的是結構，而非視覺呈現。
在 VS Code 中將 PDF 轉成 Markdown:完整流程
完整流程包含六個具體步驟，而且在你主動把 PDF 送給轉換器之前，原始 PDF 都會一直留在你的裝置上。
- 在 Microsoft Word、Google Docs 或其他支援 PDF 匯入的辦公室軟體中開啟 PDF，然後用「另存新檔」將其匯出為 .docx 檔。請在樣式窗格中檢查標題，確認各章節標題使用的是內建的 Heading 1 到 Heading 6 樣式;任何只以粗體呈現的標題，在步驟 3 中都不會轉成 Markdown 標題。
- 在瀏覽器中開啟 DOCX 轉 Markdown 轉換器，從你的裝置中選擇那份 .docx 檔。瀏覽器會先在本機載入前驗證封裝大小、ZIP 目錄結構、項目數量和宣告的展開大小;損壞、有密碼保護、不受支援或超大的檔案都會被明確地拒絕。
- 等待本機預覽載入完成。預覽是唯讀的，會顯示轉換器從 Word 文件產生的 Markdown 近似結果，包括標題層級，以及矩形格線能呈現的所有管線表格。
- 把產生的 .md 檔下載到你能從 VS Code 存取的位置，例如 Markdown 檔案最終要放置的儲存庫。這個檔案會以純文字 .md 檔的形式落地，這正是 VS Code 依檔案關聯視為 Markdown 的格式。
- 在 VS Code 中開啟下載的 .md 檔。利用 Markdown 預覽側邊面板，比對渲染後的標題、段落、清單和表格與原始 Word 文件的差異，並標記出任何需要編輯修正的地方。
- 進行每份文件轉換後都會需要的小幅編輯修訂:確認每個標題確實是章節標題、修正依賴 Word 特殊行為的連結或清單、檢查表格標頭，並移除任何在目的地中沒有意義的暫存格式。
結束時，原始 PDF 並未上傳到任何地方;磁碟上只有你在本機產生的 .docx，以及轉換器在本機產生的 .md 檔，兩者都能在不接觸任何遠端服務的情況下直接刪除。
哪些會帶到 Markdown，哪些不會
Word 的功能集合遠比 Markdown 豐富，因此轉換器只能帶過去 Markdown 能表達的內容。下表列出 DOCX 轉 Markdown 轉換器能辨識的 Word 元素，以及每個元素在輸出中的對應結果。
| Word 元素 | Markdown 輸出 |
|---|---|
| 明確的 Heading 1 到 Heading 6 段落樣式 | 對應的 Markdown 標題層級，從 # 到 ###### |
| 一般內文段落 | 一般段落文字 |
| 簡單的矩形表格 | Markdown 管線表格，以第一列為標頭，儲存格內的管線字元會跳脫 |
| Tab 字元和換行 | 以可見的形式保留為純文字 |
| 用自訂段落樣式、粗體或大字級模擬出來的假標題 | 維持為一般段落;工具不會依外觀升級 |
| 合併、巢狀或列數不一致的表格 | 退回為 Tab 分隔文字，而不是產生誤導的表格 |
| 圖片、圖形、圖表、註解、追蹤修訂、欄位、引註、文字方塊、主題樣式 | 不會在輸出中呈現;不會被悄悄捏造 |
先讀過這張表，有助於釐清哪些內容是忠實的，哪些是 VS Code 中的編輯修訂必須手動處理的。
在 VS Code 中整理草稿
Markdown 是原始碼內容，因此任何文件轉換後進行簡短的編輯修訂都是預期中的事，而不是轉換器失敗的跡象。請使用 VS Code 的分割 Markdown 檢視，將渲染預覽與原始 Word 檔相互比對。確認分節符號已轉為標題分隔、清單仍讀起來像清單，而且表格標頭能準確描述欄位內容。VS Code 的大綱檢視是由 Markdown 標題驅動的，是快速找出實際上是子標題卻被標成標題(或反之)的好方法;修正一個字元，就能修正整個大綱，以及下游工具據此建立的所有目錄。
如果某個標題在輸出中變成內文，幾乎可以確定原始文件使用的是自訂樣式或粗體文字，而非 Heading 1 到 Heading 6 樣式。在 Word 中套用正確的段落樣式後重新匯出 .docx，再重新執行轉換器，就能在不必手動修改 .md 檔的情況下修正這個問題。如果某個表格讀起來變成 Tab 分隔文字，原始表格很可能有合併儲存格、巢狀表格或列數不一致的情況;此時可以在 Word 中先簡化表格，或者接受 Tab 分隔的備援結果作為正式版本。
何時該改用其他獨立的工具
當目的地是文件網站、儲存庫、筆記應用程式、CMS 編輯器或靜態網站工作流程，而純 Markdown 比二進位 Word 檔更容易審閱和版本控管時，本機轉換器是正確的起點。但若只是要純粹抽取文字、完全不需要任何 Markdown 格式，那它就不是合適的起點:在這種情況下，DOCX 轉文字轉換器能從同一份 .docx 產生乾淨的純文字。它同樣不適合用來蒐集文件連結或擷取嵌入的圖片;專門處理 Word 超連結和擷取圖片的工具才能在不做廣泛保真度承諾的情況下，完成這些單一目的的工作。
把這些任務分開處理，能避免單一轉換器默默承諾超出其能力的成果。一份本機的、結構性的 Markdown 草稿，加上在 Markdown 編輯器中快速的編輯審閱，才是務實的目標;而針對這個目標，DOCX 轉 Markdown 轉換器提供了一個乾淨的起點，過程中無需上傳來源檔。
如果你正在權衡各種選項，Emoji 複製貼上詳解:從代碼到剪貼簿對此有詳細說明。
如果你正在權衡各種選項，特殊字元:命令列與線上複製貼上的比較對此有詳細說明。