為什麼術語很重要
- 多數 Markdown 的困惑其實是名詞的困惑，不是語法的困惑。
- 大家嘴上說「Markdown」，心裡指的往往是某一種方言，所以在 GitHub 正確的建議，到聊天框裡就變成錯的。
- 下面三十個名詞，每個都用一到兩句話定義，可以直接引用。
- 方言、渲染器和 CommonMark 這三個字，惹的麻煩比其他全部加起來還多。
Markdown 看起來很單純，直到兩個人用不同的詞描述同一個問題。一個說渲染器壞了，一個說這個方言不支援，第三個說檔案不過是純文字，根本沒有東西會壞。三個人可以同時都對，這正是名詞重要的原因。
說「Markdown」，心裡想的卻是某一種方言
多數永遠得不到好答案的問題，背後都是同一個模式。有人說「Markdown」，指的其實是自己 App 剛好在用的那種方言。接著他照著為另一種方言寫的建議去做，語法就悄悄失效了。語法從頭到尾都沒錯，錯的是目的地。
把零件叫得出名字，你才問得出有答案的問題。「這個渲染器支援註腳嗎？」幾秒鐘就能解決；「為什麼我的 Markdown 壞掉了？」不會。如果這個格式對你還很新，請先看白話版入門，再回來看這一頁。
用對詞可以省下什麼
- 搜尋更準。搜「圍欄式程式碼區塊」找得到答案，搜「那個三個點點的東西」找不到。
- 求助更快。講清楚剖析器和方言的問題回報會被修好；只說「看起來怪怪的」，得到的只會是一句反問。
- 少走冤枉路。知道表格是擴充語法、不是核心語法，就能理解為什麼表格語法在這個 App 好好的，換一個就掛掉。
小提醒：讀完一個定義，就到免費編輯器把它描述的東西打一次，看著預覽變化。用過一次的名詞才記得住，只讀過的不會。
最容易出事的三個字
大部分的混亂都由三個名詞造成。它們在論壇回答、部落格文章甚至官方文件裡都被用得很鬆，一旦搞混，人就會跑到錯的地方找問題。
方言：你到底在為哪一套規則寫字
方言（dialect）是某一套特定的 Markdown 規則。GitHub 風格 Markdown 是一種方言，MultiMarkdown、Markdown Extra，還有 Discord 用的那一小撮子集也都是。它們對核心的看法一致：標題、粗體、清單、連結。核心以上就各說各話。
陷阱在這裡。有人問「Markdown 支援刪除線嗎？」這樣問其實沒有答案。刪除線是 GFM 的功能，真正該問的是目的地跑的是哪一種方言。該寫哪一種 Markdown 方言說明怎麼在一分鐘內判斷出來。
渲染器：決定你看到什麼的那個軟體
渲染器負責把剖析後的 Markdown 變成你眼前的頁面。兩個網站就算支援一模一樣的語法，長相也可能天差地遠，因為每個渲染器都帶著自己的樣式、自己的擴充功能和自己的安全過濾器。
所以「在 GitHub 上可以」是關於 GitHub 的事實，不是對其他地方的保證。GitHub 跑的是自家渲染器和自家規則，GitHub 風格 Markdown 那一頁講得很完整。同一段文字貼到別處的留言框，換一個渲染器就換一種說法，平台比較整理了差距有多大。
CommonMark：那是規格，不是一個 App
CommonMark 常被稱作一種方言。這樣講很接近，但有點偏。它是一份規格：精確、附上大量測試，明確定義每條規則該怎麼剖析，2014 年發布，為的是終結各家實作之間多年的模稜兩可。
沒有人像用 Notion 那樣「使用 CommonMark」。大家真正的意思是：我用的剖析器遵循它。這件事之所以重要，是因為現在幾乎所有新東西都站在 CommonMark 這塊地板上，GFM 也不例外。它把巢狀強調、落單星號這些尷尬情況都講死了，再把表格、註腳和待辦清單留給上層的方言處理。
這份術語表要怎麼搭配其他頁面用
術語表只回答一個問題：這個詞是什麼意思。它刻意不是學語法的地方，因為定義和教學想從你身上拿走的注意力不一樣。各頁的分工如下。
- 卡在某個名詞時，從這裡開始。別人講了「分隔列」或「前置資料」，你後半句就跟不上了。
- 需要全貌，去語法參考。它列出每一個元素，並指向真正深入說明的那一頁。
- 要真的學會，讀完整指南。照順序講完每個元素，附範例和大家真的會犯的錯。
- 動手寫的時候，把速查表開著。一頁、所有常用符號，不用捲過一堆說明。
有專屬頁面的名詞
下面有些條目附了連結，因為一段話真的裝不下。圍欄和語法高亮在程式碼區塊講得最完整；連結語法（包含參考式寫法）在連結那一頁；標記和它對應的說明文字則在註腳。定義告訴你那是什麼，那些頁面告訴你怎麼用。
同一個詞，各家 App 的行為不同
名詞是共用的，支援度不是
幾乎每個 App 都借用了 GitHub 的講法。待辦清單、刪除線、管線表格、程式碼圍欄，在 Notion、Obsidian、Reddit 和 Discord 裡指的都是同一件事。會變的是這個 App 到底理不理它。尤其是聊天軟體，只支援一小部分，其餘一聲不吭地忽略。
注意：不支援的元素通常不會跳錯誤訊息，它只會把你打的符號原樣顯示出來，或者什麼都不顯示。看到東西以文字原樣出現時，先假設是不支援，再去找有沒有打錯字。
兩組最常被搞反的詞
- 剖析器與渲染器。剖析器讀你的文字、判斷出結構；渲染器決定這個結構長什麼樣子。表格根本沒出現，通常是剖析器的極限；間距很醜，通常是渲染器的事。
- 檔案與格式。
.md檔就是貼了一張標籤的純文字，這點副檔名說明講得很清楚。把它改名成 .txt，唯一改變的是哪些軟體會主動提供預覽。
這也是這份術語表把定義寫得又短又和支援度表格分開的原因。一個詞就是一個意思；你的 App 認不認帳是另一個問題，那個問題請到平台總覽找答案。
全部術語與定義
- 錨點（slug）
- 錨點是渲染器從標題自動建立的連結目標，slug 則是它拿來當 id 的那段小寫短代稱。GitHub 會把標題 Getting Started 變成 getting-started，所以網址結尾加上 #getting-started 就能直接跳到那一段。 閱讀完整解答 →
- ATX 標題
- ATX 標題是在行首用一到六個井字號寫成的標題，例如 ## 設定。這是標準的標題寫法，每一種 Markdown 方言都支援。 閱讀完整解答 →
- 引用區塊
- 引用區塊是每一行開頭加上大於符號所標示的引文段落。渲染後通常會往內縮排，左側再加上一條有顏色的直線。 閱讀完整解答 →
- CommonMark
- CommonMark 是 2014 年發布的嚴謹 Markdown 規格，明確定義每一條規則該怎麼剖析。現在多數方言，包括 GitHub 風格 Markdown，都建立在這個共同基礎之上。 閱讀完整解答 →
- 分隔列
- 分隔列是表頭底下那一行由連字號和直線組成的文字，剖析器就是靠它認出這個區塊是表格。在某一段的一端或兩端加上冒號，就能把該欄設成靠左、靠右或置中。 閱讀完整解答 →
- 跳脫
- 跳脫是在符號前面加一個反斜線，讓 Markdown 直接印出這個符號，而不是把它當成格式語法。想在文章裡顯示星號、井字號或底線本身時就用它。 閱讀完整解答 →
- 圍欄式程式碼區塊
- 圍欄式程式碼區塊是上下各用一行三個反引號包起來的程式碼區塊。兩道圍欄之間的內容會照你打的原樣顯示，開頭圍欄後面再加上語言名稱，就會開啟語法高亮。 閱讀完整解答 →
- 註腳
- 註腳是文中的小標記，點下去會跳到頁面底部集中放置的說明文字。它屬於擴充語法，所以 GitHub 和 Obsidian 支援，但不是每個 Markdown 工具都吃。 閱讀完整解答 →
- 前置資料（YAML front matter）
- 前置資料是放在 Markdown 檔案最開頭的中繼資料區塊，上下各用三個連字號框起來。裡面通常是 title、date、tags 這類 YAML 欄位，由發佈工具讀取，不會印在文章裡。 閱讀完整解答 →
- GitHub 風格 Markdown（GFM）
- GitHub 風格 Markdown（常簡稱 GFM）是 GitHub 自己的 Markdown 版本。它在 CommonMark 的基礎上加了表格、待辦清單、刪除線和自動連結，也是其他工具最常模仿的方言。 閱讀完整解答 →
- 強制換行
- 強制換行是在同一個段落裡硬換到下一行。做法是行尾留兩個空白，或在多數新版剖析器裡用一個反斜線，因為只按一次 Enter 會被忽略。 閱讀完整解答 →
- 行內程式碼
- 行內程式碼是夾在單個反引號之間、寫在一般句子裡的短程式碼。它會以等寬字型顯示，而且裡面的 Markdown 語法一律不生效。 閱讀完整解答 →
- 內嵌 HTML
- 內嵌 HTML 是直接寫在 Markdown 檔案裡的原始 HTML。許多剖析器會原封不動放行，這也是補足 Markdown 沒有語法的排版的方法，但比較嚴格的網站會基於安全把它移除。 閱讀完整解答 →
- 鬆散清單與緊密清單
- 項目之間沒有空行的是緊密清單，只要出現一行空行就變成鬆散清單。差別看得出來：渲染器會把鬆散清單的每個項目包成段落，間距因此變大。 閱讀完整解答 →
- Markdown 方言
- 方言（flavor）是某一套特定的 Markdown 規則，例如 GitHub 風格 Markdown 或 MultiMarkdown。各方言的核心語法一致，差別在表格、註腳、待辦清單這些額外功能。 閱讀完整解答 →
- .md 副檔名
- .md 副檔名代表這是一個內容以 Markdown 撰寫的純文字檔。比較長的 .markdown 意思完全相同，而且兩者都不會改變檔案本身，副檔名只是告訴軟體該怎麼處理它。 閱讀完整解答 →
- Mermaid
- Mermaid 是一種用文字描述圖表的語法，部分網站會把標記為 mermaid 的程式碼區塊渲染成圖。GitHub、GitLab、Notion、Obsidian 和本站編輯器都支援，一般的 Markdown 剖析器則只會顯示原始碼。 閱讀完整解答 →
- Pandoc
- Pandoc 是免費的命令列工具，能在各種文件格式之間轉換，包括把 Markdown 轉成 Word、LaTeX、EPUB 和 PDF。瀏覽器工具做不到的事，通常就是交給它處理。
- 剖析器
- 剖析器是程式裡負責讀取 Markdown 文字、判斷每個符號代表什麼意思的部分。它會整理出標題、清單和段落的結構，再交由渲染器轉成 HTML。 閱讀完整解答 →
- 管線表格
- 管線表格就是標準的 Markdown 表格，用直線符號分隔儲存格，並在表頭下方放一列分隔列。表格屬於擴充語法而非核心語法，所以少數嚴格的剖析器會直接忽略它。 閱讀完整解答 →
- 純文字
- 純文字是只儲存字元、不夾帶任何隱藏格式資料的文字。Markdown 檔案就是純文字，所以任何編輯器都打得開，也很適合做版本控管。 閱讀完整解答 →
- 參考式連結
- 參考式連結把網址集中放在文件底部，句子裡只留一個簡短的標籤。這樣長網址就不會把段落切得零零落落，同一個定義還能被多個連結重複使用。 閱讀完整解答 →
- 渲染器
- 渲染器是把剖析後的 Markdown 變成你最後看到的畫面（通常是網頁 HTML）的軟體。兩個網站就算支援一模一樣的語法，長相也可能差很多，因為各自套用的樣式和規則不同。 閱讀完整解答 →
- HTML 淨化器
- 淨化器是在 Markdown 發佈之前，把不安全的 HTML（例如 script 標籤）過濾掉的機制。這就是為什麼在你自己電腦上有效的原始 HTML，貼到公開網站後會悄悄不見。 閱讀完整解答 →
- Setext 標題
- Setext 標題是比較舊的標題寫法，在文字下一行畫等號代表第一階，畫連字號代表第二階。它只有這兩階，所以現在大家多半改用井字號標題。 閱讀完整解答 →
- 靜態網站產生器
- 靜態網站產生器是把一整個資料夾的 Markdown 檔案，轉成一個由純 HTML 頁面組成的網站的工具。常見的有 Hugo、Jekyll、Eleventy 和 Astro。
- 刪除線
- 刪除線是中間畫一條線的文字，前後各用兩個波浪號寫成。它來自 GitHub 風格 Markdown，所以 GitHub、Reddit 和 Discord 都能用，最原始的規格則沒有。 閱讀完整解答 →
- 語法高亮
- 語法高亮是依照程式語言替程式碼上色，讓關鍵字、字串和註解一眼就能分辨。在圍欄式程式碼區塊開頭的反引號後面直接寫上語言名稱，就會啟用。 閱讀完整解答 →
- 待辦清單
- 待辦清單是每個項目開頭加上一組方括號的清單，括號留空或填一個 x，渲染後會變成核取方塊。它是 GitHub 風格 Markdown 的功能，也被大量筆記軟體沿用。 閱讀完整解答 →
- 所見即所得（WYSIWYG）
- WYSIWYG 是 what you see is what you get 的縮寫，指打字當下就看得到排版效果的編輯器。Markdown 刻意反其道而行：你打的是純文字符號，排版結果要等渲染之後才出現。 閱讀完整解答 →
常見問題
什麼是圍欄式程式碼區塊？
圍欄式程式碼區塊是上一行三個反引號、下一行三個反引號夾起來的程式碼。兩道圍欄之間的內容會照你打的原樣顯示，不會套用粗體、斜體或連結。在開頭圍欄後面加上語言名稱（例如 python），多數渲染器就會自動替程式碼上色。圍欄、縮排式區塊和語法高亮的完整說明在程式碼區塊那一頁。
CommonMark 是什麼意思？
CommonMark 是一份規格，不是 App，也不是產品。它在 2014 年發布，用數百個測試明確定義每條 Markdown 規則該怎麼剖析，因為 2004 年最初的說明留下太多可以各自解讀的空間。有人說某個工具「符合 CommonMark」，意思是它的剖析器遵循這份規格。現在多數方言，包括 GitHub 的版本，都建立在它之上。
Markdown 方言和渲染器是同一件事嗎？
不是，而且這是這個題目裡最常見的誤會。方言是一套規則，例如 GitHub 風格 Markdown；渲染器是套用這些規則、把結果畫到畫面上的軟體。同一種方言可以有很多個渲染器實作，所以兩個網站可能都支援同樣的語法，畫面卻長得不一樣。GFM 那一頁兩邊都有談到。
延伸閱讀
立即使用編輯器
開啟編輯器