Markdown Viewer：把 Markdown 匯出成 Word 的開源擴充，圖表與 LaTeX 公式一起保留

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Markdown 寫起來輕快，可是一旦要交件，對方要的往往是 Word 檔。手動把 Mermaid 流程圖重畫一次、把 LaTeX 公式截圖貼上去、把程式碼區塊重新排版，半小時的內容常常花兩小時在排版。Markdown Viewer 這個開源擴充把這件事壓成一鍵匯出，而且匯出引擎確實是在你的瀏覽器本機跑。但它喊出的「完全本機、不碰任何遠端」話術，需要分成兩層來讀：文件內容處理在本機是真的，擴充本身卻要求讀取你所有網頁的權限、也會外連 Google 字型伺服器載入字型。值不值得裝，要看你願不願意用這個權限，換它把圖表與公式一次帶進 Word 的能耐。

它宣稱能把 Markdown 變出什麼樣的 Word

官方在倉庫描述與 README 列出的匯出能力相當進取。PlantUML、Mermaid、Vega 與 Vega-Lite、drawio、Canvas、Infographic、Graphviz 這七類圖表，會被轉成高解析度圖片嵌進 Word；LaTeX 公式不是變成靜態圖，而是宣稱轉成 Word 原生的可編輯方程式；程式碼區塊有上百種語言的語法標示；另外有官方宣稱的二十九種佈景主題，覆蓋商務、技術、學術等版面風格。這份清單涵蓋的圖表類型，比多數同類轉檔工具都來得完整，是這個擴充主要打出來的差異化。整個匯出動作在瀏覽器裡點一下就能完成，不需要先把檔案上傳到任何第三方網站，也不需要在命令列安裝額外的轉檔引擎。

這裡有兩件事要分清楚。一方面，圖表類的轉換是「變成圖片嵌入」，不是把 Mermaid 原始碼搬進 Word 讓你之後還能改流程圖，匯出後要改圖只能回 Markdown 改再重匯。另一方面，LaTeX 公式轉成可編輯方程式是作者最主打的賣點，也是它與一般「截圖貼上」做法的差異所在，但這部分屬於作者宣稱的能力，實際在 Word 裡能不能順利改繫數、改上下標、與 Word 內建的方程式編輯器相容到什麼程度，需要你自己裝起來跑一輪才知道。把它當成「格式保真度高於手動」來期待是合理的，當成「無損還原」則超出能驗證的範圍。

匯出引擎在本機跑這件事可以信

會把這個工具獨立出來看，是因為它的匯出鏈真的設計在本機。從 chrome/manifest.json 看，擴充要求的 offscreen 權限搭配 script-src 裡的 wasm-unsafe-eval，對應的是它在背景透過 WebAssembly 與 offscreen API 把 Mermaid 這類需要完整渲染的圖表先畫成 PNG，再塞進 Word。offscreen API 是 Chrome 為 MV3 擴充提供的背景渲染機制，讓 service worker 不能直接碰 DOM 的限制下，仍能在隱藏頁面裡完成圖表繪製；wasm-unsafe-eval 則是因為 Mermaid、Graphviz 這類函式庫的運算需要 WebAssembly。web_accessible_resources 也把 libs/mermaid.min.js、ui/offscreen-render.html、core/drawio2svg.js、core/draw-uml.js 列進去，這條渲染鏈是瀏覽器本機完成，不需要把你的 Markdown 內容送外部伺服器才能生成圖表。

換句話說，你的文件內容不會因為「要匯出 Word」這個動作離開本機。這點與它的競爭力直接相關，也是它有別於一堆「把 Markdown 丟上雲端轉檔」線上服務的關鍵。對於寫技術文件、研究筆記、甚至合約草稿這類不該外流的內容，本機匯出是實質的隱私優勢，而不是行銷話術。

但擴充本身要讀你開的每一個網頁

