預覽窗格說的是 GitHub 風格 Markdown，一般簡稱 GFM。拆開來看，它等於 CommonMark 規格（也就是被標準化的 Markdown 核心），再加上 GitHub 為開發寫作補的那組擴充：直線式表格、核取方塊待辦清單、雙波浪號刪除線，以及不加任何語法就會變成連結的裸網址。渲染由開啟 GFM 選項的 marked.js 完成。
知道自己在寫哪一種方言很重要，因為有幾個熱門擴充並不在其中。註腳、定義清單和 YAML front matter 都不屬於 GFM，在這裡不會渲染，在 GitHub 上同樣不會，即使 Obsidian 和 Pandoc 支援得很好。要寫 README、issue 或靜態網站部落格嗎？GFM 就是你要的目標，GFM 指南逐項說明每一個擴充。
有三件事是在單純的 GFM 之外另外做的：標了語言代碼的程式碼圍欄會用 highlight.js 上色、$數學式$ 會由 KaTeX 排版、標成 mermaid 的圍欄會畫成圖表。這三項 GitHub 也都支援，所以預覽仍然是 README 的合理彩排。
重點速覽
| 基礎規格 | CommonMark，並由 GFM 擴充 |
|---|---|
| 解析器 | marked.js，在你的瀏覽器裡執行 |
| 支援的擴充 | 表格、待辦清單、刪除線、自動連結 |
| GFM 之外另外支援 | 程式碼上色、KaTeX 數學式、Mermaid 圖表 |
| 不支援 | 註腳、定義清單、YAML front matter |
| 與 GitHub 一致嗎 | 結構一致，視覺樣式由目的地決定 |
Markdown 為什麼會有「方言」？
- GFM 就是 CommonMark 加上表格、待辦清單、刪除線與自動連結。
- 預覽呈現的結構，就是 GitHub 會產生的結構，差別只在視覺樣式。
- 刪除線和自動連結在每個平台都安全，表格和核取方塊則不是。
- 註腳和定義清單要換工具，例如 Obsidian 或 Pandoc。
- 數學式不在 GFM 裡，但本站預覽會用 KaTeX 幫你排出來。
- 單一換行會被當成空格，跟 GitHub 處理
.md檔的方式一致。
2004 年的規格刻意精簡，某些地方甚至語焉不詳。它沒有表格、沒有待辦清單，邊界情況也沒有定義。兩個解析器可以「都沒錯」，卻對同一份文件有幾層巢狀清單各說各話。
於是各平台把自家使用者需要的東西補了進去。GitHub 為了 issue 和技術文件加了表格與待辦清單，其他工具加了註腳、螢光標記或維基式連結。每一套擴充就成了一種方言。
小提醒：後來 CommonMark 用一份精確的規格書和測試集，把那個模糊的核心釘死了。GFM 現在的正式定義就是 CommonMark 加上一小組有文件可查的擴充，所以「GitHub 風格」指的是真正的標準，不是某家公司的習慣寫法。
GFM 多了什麼？一個範例看完
原始語法的一切都還能用：標題、強調、清單、連結、圖片、引用、程式碼。GFM 最重要的四項新增功能，下面這段全用上了：
| 功能 | 原始 MD | GFM |
| -------- | :-----: | :-: |
| 表格 | 無 | 有 |
| 待辦清單 | 無 | 有 |
- [x] 完成報告草稿
- [ ] ~~寄出郵件版~~ 改成分享連結
https://mdeditor.tw 會自動變成連結
這段裡每一行做的事都不一樣，值得逐項對照著看。
這四個擴充各自在做什麼
- 表格。那一行連字號是分隔列，用來告訴解析器上面那一行是表頭，其中的冒號則決定對齊方式。
- 待辦清單。
- [x]和- [ ]會變成已勾選與未勾選的核取方塊，這正是 GitHub issue 呈現檢查清單的方式。 - 刪除線。雙波浪號把一段文字劃掉但保留下來，很適合展示改變過的決策。
- 自動連結。裸網址不需要任何方括號語法就會變成可點擊的連結。
哪些擴充在哪裡活得下來？
目前的支援狀況
可攜性正是在擴充功能上破功的，所以動筆之前先確認目的地很值得。以下是大家最常貼上去的幾個平台：
| 平台 | 表格 | 待辦清單 | 刪除線 | 自動連結 | 註腳 |
|---|---|---|---|---|---|
| GitHub | 支援 | 支援 | 支援 | 支援 | 支援 |
| GitLab | 支援 | 支援 | 支援 | 支援 | 支援 |
| 支援 | 不支援 | 支援 | 支援 | 不支援 | |
| Discord | 不支援 | 不支援 | 支援 | 支援 | 不支援 |
| Notion | 部分 | 支援 | 支援 | 支援 | 不支援 |
| Obsidian | 支援 | 支援 | 支援 | 支援 | 支援 |
| VS Code 預覽 | 支援 | 支援 | 支援 | 支援 | 不支援 |
| MD Editor | 支援 | 支援 | 支援 | 支援 | 不支援 |
從表裡帶走兩件事
- 刪除線和自動連結幾乎全平台通用。可以不假思索地用。
- 表格和待辦清單是開發者平台的功能。在聊天軟體並不可靠，所以要送到 Discord 或 Slack 之前，先把表格改寫成簡短的條列。
如果你的目的地是聊天軟體，平台指南會先告訴你各家吃得下什麼，再按送出。
背後的引擎：在瀏覽器裡跑的 marked.js
解析發生在你的分頁裡
編輯器使用 marked.js 渲染，這是一套快速、廣泛採用的 JavaScript 解析器，並開啟了 GFM 選項。它完全在你的瀏覽器裡執行，所以預覽才能逐鍵反應、不必來回伺服器，也是頁面載入後一切都能離線運作的原因。產生的 HTML 送進預覽窗格之前還會經過 DOMPurify，所以就算貼進夾帶惡意 script 標籤的文件，也只會顯示成無害的文字。
最常讓人意外的換行規則
換行採用 GitHub 的慣例：段落內的單一換行算一個空格，不是強制斷行。這跟 GitHub 渲染 .md 檔案的行為一致，但跟它的留言框不同，留言框裡單一換行是會斷行的。需要硬斷行嗎？在行尾打兩個空格，或直接寫 <br>。
跟 GitHub 到底有多像
預覽呈現的內容，就是 GitHub 會替你的 README 呈現的內容，只有一個前提要記得：最終的視覺樣式永遠來自目的地網站的 CSS，字型、間距、顏色都是它們的。一致的是結構，也就是什麼會變成表格、核取方塊或標題。
最常害人踩雷的 GFM 語法錯誤
每一項 GFM 擴充都有一條大家常忘記的嚴格規則。下面這段一次犯滿四個：
團隊名單：
| 姓名 | 角色 |
| Ana | 編輯 |
- [x]發佈 beta 版
- [ ]撰寫更新說明
這個計畫暫時~取消~了。
這四種寫法沒有一個會照你預期的樣子渲染出來。
各自錯在哪裡
- 表格少了分隔列，所以整段維持純文字，直線符號直接露出來。
- 表格黏在上一段下面。表格區塊前面需要一行空行。
- 核取方塊少了空格。右方括號後面要有一個空格，否則解析器只看到普通清單項目。
- 刪除線只用了一個波浪號。GFM 需要兩個。
修正後的版本
團隊名單：
| 姓名 | 角色 |
| ---- | ---- |
| Ana | 編輯 |
- [x] 發佈 beta 版
- [ ] 撰寫更新說明
這個計畫暫時~~取消~~了。
分隔列每一欄至少要三個連字號。在裡面加冒號就能設定對齊：:--- 靠左、:---: 置中、---: 靠右。原始碼裡的欄寬不必對齊，解析器會忽略多餘空格，排整齊只是為了讓原始檔好讀。
小提醒：這四種錯誤在預覽裡一兩秒內就會現形，所以邊打邊看那一格。如果你常做表格，表格產生器會直接幫你把分隔列寫好。
目的地不是 GitHub 時的邊界情況
當目的地有自己的額外語法
核心語法走到哪裡都通，擴充功能則在邊緣地帶各有差異，上面那張表已經說明了。有些文件系統多了 GFM 沒有的功能，像註腳、維基式連結或提示框，這些區塊在本編輯器裡不會預覽。它們在支援的系統上照樣正常發佈，你失去的只是那幾行的即時預覽。數學式是個例外：GFM 從未定義它，本站預覽仍然會幫你排版。
一個安全的預設
最需要可攜性時，只用共通核心，也就是語法速查表裡的全部內容。要發佈大量使用擴充語法的內容之前，先用目的地平台自己的預覽檢查一次。其餘情況下，GFM 仍是最好的預設：它是在最多地方都能正確渲染的最大語法集合。還在建立基本概念嗎？建議先看什麼是 Markdown。
相關問題
立即使用編輯器
開啟編輯器