翻译-Markdown是一场灾难：原因及替代方案

在我的商业工作中，每天都需要多次使用不同的基于 Markdown 的工具。而在个人生活中，尽管基于本文提到的论点我希望尽量减少接触，但依然避不开 Markdown 的身影。

此外，出于对个人信息管理(PIM)的兴趣，我的目标之一就是帮助人们找到适合工作的工具。当使用优秀的技术解决方案替代糟糕或平庸的方案时，我确实能获得某种个人满足感。

在使用 Markdown 相关流程长达多年之后，我深切体会到了与之相关的痛点。与大多数人不同，我实际上能识别并意识到那些被人们视为理所当然、甚至默认别无选择的细微问题。

根据我的经验，许多 Markdown 替代方案并不存在与 Markdown 相关的那些缺陷。由于大多数人没有接触过这些替代方案，网络上关于 Markdown 实用性的讨论最终演变成我试图推广替代方案，而其他人似乎认为我想剥夺他们的轻量级标记语言工作流，代之以可能更不适合的技术方案——比如文本处理、文字处理、复杂标记语言之类。

部分讨论确实发生在社交媒体平台上，由于篇幅限制和必要的精简要求，我无法完整表达和传递观点。因此我筹划这篇文章已久，以便能直接分享链接，而非在短消息平台上徒劳地阐述论点。

当所有论点都以完整篇幅呈现于此，你便能自行判断这些论点和影响是否适用于自身情况。当然，无论结果如何，你完全有权利继续偏爱 Markdown 语法。你的选择，你的数据，你的付出，你的未来。

不过你可能会发现，这里提到的某些问题同样会影响你的工作流程，渐渐地你或许会认同我的观点：Markdown 在这里根本算不上最佳选择。;-)

我的最终目标是让他人决定的 Markdown 接触量降至最低限度，这样我就能用设计更优良的语法语言来替代它。

通过使用 Markdown 语法记录信息，你实际上为这些信息的未来（重复）使用限定了形式。若这种选择对你自身数据的处理产生负面影响，你将感受到日益明显的局限性。当你的知识库中存在大量以某种 Markdown 格式编写的内容时，将其转换为更合适的格式会引发越来越多的问题——随着手动检查等环节的增加，转换工作量呈线性增长。假设转换单份文档需要十分钟，那么知识管理系统中的一千份文档将耗费你整整一个月的全职工作时间。而对于长期维护的知识管理系统而言，千份文档的规模根本算不上庞大。

如果你认同这里提到的某些问题，那么你就是在耗费自己的时间来处理变通方案、修复、不必要的转换等等。

然而，我最关键的论点并非关乎你自身和你的数据。最重要的论点是针对大多数 Markdown 用户的：那些将来会开始学习并使用轻量级标记语言的人。那些现在年纪尚幼的人，那些甚至尚未出生的人。

因此，当我提到学习 LML 语法相关的问题时，你不应该只考虑自己——毕竟你很可能已经通过适应克服了某些语法怪癖。实际上你还应该考虑所有未来需要投入学习精力的人们。所以，缺乏一致性和逻辑性正是我在此最重要的论点之一。

为确保我们理解一致：我并非要否定使用 Markdown 这类轻量级标记语言实现的优秀工作流程。我只是想指出，通过使用设计更完善的轻量级标记语言，同样可以实现这类工作流程。

遗憾的是，这里提到的一些问题看似非常细微琐碎，但其影响却不容忽视。随着轻量级标记语言日益普及并在各类工具中广泛应用，我们确实应该确保所选用的标记语言足够优秀——这无关个人好恶。

• 什么是 LMLs？
  
• 为什么 LML 是个绝妙的主意？
  
• 如何使用 LML？
  
• 为何最主流的轻量级标记语言是个反面教材
  
• 替代方案（举例说明）
  

我认为「轻量级标记」或「轻量级标记语言」这个术语并没有严格的定义。因此，我倾向于参考维基百科等常见来源。截至 2025 年 5 月 10 日，英文维基百科关于轻量级标记语言的词条这样写道：

轻量级标记语言（LML） ，亦称 简易 或 人性化标记语言 ，是一种语法简洁、无侵入性的标记语言。其设计初衷是让用户能够使用任何通用文本编辑器轻松编写，并以原始格式直接阅读。轻量级标记语言适用于需要同时阅读原始文档与最终渲染输出的应用场景。