「本機處理」可信，不等於「這個擴充不碰網路」。chrome/manifest.json 裡 host_permissions 涵蓋 file:///*、https://*/*、http://*/*，也就是你本機的 Markdown 檔加上所有 http 與 https 網頁都在授權範圍內。content_scripts 進一步在 document_start 時機把 core/content-detector.js 注入到 file:///* 與 *://*/* 的頁面，目的是在頁面開啟的第一時間偵測這是不是一份 Markdown，再決定要不要進入渲染流程。

這是它能在瀏覽器裡直接預覽與匯出 Markdown 的代價：你得授權它看你開的每個網頁與本機檔案。它是不是只在遇到 Markdown 時才動作、會不會把其他頁面的內容往外送，只能從原始碼與隱私政策判斷，沒辦法從權限清單一眼斷定。換個角度看，這也是絕大多數「能在所有網頁上動作」的瀏覽器擴充共同面對的信任模型，並非這個擴充獨有，但對隱私特別在意的讀者來說，這才是真正要衡量的信任成本，而不是「local」這個字能打發掉的。

Pin

隱私政策跟現版程式碼對不上

實際比對 PRIVACY.md 與 chrome/manifest.json 會發現一個落差。政策頁的權限說明段列了 tabs，但現版 manifest 的 permissions 並沒有 tabs；相反地，現版 manifest 有的 contextMenus 與 alarms，政策頁完全沒提到。downloads 在政策裡寫成一般權限，在 manifest 則放在 optional_permissions，屬於要用的時候才問，定位並不一樣。

這是典型的政策跟不上程式碼現況。對想精確知道「擴充到底能讀什麼、不能讀什麼」的讀者來說，只看政策頁不夠，得自己對著 manifest 看。政策本身也透露一個訊號：它的主要語言是中國大陸慣用的簡體中文，標題與更新日期用的是當地寫法，英文版排在後面。英文版的內容與簡體版一致，這代表政策內容仍可信，但語言排序暗示了作者預設的主要受眾。

字型從 Google 來，與「不使用任何遠端伺服器」的宣稱有落差

政策頁寫得很斬釘鐵：「不使用任何遠端伺服器」、「不向任何第三方發送資料」。前一句在嚴格意義上並不準確。chrome/manifest.json 的 content_security_policy.extension_pages 把 connect-src 設成允許 https://fonts.googleapis.com 與 https://fonts.gstatic.com，style-src 與 font-src 也涵蓋這兩個網域，也就是擴充會從 Google 字型伺服器載入字型來渲染文件。

這在實務上很常見，也不代表你的文件內容被送出去，字型下載是單向取資源，Google 拿到的是「有人要某個字型」這個層級的請求，不是你的 Markdown 文字。但如果你把「不使用任何遠端伺服器」理解成擴充完全斷網、連一個位元都不往外送，那與程式碼的事實有出入。「文件內容不上傳」與「擴充不碰任何網路」是兩件不同的事，這裡成立的是前者，後者只能算宣傳層級的簡化。在嚴格管控對外連線的企業環境裡，這條外連也值得注意，因為它會把請求送到 fonts.googleapis.com 與 fonts.gstatic.com，若公司防火牆封鎖這兩個網域，擴充仍可運作但會退回內建字型，視覺效果可能與展示截圖有落差。

是 GPL-3.0 真開源，而且最近還在更新

授權狀態值得單獨講。GitHub 倉庫頁面顯示授權為 NOASSERTION，但其實只是因為 LICENSE 檔的標準偵測標頭沒被認出來；package.json 的 license 欄位明確寫 GPL-3.0-only，LICENSE 檔是完整的 GNU GPL v3 全文。換句話說它是真開源、且是強 copyleft，你可以自由使用、研究、修改、再散布，但衍生作品必須同樣以 GPL-3.0 釋出。想把它的程式碼包進封閉商業產品的人，要注意這個授權會把衍生作品「傳染」成同樣必須開源的狀態，這對單純使用者無影響，對想把它的渲染鏈整進自己商業服務的團隊則是實質限制。

Pin

