A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. — John Gruber
当我们在谈论 Markdown 的时候，我们到底在谈论什么？是 CommonMark 还是 GitHub Flavored Markdown，抑或是最初发明时的那个 Markdown？
当我第一次知道 Markdown 的时候，我的内心是欣喜的，心想这个世界除了复杂的 HTML 标签以外居然还有如此简单的标记。但当我知道它有好几种风格的时候，我的内心是拒绝的，因为我不知道应该遵循哪一种写法，不知道我写的 Markdown 是否能适用于其他场景。这种不确定性造成的纠结和担忧一度使我不想使用 Markdown，但如此简洁的设计又让人欲罢不能。现在又正式将博客换成了 Hexo，于是便义无反顾的跳入这个坑了。既然这样，那就好好考虑考虑以下几个问题。
目前最流行的要属 Github Flavored Markdown 和 CommonMark 这两种了。前者不用说，Github 官网用的就是，许多主流编辑器支持。后者则最接近原始 Markdown，虽然名字听起来像个标准，目的也是为了给混乱的 Markdown 界树立一个通用的标准，但事实上它并非标准，而且我认为，Markdown 的属性决定了它可以甚至应该不遵从一个统一的标准。
在详细了解了各种 Markdown 的区别后，我发现，基本的语法其实是一样的，罗列一下，都用到了下面这些符号：
至于有序列表项目的“1.”“2.”这些就不算进去了吧，这就是全世界通用的正常语言啊。就算把另外一种表示方法，比如一级标题的“=”、强调或加粗文本的“_”算进去，那也是十个指头就数得过来的，而且这些符号的使用方法在各种 Markdown 中也是一样的。所以你说 Markdown 简单吗？比起 HTML N 多个标记来说简单爆了！
那么各种 Markdown 的区别其实在于是否拥有更高级的功能，比如 Github Flavored Markdown 就比 CommonMark 多了表格功能，甚至更有丧心病狂者还能用 Markdown 来画流程图。如果没有特殊需求，CommonMark 当是第一选择，几乎所有的编辑器和转换器都能正确识别。如果喜欢用表格，那 Github Flavored Markdown 可能是更好的选择。
我的最终选择是 Github Flavored Markdown，但并非表格的关系。选它一是因为 Hexo 支持，二是因为它支持直接换行，也就是换行就是换行，而不是两行拼接再加空格这种对于中文来说然并卵的模式。
子曰：“工欲善其事，必先利其器。”
只怪孔子这话说得太有道理，无数人在找寻称手工具上花费了无数的时间，我也是这其中这一。过程十分艰辛。
在我看来，一个好的 Markdown 编辑器需要具备如下素质：
我觉得我的要求很简单啊，但光前两点就 pass 了一票编辑器。为什么不用在线编辑器？因为打开和保存文件麻烦。有些在线编辑器不是有桌面版吗？但它们只是网络应用的打包，不仅运行起来慢，还占内存。那还是有很多好用的编辑器啊？哦，对了，还有一个条件刚才没写，要支持 GNU/Linux 平台。这一刀下来，最终只剩下 4 个比较好的选择。
Marketo 是一个 KDE 笔记程序，用 Markdown 来记笔记，也带有一个独立的 Markdown 编辑器。编辑器直接使用 katepart，所以带有 vim 模式。部分支持 CommonMark，双面板实时预览、代码语法高亮、支持 MathJax。去年年底才发的 v0.1 版，最新的也只是 v0.2.2，尚在早期开发阶段就已经相当不错了，后续还有很多功能值得期待。KDE 用户可以毫不犹豫地收下。
唯一让我不爽的是，它的实时预览不能自动平均分割左右视图，每次都要手动调整，期待后续改进。
Remarkable 应该算 Linux 平台下可以找到的最成熟的一款 Markdown 编辑器了。支持 Github Flavored Markdown、双面板实时预览、代码语法高亮、MathJax，还能自定义 css，并导出带样式的 PDF 或 HTML，真的是相当地 remarkable。
如果你喜欢 Github Flavored Markdown，Remarkable 绝对是不二之选！
但唯一让人蛋疼的是，它的左右视图在初始窗口大小时是平均分割的，但是最大化后左侧视图的宽度却不会相应加大，不知道是有意为之还是 bug，总之这一点让我很不爽。
上述两款编辑器虽然都很不错，但它们在编辑 Hexo 文章的时候都有一个问题，就是无法正确处理正文头部的 front-matter 信息，直到我发现了 ReText。
ReText 是一个 Python 写的轻量级编辑器，采用 Python-Markdown，与最初的 Markdown 几乎一致，没什么高级功能，带实时预览。但好在它用的 Python-Markdown 支持插件，可以扩展很多功能，像表格、代码高亮、直接换行等，你完全可以在原始 Markdown 的基础上定制出一套属于自己的风格。其中的 Meta-Data 插件可以识别正文头部的 front-matter 信息，这样在编辑 Hexo 文章的时候就不会在预览中看到文章元数据了。此外还有若干第三方扩展，不满意目前任何一种 Markdown 风格的朋友，用 ReText 定制属于自己的 Markdown 吧！
ghostwriter 与前面的都不一样，它没有左右同步预览。但它推崇一种沉浸式的书写体验，所以界面很干净，而且带有专注模式，值得一试。默认的 Sundown 后端很老了，建议装个 Pandoc 配合使用，这样在预览的时候可以选择多种风格。
用 Markdown 写了东西，就得考虑怎么把它导出成其他格式以方便日后查看，最常用的应该是导出成 HTML 文件。其实 Markdown 编辑器基本都带导出 HTML 功能，但生成 HTML 是一回事，生成漂亮的 HTML 就又是另一回事了。
刚才那几款编辑器里，只有 Remarkable 支持导出带样式的 HTML，ReText 虽然支持自定义 css，但只能在预览窗口看到效果。好在有 Pandoc 这个文档转换神器，可以将 Markdown 文件转换为各种格式，并且可以自定义样式。
既然生成 HTML 不是问题了，那就要好好找找 css 了。目前现成在网上能找到的我认为最漂亮的 css 是这个。如果你有更好的样式推荐，请告诉我。
好了。这下有自己偏好的 Markdown 风格了，也找到称手的编辑器了，生成的 HTML 也入得了自己的法眼了，事情可以结束了。然而，后来我才明白，这并非使用 Markdown 的正确姿势。
对于 Markdown 的反思源于发现的一个十分有意思的 css。这个 css 把 HTML 文件 Markdown 化，让 HTML 看起来像是 Markdown 源文件一样。诶！这让我猛然发现，其实 Markdown 本身就有一种美感！
Markdown 不同于 HTML ，它并不是一种标记语言 (markup language)，所以它才叫 Markdown 啊。本文最开始引用 Markdown 发明者 John Gruber 的那句话已经说得很明确了，一篇 Markdown 文档应该是不需要转换成任何格式而直接这样子拿给人家看就能看懂的。Markdown 在设计之初就把易读性放在与易写性同样重要的位置考虑了。所以即使你把一篇 Markdown 文档拿给一个不知道什么是 Markdown 的人看，我相信他并不会像看 HTML 源文件一样感觉自己是在看某种源代码，相反，他应该能毫无障碍地阅读和理解文档内容及其中体现的逻辑关系。试问你第一次看到 Markdown 的时候，没觉得它是如此直观，无需解释就如此清晰明了吗？
所以 Markdown 到底是什么？我觉得它更像是标点符号一样的东西，它能使文章更易阅读而又藏匿于内容之中不会分散你的注意力。
于是首当其冲，预览 Markdown 就变成了一个毫无意义的话题。既然 Markdown 如此易读，预览它干嘛呢？难道看预览，会比直接看 Markdown 更清楚吗？除了少了几个符号，多了一些字体格式对比之外，本质上，看预览相较直接看 Markdown，在易读性、内容条理性和逻辑性的感知上并没有什么明显的优势。
既然 Markdown 的哲学是要作为一种通俗易懂的符号存在，那么将它转换成其他格式就显得并无必要。虽然当初发明 Markdown 就是为了简化 HTML 的书写，但是前面说了，Markdown 文档也并不是非要转成 HTML 文件才能拿给人家看的。既然如此，就不需要考虑什么编辑器和风格了，所谓的 Markdown，就是加了一些能够使文档内容条理更清晰的符号的纯文本而已。
既然写 Markdown 的目的并不是为了转换成其他格式，于是风格便成了最不重要的东西。你甚至完全可以按照自己的意愿写出属于自己 Markdown，用你自己发明的符号去表示任何你想要表示的东西，只要你觉得你写的够直观，不用解释大家就能看懂。只有在你想要将你的 Markdown 文档转换成其他格式的时候，你才需要去考虑风格的问题，即你写的东西能否被转换器正确识别从而转换成你想要的格式。当然，如果你够牛逼，你也可以自己写一个转换器，设定好规则从而得到你想要的结果。
仔细想来，我之所以纠结于编辑器和风格，没有正确认识 Markdown 的本质是其一，还有一点是并未正确认识到 Markdown 的用途。我们写 Markdown，基本上有这么三种情况：
如果纯粹是写给自己看，比如自己作笔记，那前文已经说过，想怎么写就怎么写，只要这种格式对你有意义，对提升内容的条理性和逻辑性有帮助，你就写。如果是写给别人看，按照 Markdown 直观易懂的特点，你就这么拿给人家看也是不成问题的。当然更多的时候，我们是把 Markdown 当作某种输出格式的原始输入。比如你在 Github 上写评论或写 README，最终就是要被转换成 HTML 呈现出来的。再比如写 Hexo 博客，也是要被转换成 HTML 呈现出来的。
而迷思产生的根源就在于我们过分强调了把 Markdown 当作某种输出格式的原始输入这一功能，而忘却了 Markdown 本身就是一种可以直接呈现的最终格式。
不要把 Markdown 当作某种语言，更不要把它当成什么代码，因为它其实很简单很易读。不要去管什么语法风格，适合自己就好。Markdown 就是 Markdown，不是简化了的 HTML，也不是什么格式化指令，把它当成标点符号自然而然的运用就行了。
本文首发于我的博客：https://www.sundialdreams.com/markdown-myth/
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。