我完全赞同这一观点。

然而，维基百科词条后续在未明确说明的情况下，又提及了 HTML 和 LaTeX。为免歧义，特此说明：根据本文定义，轻量级标记语言特指维基百科词条后文列举的语法类语言，例如 Markdown 等。

包括 AsciiDoc、atx、BBCode、Creole、Crossmark、Djot、Epytext、Haml、JsonML、MakeDoc、Markdown、Org-mode、POD（Perl）、reST（Python）、RD（Ruby）、Setext、SiSU、SPIP、Xupl、Texy!、Textile、txt2tags、UDO 和 Wikitext。

在我看来，非轻量级标记语言（LML）的语法体系：HTML、XML、(La)TeX 这类「复杂」标记语言，其输入操作远谈不上轻松简便。

此外，我想补充一个关于 Org-mode 语法特性的个人见解："Org-mode"实际上包含两个不同层面的含义：

1. 一个 Elisp 实现，用于支持文本处理，如添加新标题、折叠/展开章节等
   
2. 一种 LML 语法，由上述 Elisp 实现进行解析
   

这导致了许多讨论中的大量困扰。因此，我为 Org-mode 的语法提出了一个不同的名称。这种 LML 应被称为「Orgdown」。

我已在这篇博客文章中详细阐述了我的动机及其他内容。因此请注意，为简化和明确此处的讨论，我将使用「Orgdown」而非「Org-mode 的语法」这一术语。我强烈建议您遵循此例，以避免此类误解。

本文有时会将 Markdown 与 Orgdown 进行比较。这是因为我个人偏爱的轻量级标记语言是 Orgdown。但 您不应认为 Orgdown 是 Markdown 唯一的替代方案 。只是由于我个人主要使用这种特定语法，因此在讨论相关概念时，我会很自然地举出 Orgdown 的例子来进行说明。

即便你永远不会亲自使用 Orgdown，本文的核心理念依然成立——任何其他没有 Markdown 缺陷的轻量级标记语言都适用。

哦，没错。刚才列举了不少名字。但如果你没用过其中任何一种语言，你可能还是不明白 LML 是什么，以及它们如何为你的工作流程提供卓越服务。

别担心。我会在本文中简要说明核心理念：FIXXME: 尽快完成并链接我的文章 ;-)

The Main Characteristics of an LML

对我来说，一种轻量级标记语言最重要的特性包括：

• LML 对人类而言 易于阅读
  
• LML 对人类而言 易于掌握
  
• LML 易于人工输入 （或由工具生成）
  
• LML 对工具而言 易于处理
  

这非常重要。因此，让我们花些时间逐一解释。

在前面的章节中，我已经总结了一个设计良好的轻量级标记语言需要涵盖哪些基本特性。

我的个人经验是，Markdown 作为当下使用最广泛的轻量级标记语言，在大多数特性上都表现欠佳。

在接下来的章节中，我将解释为何会得出这个颇具争议的结论。

请务必记住：我并非要剥夺您使用轻量级标记语言的工作流程。只是认为，若您能改用比 Markdown 更优秀的轻量级标记语言，将会获得更愉悦的体验。

了解 Markdown 的早期发展历程很有帮助。

据我所知，这是最早公开提及 Markdown 的文献之一：2004 年 12 月 17 日发表在 Daring Fireball 上的一篇博客文章。

它还附带了一个语法示例文件：https://daringfireball.net/projects/markdown/syntax.text

该定义包含以下语法元素：

- 内联 HTML
  - 「对于 Markdown 语法未涵盖的任何标记，你只需直接使用 HTML 本身。」
- 段落
- 多种标题类型
  - Setext 风格的标题如下：
    1st level heading
    =================
    2nd level heading
    -----------------
  - 封闭式 Atx 风格标题（前后均带井号）
    ,# first level heading #
    ,## 2nd level heading ##
  - 开放式 ATX 风格标题（前置井号字符）
    ,# first level heading
    ,## 2nd level heading
