Markdown 转 HTML

Markdown 最初是一种规范松散、没有单一权威语法的格式,这意味着不同的实现在边界情况上会有分歧——嵌套列表该如何表现、单词内部的下划线算不算强调——而且这些分歧经常导致同样的源文本渲染出真正不同的结果。CommonMark 的出现正是为了解决这个问题,它定义了一份精确、无歧义的单一规范,任何遵循它的解析器都必须严格执行。GitHub Flavored Markdown(GFM)在 CommonMark 这个基础之上,增加了几项纯 CommonMark 完全没有定义的扩展:用竖线字符和一行短横线分隔行构建的表格、写成 `- [ ]` 和 `- [x]` 的任务列表复选框、用双波浪线包裹的删除线文字,以及无需显式链接语法就能自动变成超链接的裸 URL。这个工具实现的正是 GFM 这种方言,因为它正是 GitHub、Reddit,以及绝大多数静态站点生成器和文档工具已经标准化采用的方言,这让它成为任何打算在别处被阅读的内容最广泛适用的目标格式。

Markdown 语法刻意允许直接在其中嵌入原始 HTML——这是有意为之的设计,让 Markdown 的作者能够插入一个嵌入内容、一种特定的对齐方式,或者一段 Markdown 自身语法完全没有简写形式的样式。风险在于,一个粘贴进不可信 Markdown 的 `<script>` 标签,或者一个像 `onerror=` 这样的内联事件处理器,通常会在渲染它的上下文里执行,如果这段 Markdown 来自查看预览的人以外的其他人,这就是一个真实的跨站脚本攻击途径。在一个禁用了脚本执行的沙盒 iframe 里渲染实时预览,意味着预览里任何这样的脚本标签或事件处理器根本不会运行——浏览器会拒绝在一个正确配置了沙盒的 frame 内部执行代码,把风险控制在那个被隔离的预览范围之内。

沙盒机制不会做的一件事,是对这个工具产出、供你复制的*生成 HTML 输出*做消毒处理——那份文本层面的输出,依然会完整保留原始 Markdown 里存在的任何原始 HTML,忠实地按照 Markdown 规范的本意保留下来。如果这段生成的 HTML 将被插入一个展示不可信作者内容的实时页面,它在发布之前还需要经过一次独立的服务器端消毒处理,这是一个和这个预览沙盒所处理的任何环节都不同的步骤。

Markdown 被刻意设计成写作者最常用到的那些 HTML 结构——标题、链接、强调、列表——的简写形式,而不是要完整替代 HTML 的全部能力。任何 Markdown 自身语法没有对应简写的内容,从一种特定的内联样式到一段嵌入的视频,都应该直接以字面 HTML 的形式写在 Markdown 源码里,解析器会原样传递它,而不是把它当作无效内容拒绝掉。这是一个可以追溯到 Markdown 最初规范的刻意设计决定,不是任何具体实现里的缺口或疏漏。