維護狀態也正向。倉庫目前有一千七百多顆星、一百四十幾個 fork、十四個開放 issue，最近一次推送在 2026 年 7 月 31 日，版本號 5.2.0，不是棄坑專案。一個小陷阱是，舊的個人倉庫 xicilion/markdown-viewer-extension 已經封存，只剩一個「倉庫已搬家」的 README 指到現在的 markdown-viewer/markdown-viewer-extension 組織版本。看到兩個同名倉庫別誤會是仿冒，官方的真倉庫是組織版本；不過 VS Code Marketplace 上的條目目前仍掛著舊的 xicilion 作者名，安裝時認商店網址而不是認作者欄會比較準。

不只 Chrome，跨六個平台

把它窄化成「Chrome 擴充」會錯過它真正的定位。官方在 README 把自己描述成「統一渲染與匯出引擎」，同一套核心分別出現在 Chrome、Microsoft Edge、Mozilla Firefox、Obsidian、VS Code 與行動版的 iOS 與 Android。對已經把 Markdown 工作流散在好幾個地方的讀者，這代表你不必為了換個編輯器就重學一套匯出流程。

不同平台的功能是否完全對齊、行動版 App 的完成度到哪裡，這些官方並沒有用一張對照表說清楚，需要在各自平台的商店頁與 docs 子倉庫裡確認。如果你主力是 Obsidian 或 VS Code，值得先查一下對應版本有沒有把你要的圖表類型補齊，再決定要不要從瀏覽器版本切換過去。Obsidian 外掛與 VS Code 延伸模組的更新頻率通常會落後 Chrome 主線版本一段時間，這在跨平台開源專案裡是常態，但對需要最新功能的人是個變數。

對台灣讀者比較友善的一點是，官方 README 提供了涵蓋繁體中文在內的近三十種語言版本，擴充介面本身也宣稱支援二十八種 UI 語言。無論是查文件還是操作介面，都不必硬啃簡體中文或英文版的描述，遇到「渲染」、「匯出」這類功能名詞時，可以直接對照繁中譯法，減少誤解。這在以英文為主流的開發者工具生態裡不算常見配置，對需要長期使用這個擴充的人是實質加分。

經常交 Word 的人會用到，但要先認清的硬限制

這個擴充最明顯的受眾，是經常寫 Markdown 又得交付 Word 檔的人。把語音轉成的文字稿用 Speech-to-Markdown 整理進 Markdown、再把筆記放在 EdgeEver 這類開源筆記工具裡的寫作者，或是本機 Markdown 檔案多到要靠 Mango Finder 才找得到檔案的開發者，都會碰到同一個痛點：內容在 Markdown 裡很乾淨，交件那一刻卻得為了格式傷腦筋。Markdown Viewer 處理的正是這個環節。一個典型的應用情境是技術文件寫作者每週要把 API 文件匯成 Word 給非技術同事審閱，原本的流程是寫完 Markdown、開另一個工具把流程圖一張張匯出、再手動貼進 Word 排版，換成這個擴充之後，圖表與公式可以跟著文件主體一次出去，剩下的時間能花在內容本身。

它有幾個硬限制要先認清楚。最直接的一條是授權：你得讓它讀你所有網頁與本機檔案，這是它能在瀏覽器裡偵測並渲染 Markdown 的前提，沒有迴避的空間。程式碼授權本身也要留意，它是 GPL-3.0，想拿來做封閉商用整合會撞上 copyleft 的傳染性，對單純使用者無影響但對開發團隊是實質限制。期待面也要校準：圖表是轉成圖片嵌進 Word，不是可再編輯的向量結構，LaTeX 方程式雖然宣稱可編輯，實際品質要自己裝起來驗；隱私政策與現版程式碼不同步，想精確掌握權限得以 manifest 為準；行動版與各平台版本的功能對齊程度，需要自己在各商店與文件查證，不要假設六個平台功能一模一樣。

如果你經常交 Word 檔、又能接受把網頁閱讀權限交給一個持續更新的開源擴充，Markdown Viewer 值得一試。如果你連瀏覽器擴充要讀所有網頁都過不了信任那一關，那麼走線上轉檔服務或命令列工具，接受內容上傳或自行架設的代價，會是更舒服的選擇。認清「本機處理」指的是匯出引擎、不是擴充完全不碰網路，再決定要不要裝，會比看著行銷話術做判斷準得多。