- 引用（使用 > 字符）
- 列表（使用 *、+、-、1. 及 HTML）
- 代码块（缩进≥4 个空格或≥1 个制表符）
- 水平分割线（使用≥3 个连字符、星号或下划线）
- 网页链接
  - [an example](http://example.com/ "Title")
  - 自动链接: <http://example.com/>
- 文件链接
  - [a sub directory](/subdir/)
- 参考式链接
  [an example][myid]
  [myid]: http://example.com/  "Optional Title Here"
  - 链接 URL 可以选择性地用尖括号括起来
  - ID 不区分大小写
  - 隐性链接：
    [myid][]
- 强调（包括词内强调）
  ,*em* or ,_em_
  ,**strong** or ,__strong__
- 代码
  - 段落中的单反引号
  - 可选的多重反引号
- 图片引用
  ![Alt text](/path/to/img.jpg "Optional title")
- 使用反斜杠转义上述字面字符

就这些吧。

写邮件和简单文本文档确实够用了。这点我承认。

然而，当涉及许多其他场景时，人们需要更多语法元素。

灾难就此开始蔓延。一些在工具中采用早期 Markdown 的开发者开始 扩展语法，添加新的语法元素 。某个应用增加了脚注功能，另一个则添加了标题内部链接，还有的应用增加了更多处理源代码的选项，更有甚者添加了其他五花八门的功能。

而且没有人将这些语法扩展「合并」回原始源代码。你懂的。

这样一来，我们确实拥有了一系列所谓的 Markdown 「变体」。

Markdown Monster 工具识别出 24 种不同的 Markdown 变体。而实际存在的 Markdown 变体数量很可能远超这个数字，这丝毫不会令人惊讶。

市面上有许多工具——比如当下热门的 Obsidian——通过可选插件提供功能扩展。其中部分插件还会引入自己专用的语法元素。若想妥善复用这些元素，在格式转换时自然也需要处理这些特殊语法。遗憾的是，这些私有语法扩展确实让情况变得更加糟糕。因此，即便你使用的是人类可读的文本，使用这类插件最终仍会导致某种形式的 锁定 。可悲的是，大多数人往往要等到遭遇信息损失时，才会意识到这个问题。

以下是维基百科关于 Markdown 条目中的一段引文：

Markdown 最初的描述存在模糊之处，引发了许多悬而未决的问题，导致各种实现版本有意或无意地偏离了原始版本。这一问题在 2014 年得到解决，当时长期参与 Markdown 开发的贡献者们发布了 CommonMark——一个明确的 Markdown 规范及测试套件。

确实，曾有人尝试统一或标准化 Markdown。但由于普遍规律的存在，这反而催生了更多变体版本。

在日常工作中，诸如 MultiMarkdown、Markdown Extra、CommonMark 等 Markdown 标准规范并未发挥特别重要的作用。真正重要的是由 pandoc 或 GitHub 风味 Markdown（GFM）等工具确立的隐性标准——后者也被 GitLab 所采用。

为了让您了解 Orgdown 中那些不属于原始 Markdown 的语法元素，我从这份语法概览中摘录了部分内容：

• 上标/下标
  
• 下划线文本
  
• 斜体文本
  
• 原样文本
  
• 删除线文本
  
• 表格
  
• 复选框/内联任务
  
• 抽屉/属性中的元数据（键/值）
  
• 非代码块或行内 HTML 的其他区块：引用、诗句、示例、LaTeX 公式等…
  
• 注释（区块或行内）
  
• 标题标签
  
• 优先级标记
  
• 标题任务状态
  
• 标题引用
  
• 时间戳、日期戳
  
• 宏指令
  

要知道，其中一些功能在文本写作中远不止是锦上添花。当你将其他轻量级标记语言与原始 Markdown 定义进行比较时，很容易就能列出一份类似的清单。这绝非 Orgdown 特有的问题。

有鉴于此，我认为 Markdown 作为一种轻量级标记语言是极其糟糕的选择：

好吧，如果 Markdown 在这里也会失败，那它现在很可能就不会有这么显赫的市场地位了。

那么让我们把注意力集中在这里的其他方面。

多次讨论中我发现，长期使用 Markdown 的人往往难以理解本文的论述逻辑。究其原因，我认为是他们已无法代入 Markdown 初学者的视角。若您此刻仍感困惑，建议重读前文"人类易于掌握 LML"章节。

为优化学习效果，保持 一致性 是关键。

新用户若发现实际效果与预期不符，往往会感到沮丧。当 Markdown 语法仅由人工编写且仅供人工阅读时，这并不构成问题。真正的隐患往往在文本撰写完成很久之后才显现——当工具对 Markdown 进行解析后处理时。

初次学习某事物时，不一致性显然是个障碍。然而，不一致性还有另一个弊端：它会干扰已掌握知识的正确提取。

因此，如果某些内容存在不一致性，不仅会在你学习时带来困扰。当你试图应用已掌握的知识时，若需要记忆这些不一致的内容而非运用人类大脑与一致的 LML 设计逻辑，同样会造成挫败感。

让我们通过一些语法示例来讨论 Markdown 的不一致性。

Markdown 难以输入的原因与其难以学习的原因如出一辙。例如，我总是被 URL 语法（顺序、括号类型）搞得晕头转向。

在日常工作中，人们更倾向于使用加粗强调而非斜体。因此，所有需要加粗的内容都必须以两个星号开头，并以两个星号结尾。你可能觉得这太夸张了，但我认为如果能设计出更好的轻量级标记语言，这种重复操作本可避免。

在处理源代码示例时，Markdown 能识别 HTML 标签。此外，你可以在代码段的首尾使用三个反引号。这种方式我也能接受。但有时你需要使用第三种 Markdown 选项：每行开头≥4 个前导空格。具体是否需要采用这种方式取决于你使用的工具或 Markdown 变体。这种情况下，在每行前添加额外字符会非常繁琐。通常 Markdown 编辑器并非优秀的文本编辑器，它们不支持宏命令、列编辑或多光标功能——这些功能本可以简化此类操作。

（注：尽管我试图严格区分 LML 语法与工具支持，但必须指出，我从未见过任何 Markdown 编辑器能提供接近 GNU Emacs 为 orgdown 所提供的工具支持水平。这并非针对 Markdown 语法本身的优劣评判，但确实加剧了我使用 Markdown 工具时的挫败感。）

在许多讨论中，Markdown 广受支持的工具生态常被视为拥抱它的最强理由。而我认为，Markdown 文本无法在其他工具中被正确复用，正是反对它的最有力论据。读到这里，您或许已明白其中缘由。

Markdown 缺乏统一定义。它存在着各种方言版本，不同工具采用不同变体。正如我简单提及过的，部分工具甚至通过可选插件进一步扩展语法，可能引入额外的语法元素。否则就不会出现《10 款不影响纯文本数据的实用#Obsidian 插件》这类文章了。

这些语法元素存在严重问题，因为几乎可以确定的是，当转换为功能更强大的输出格式时，它们所包含的内容都无法得到正确处理。

总而言之，无论你在 Markdown 语法中使用了什么，在确定其能在特定情境下复用之前，你都必须仔细甄别所用的是哪个变体的哪些语法元素。对于所有非简单的文档，我都不愿做这种繁琐的工作。

像 Markdown Monster 这样的工具或许能辅助处理最基本的语法元素。但对于那些你可能知晓或根本不知晓的插件所扩展的语法，它就无能为力了。因此多数情况下，当你试图将某种不完全了解/未明确定义的 Markdown 变体转换为其他格式时，即便使用最优秀的工具支持，仍难以避免数据丢失。

根据手头的工具、信息以及用于格式化文本的语法元素， Markdown 文本可重复使用的普遍承诺只是一种幻想。

我认为这是一种 锁定效应 ，尽管文本是人类可读的并以文本文件存储——对许多人来说这似乎自相矛盾。但如果你不坚持「仅供人类阅读」的理念，这其实并不矛盾。

对此我进行了一番思考。我无法提出一个既能为整个故事增添另一种 Markdown 变体，又能制定另一种 Markdown 标准的方案。事实上，这正是某些 Markdown 变体存在的根源——总有人试图定义（唯一的）Markdown 语法规范。如果这种做法曾取得成功，我就不会撰写这篇文章了。恰恰相反，在我的个人使用场景中，那些被视为标准的 Markdown 变体，与我日常使用的工具关联甚微。

xkcd 漫画《标准》（知识共享署名-非商业性使用 2.5 许可协议；https://xkcd.com/927）

这就是为什么我认为 Markdown 已经输掉了这场战役。它就是这样了。对于那些坚持使用单一 Markdown 应用，或者至少使用一组语法基本相同的 Markdown 应用的人来说，它可能还行得通。

我并非说这不可能实现。但要说（任何）Markdown 适合作为通用轻量级标记语言的候选方案，这个论点实在站不住脚。

因此我们应该改用通用轻量级标记语言（LML），当文本在支持同种 LML 的不同工具间复用时，无需额外处理。

那么为了避免 Markdown 的缺点，有哪些优秀的轻量级标记语言（LML）候选方案值得使用呢？

好消息是，目前已有多种轻量级标记语言可供选择。其中许多都是绝佳的替代方案。让我们就此展开讨论。

在我看来，你需要一种初始形态就足够先进的轻量级标记语言，无需外部语法扩展或语法变体就能满足大多数应用场景。

那么，你需要一种 LML，即：

• 人类可轻松阅读
  
• 人类易于学习
  
• 人类易于输入
  
• 工具易于处理
  

听起来很熟悉吧？;-）

如果你知道有任何标记语言比 Markdown 更能满足这些要求，那就去用吧！你不需要我的建议。实际上你可以就此打住不必往下读了，反正这篇文章也太长了。

以下链接或许能帮助你自行判断：

• 轻量级标记语言：Markdown、reStructuredText、MediaWiki、AsciiDoc、Org-mode - Hyperpolyglot
  
  • 不知为何，作者遗漏了许多确实存在的 Orgdown 选项。我猜她/他对 Orgdown 不太熟悉，只找到了非常简单的语法概述。不过在我看来，这个表格还是挺有用的。
    
• AsciiDoc 与 Markdown 对比 | Asciidoctor 文档
  
• 通过您喜欢的搜索方式查找更多类似此网页查询的内容
  
  • 请注意：仍有部分作者未能区分语法（orgdown）与使用特定工具（如 Emacs）的必要性。
    

你可以回顾我在前文「什么是轻量级标记语言（LML）？」章节中提到的流行 LML 列表。

在本文剩余部分，我将阐述为何推荐尝试我个人偏爱的轻量级标记语言选择：Emacs Org-mode 语法——在我看来，它应该改名为 Orgdown。

当你想了解我为何为 Org-mode 语法创造新术语时，请阅读这篇文章。

是的，Orgdown 并非官方正式标准。然而，作为 Org-mode 的 Elisp 实现定义了语法元素的呈现方式和解释规则，它已然成为一种事实上的伪标准。这已远超 Markdown 所能企及的规范程度。

我已写过《Org Mode 语法是最合理的文本标记语言之一》。不过按照同样的标准来论证 Orgdown 的合理性也很公平。

哇，你竟然坚持读到了这里。这篇文章之所以这么长，是因为我试图澄清关于这个主题的所有误解、混淆和争议——毕竟我在网上经历过（太多）相关讨论了。

我已简要介绍了 LML 理念，它完全独立于任何特定的 LML 语法。

根据我的理解，我总结了 LML 应具备的通用特性。通过这种方式，您可以客观地讨论不同的实现方案。

接着我总结了 Markdown 设计上让我不满意的方面，以及需要在大脑中区分如此多不同变体的事实。

我阐述了自己对 Markdown 现状为何如此失控的看法。

最后，我建议改用另一种轻量级标记语言——一种不会带来 Markdown 所有缺陷的标记语言。

作为我个人最爱的选择，我特别强调Orgdown 即便你永远不会使用 Emacs 软件，它也是一个出色的轻量级标记语言候选方案。

根据我的个人经验，Markdown 唯一聪明之处就是它那个俏皮的名字。除此之外，几乎所有功能都能被其他轻量级标记语言实现得更好。

以我的经验来看，这个话题对许多人来说非常敏感。这导致争论往往超出我在此试图总结的客观理性范畴，演变成带有个人偏好的信仰之争。

然而，通过以上论述，你应该能够 自行判断 我的观点是否具有一定道理——我对于 Markdown 的个人困扰是否也映射在你的实际使用场景中，或者所列的所有 Markdown 缺陷对你以及所有与你共享文本文档的同事而言根本不成问题。

如果此刻我仍未能说服你，至少我们还有双方都能选择的其他方案。

若我遗漏了有力论据，请不吝在下方留言评论。

• 支持 Markdown
  
  • Markdown 与格式迷恋的缓慢消逝 + 我对此的评论
    
• 反对 Markdown
  
  • 为什么你不该用 Markdown 编写文档 —— Eric Holscher