Markdown 與 PDF 來回：格式轉換保留什麼
Markdown 與 PDF 各為不同契約服務：標題、清單與簡單表格能大致往返，精確字型、分頁與版面配置會遺失，來回兩次還會漂移，不能當成歸檔循環。
Markdown 與 PDF 最佳化的契約不同。Markdown 是對版本控制友善的結構，PDF 是固定的頁面描述。單向轉過去再轉回來很有用，但它不是無損的歸檔循環。
Markdown 轉 PDF：結構變成頁面
Markdown 轉 PDF（POST /api/v1/convert/markdown/pdf）接受 .md 檔，或一個裡面含有 Markdown 的 ZIP。非 Markdown、非 ZIP 的上傳會被拒絕；純 .md 輸入要求 UTF-8。管線會把 Markdown 渲染成 HTML，啟用表格、刪除線與任務清單，再用面向列印的 CSS 包起來（包含多文種字型堆疊，偵測到阿拉伯文時切換 RTL），最後交給 WeasyPrint 印成 PDF。
正向轉換通常能存活下來的東西：
- 標題、段落、清單與簡單的 Markdown 表格
- HTML 路徑排得下的多文種文字（列印 CSS 涵蓋的 CJK、拉丁與其他文種）
- 給 docs-as-code 工作流的可列印、可分享 PDF
活不下來的：
- 你的編輯器主題字型，在每個檢視器裡都能保證吻合
.md檔裡精確的螢幕換行- 沒有 PDF 對應物的互動式 Markdown 功能（即時核取方塊、可摺疊區段、wiki 連結）
ZIP 輸入是為了把 Markdown 與 HTML 路徑能在文件旁解析的資源打在一起。請把它當成打包上的便利，而不是「每個相對圖片或 CSS 參照，在每個檢視器裡都長得一樣」的保證。
PDF 轉 Markdown：文字層進，Markdown 出
PDF 轉 Markdown（POST /api/v1/convert/pdf/markdown）經由 pdf-inspector 把文字內容抽取成 Markdown，回應是 text/markdown，以 .md 檔下載。文字層乾淨的原生數位 PDF 轉換效果最好。沒有文字層的掃描頁，在你先 OCR 之前只會得到空白的或無用的 Markdown；而本站的 OCR 同樣回傳 Markdown，不是可搜尋的 PDF 文字層。
可以預期：
- 字級啟發式正確觸發時會有標題與段落（
#的層級仍可能需要手工重編） - 辨識成功時表格會變成 Markdown 表格；多欄版面可能被線性化成另一種閱讀順序
- 每頁重複出現的頁首與頁尾（事後自己修剪）
- 影像與以圖片形式存在的公式，不會自動變成本地資源或 LaTeX
如果你要的是沒有標題啟發式的純散文，PDF 轉文字 是更平坦的抽取。表格式匯出回傳 HTTP 204，代表沒有偵測到任何欄狀區塊，見 空表格匯出（204）。
往返究竟證明了什麼
| 大致能存活 | 通常不會 |
|---|---|
| 詞語、標題階層、清單結構 | 像素級精確的頁面幾何 |
| 作為文字的簡單表格 | 精確的字型與字距 |
| 給 Git 或 Agent 的可用草稿 | 與印刷完全一致的分頁 |
往返兩次就會漂移。Markdown→PDF 要經 WeasyPrint 重新排版；PDF→Markdown 要從抽取啟發式重建結構。兩步都不會保留對方版面模型的無損中間狀態。
選定一個權威方向
如果印刷版面才是你的系統紀錄，就保留 PDF，把 Markdown 當成匯出格式或餵給 Agent 的內容。如果你需要 diff、程式碼審查與 Agent 攝取，就優先採用 Markdown，把 PDF 當成發布步驟。不要兩者都存成平等的「真相來源」，還指望編輯之後它們保持一致。
一條實用的 docs-as-code 循環：在 Git 裡編輯 Markdown → 用 Markdown 轉 PDF 產出可分享的成品 → 避免把 PDF→Markdown→PDF 養成日常習慣。當你接手一份原生數位 PDF、又需要餵文字給 Agent 時，才用 PDF 轉 Markdown，然後把那份 Markdown 當成一份新草稿，而不是原分頁的保證。
加密檔案在做任一種轉換之前，都需要經過授權的 解鎖。打不開的損壞檔案，先走 取得資訊／修復。同一批端點的 HTTP 用法，見 開發者。