若要在 Markdown 表格的單一儲存格中顯示多行,請讓該列保持在同一行原始碼中,並在各片語之間插入 <br>。這種做法適用於支援表格和內嵌 HTML 的地方;使用前請先確認 Obsidian 和目的地的渲染器支援此功能。
本指南介紹一項實用的 Mac 桌面操作:在 Obsidian 中撰寫小型表格、檢查顯示效果,並準備相同的 Markdown 供 GitHub 或其他渲染器使用。範例採用虛構的文具描述。以下相容性檢查流程是根據文件整理而成,並非在已安裝的應用程式中實測的結果。
哪些 Markdown 渲染器支援多行表格儲存格?
管線表格是擴充語法,不屬於核心 CommonMark。GitHub Flavored Markdown(簡稱 GFM)新增了可接受內嵌內容的表格。其規格不允許在這些儲存格中使用區塊元素。因此,儲存格中包含多行顯示內容,與儲存格中包含多個獨立段落、Markdown 清單或圍欄式程式碼區塊並不相同。請參閱 GFM 表格規格。
Obsidian 說明了管線表格以及儲存格內的格式設定。其基本語法文件也指出 <br> 是換行標籤。這些文件共同構成本指南做法的依據,但表格頁面並未提供專門的多行儲存格範例。請參閱 進階格式語法 和 基本格式語法。
編輯大型文件前,請先參考這份判斷表:
| 目的地 | 文件說明的限制 | 實用做法 |
|---|---|---|
| 未使用擴充功能的核心 CommonMark | 管線表格不屬於核心語法 | 使用標題和清單 |
| 相容 GFM 的渲染器 | 表格接受內嵌內容,但儲存格內不能使用區塊元素 | 嘗試使用內嵌換行,並檢查目的地的顯示效果 |
| Obsidian | 文件說明了表格和換行標籤 | 編輯原始碼,再檢查閱讀檢視 |
| HTML 處理方式未知的渲染器 | 尚未確認其支援情況 | 先執行下方的小型比較,再決定格式 |
前三列依據上方連結的 CommonMark 規格、GFM 規格 和 Obsidian 文件。最後一列是建議的驗證步驟:光看渲染器名稱,無法確定它會如何處理你的文件。
如何在單一儲存格中寫入兩行?
將以下範例貼到筆記中,不要複製外面的程式碼圍欄。每個表格列都佔用一行實際原始碼;第二個儲存格中的兩個片語之間放置了換行標記。
| Item | Details |
| --- | --- |
| Notebook | Dotted pages<br>Blue cover |
| Pencil | Graphite core<br>Hexagonal shape |
預期結果是包含兩個資料列的兩欄表格。第一個詳細資料儲存格中,「點點頁面」會顯示在「藍色封面」上方。第二個儲存格中,「石墨筆芯」會顯示在「六角形筆身」上方。這是預期的渲染結果,應在你的目的地確認,而非內嵌展示目的地的實際行為。
此方法結合了內嵌 HTML 換行標籤與表格語法。GitHub 在其支援的換行方式中列出 HTML 換行標籤,Obsidian 則明確說明了 <br>。這些是使用 HTML 輔助的 Markdown 儲存格,因此可攜性取決於目的地是否接受該標記。請參閱 GitHub 的換行說明 和 Obsidian 的基本語法文件。
保持表格結構簡單:表格前留一個空行、標題列和分隔列的欄數一致,且每個分隔儲存格使用三個連字號。GitHub 的表格指南說明了空行和三個連字號的慣例。Obsidian 至少接受兩個連字號,因此三個是兩者都適用的選擇。來源:使用表格整理資訊 和 進階格式語法。
為什麼按 Enter、加兩個空格或反斜線都無法解決?
CommonMark 支援在行尾加兩個空格,或在原始碼換行前加反斜線,以建立強制換行。這些規則適用於既有區塊中的內嵌內容,並未定義多行管線表格儲存格。請參閱 CommonMark 的強制換行。
例如,以下寫法刻意示範了不適合將兩個片語保留在同一個 GFM 儲存格中的方式:
| Item | Details |
| --- | --- |
| Notebook | Dotted pages
Blue cover |
根據 GFM 的表格規則,第二行原始碼會成為另一列,而非詳細資料儲存格的延續內容。空行則會結束表格。請將完整表格列放在一起,並在顯示內容需要換行的位置放置內嵌換行標記。請參閱 GFM 表格範例。
也要區分自動換行與刻意換行。就此任務而言,即使視窗夠寬,能容納兩個片語,成功的結果仍應讓第二個片語從新的一行開始。只用窄視窗的螢幕截圖無法證明這點。
如何在 Mac 上用 Obsidian 檢查表格?
建立一個只包含範例表格的暫存筆記。這樣更容易判斷問題來自表格本身,還是周圍的內容。
- 使用編輯模式狀態控制項,將筆記切換至
Source mode。此模式會顯示實際撰寫的 Markdown 原始碼。 - 貼上範例,確認每個資料列都維持在同一行原始碼中。
- 按下
Cmd+E,在編輯模式與Reading view之間切換。 - 檢查兩個詳細資料儲存格:每個都應顯示兩行,且片語都不應移到新的表格列中。
- 返回編輯模式,再用
Live Preview比對結果。
Obsidian 在 檢視和編輯模式 中說明了 Source mode、Live Preview 和 Mac 快速鍵。編輯時,Live Preview 會隱藏大部分語法;Reading view 則可用來單獨檢查格式化後的筆記。
若要並排比較,按住 Cmd 並點擊檢視切換器,即可同時開啟編輯檢視和閱讀檢視。如果找不到該控制項,Obsidian 說明了可透過 Settings → Appearance → Show tab title bar 顯示標籤列,也可使用狀態列控制項:Settings → Editor → Show editing mode in status bar。請參閱 檢視和編輯模式。
Obsidian 的基本語法指南介紹了用於段落換行的 Shift+Enter 快速鍵,以及 Strict Line Breaks 設定。這些一般段落說明並不能證明存在可跨平台使用的表格儲存格快速鍵。進行這項檢查時,請在 Source mode 中檢查已儲存的表格列,並使用明確的換行標記,不要把該設定當成表格相容性修正方式。請參閱 基本格式語法。
如何快速診斷渲染器差異?
在候選的多行版本旁加入純文字對照組。以下完整測試文件只變更換行標記,因此更容易分辨問題出在表格支援還是內嵌 HTML 支援:
Control:
| Item | Details |
| --- | --- |
| Notebook | Dotted pages; blue cover |
Multiline candidate:
| Item | Details |
| --- | --- |
| Notebook | Dotted pages<br>Blue cover |
在每個預定使用的目的地開啟相同內容。若是 GitHub Markdown 檔案,請檢查該檔案的渲染畫面;Obsidian 預覽只能確認 Obsidian 的結果。GitHub 也說明了 Markdown 檔案與對話欄位對一般段落換行的處理方式不同,這更加凸顯檢查實際目的地的重要性。請參閱 基本寫作與格式設定語法。
根據以下觀察結果,判斷接下來要檢查什麼:
| 觀察結果 | 下一步檢查 |
|---|---|
| 兩個範例都顯示為以直線符號分隔的文字 | 確認是否支援表格,並檢查內容是否位於程式碼圍欄之外 |
| 對照組正常,但候選範例會顯示標籤文字 | 檢查標籤是否放在反引號內,或是否已逸出 |
| 對照組正常,但候選範例的換行消失 | 查閱目的地的內嵌 HTML 文件 |
| 候選範例產生了額外的列 | 檢查原始碼中預定表格列內是否有實際換行 |
| 片語消失或移到其他欄 | 檢查儲存格內容是否包含未逸出的直線符號 |
這些是診斷方向,無法完整解釋每種渲染器的行為。先修正最小範例,再逐步加回表格其餘內容。若儲存格文字中要表示直線符號,GitHub 文件說明可用反斜線逸出,例如 Dotted \| plain。請參閱 在表格中格式化內容。
不支援多行儲存格時該用什麼格式?
如果目的地接受表格但不接受內嵌 HTML,請將詳細資料各自放在一列。重複項目名稱即可保留關聯,無須在儲存格內換行:
| Item | Detail |
| --- | --- |
| Notebook | Dotted pages |
| Notebook | Blue cover |
如果目的地只支援核心 CommonMark,請將詳細資料移到標題和清單中:
### Notebook
- Dotted pages
- Blue cover
標題和清單屬於 CommonMark 語法。此替代方式也能容納較長的項目,無須依賴表格擴充功能。
多行程式碼應放在表格外的圍欄式程式碼區塊中。將多行原始碼包在單一行內程式碼區段中,並不會保留換行:CommonMark 會將程式碼區段中的換行正規化為空格。請參閱 程式碼區段。
請依照需要保留的內容選擇格式。若是兩個簡短片語,內嵌換行是值得驗證的實用選擇。若是獨立段落、較長的清單或多行程式碼,請將詳細內容移出儲存格。將這個小型相容性範例保留在工作筆記中,以便在目的地變更時重複檢查。
來源
- CommonMark 規格,0.31.2 版 — CommonMark
- GitHub Flavored Markdown 規格 — GitHub
- 使用表格整理資訊 — GitHub 文件
- 基本寫作與格式設定語法 — GitHub 文件
- 進階格式語法 — Obsidian 說明
- 基本格式語法 — Obsidian 說明
- 檢視和編輯模式 — Obsidian 說明