Markdown → HTML 转换器，免费

将 Markdown 语法转换为干净的 HTML 代码，支持实时预览。

实时预览

支持的 Markdown 语法

标题：# H1、## H2、### H3 等

强调：*斜体*、**粗体**、***粗斜体***、~~删除线~~

链接：[文本](url)

图片：![alt](url)

代码：`行内代码`，以及使用 ``` 的围栏代码块

列表：- 无序项目，1. 有序项目

引用：> 引用文本

水平分隔线：--- 或 ***

如何使用此转换器

  1. 粘贴你的 Markdown。该工具接受 CommonMark 加上最常见的 GFM 扩展,表格、带语言提示的围栏代码、删除线、自动链接和任务列表项。
  2. 查看实时转换。右侧面板显示你输入时的原始 HTML 输出;下面的预览面板将其视觉渲染。
  3. 复制 HTML。使用复制 HTML 按钮获取准备好粘贴到 CMS、邮件客户端、静态站点生成器模板或任何接受 HTML 的地方的输出。

Markdown 简史

Markdown 由 Daring Fireball 博客背后的作家 John Gruber 创建,Aaron Swartz 提供了实质性的设计反馈。第一个公开版本 1.0 于 2004 年 3 月 9 日在 Gruber 的网站上宣布;版本 1.0.1,即规范参考版本,于 2004 年 12 月 17 日发布,仍然是从 daringfireball.net/projects/markdown 链接的版本。Markdown 从一开始就是两件事:纯文本格式化语法和将其转换为 HTML 的原始 Perl 脚本。Gruber 的明确目标是源文本应该像原样可读,在纯文本编辑器中打开的 Markdown 文档应该看起来像一封精心格式化的电子邮件,而不是标签汤。这个可读性约束是将 Markdown 与基于 XML 的格式以及像 LaTeX 这样的更重的标记分开的哲学线,这就是为什么后来的每个扩展都必须就其多大程度地破坏源代码为自己辩护。Aaron Swartz 早些时候写过一个相关的轻量级标记 atx(2002),贡献了现在熟悉的 # 和 ## 标题样式,有时仍在解析器规范中被称为「atx 样式标题」。

CommonMark,修复欠规范

Gruber 2004 年的原始语法描述以非正式而闻名,是一份带有示例的散文文档,而不是语法。它留下了数十个边缘情况未指定,Gruber 从未发布过他的 Perl 脚本之外的参考解析器,其行为以其他实现者必须复制或覆盖的方式独特。到 2010 年代初的结果是 GitHub、Reddit、Stack Overflow、Pandoc 和 Discount C 解析器都略有不同地呈现相同的 Markdown 源代码。2012 年,Stack Overflow 联合创始人 Jeff Atwood 和 Pandoc 作者 John MacFarlane 开始努力编写真正可测试的规范。该项目于 2014 年 9 月作为「Standard Markdown」公开启动;几天内 Gruber 在私人邮件中反对该名称,Atwood 写了一篇公开文章解释更改,该项目被重新命名为「CommonMark」。第一个编号版本于 2014 年 10 月 25 日发布。当前已发布的版本是 CommonMark 0.31.2,于 2024 年 1 月 28 日发布。CommonMark 规范的不寻常之处在于它本身就是一个 CommonMark 文档,内嵌 600 多个可执行测试用例;解析器通过通过这些测试来声称符合规范。GitHub Flavored Markdown(GFM),版本 0.29-gfm 日期为 2019 年 4 月 6 日的正式规范,在 CommonMark 之上定义了五个扩展:表格、任务列表项、删除线、用于裸 URL 的自动链接,以及不允许的原始 HTML(一种从作者提供的 HTML 中删除危险标签的安全限制)。

主要解析器

marked.js由 Christopher Jeffrey 于 2011 年创建,自 2018 年起由 markedjs GitHub 组织维护,这是一个单次通过的词法分析器-然后-解析器设计,优先考虑原始速度;约 36k 星标,是 GitHub 上最多星标的 Markdown 项目。这是此工具用于转换的解析器。markdown-it 于 2014 年由 Vitaly Puzrin 和 Alex Kocharin 推出,宣传 100% CommonMark 符合性,带有可选的 GFM 切换以及积极的插件生态系统(markdown-it-footnote、markdown-it-emoji、markdown-it-attrs、markdown-it-anchor 和数百个其他)。它是 VS Code 内置的 Markdown 预览、GitLab 的 Web UI 和 Eleventy 使用的解析器。remark / unified.js 不是单个解析器,而是树转换框架,unified 集体定义了名为 mdast(Markdown AST)的抽象语法树规范;remark 将 Markdown 解析为 mdast,插件操作树,remark-rehype 将 mdast 转换为 hast(HTML AST)用于发出。比 marked 慢,但更易组合;值得注意的用户包括 Prettier、Gatsby、MDN 和 alex 包容性语言 linter。Pandoc,由 John MacFarlane 于 2006 年 8 月 10 日发布,是通用文档转换器,用 Haskell 编写,解析约 30 种输入格式,渲染约 40 种输出格式;在学术和技术出版中无处不在。

MD-到-HTML 管道,机械地

Markdown 解析器通常分两遍工作。块级解析将输入拆分为块结构、段落、标题、列表、代码围栏、块引用、水平规则、表格。块边界由空行和缩进确定;正确处理它们是使 CommonMark 解析器正确的大部分。内联解析然后遍历每个块的内容并匹配内联语法:强调(*斜体*、**粗体**)、链接([文本](url))、内联代码跨度(`代码`)、图像(![alt](url))、删除线(GFM 中的 ~~文本~~)和显式自动链接(<https://example.com>)。内联强调解析是任何 Markdown 规范中最细微的部分,CommonMark 用规范的几页和数十个测试用例来指定何时 *foo*bar* 应该产生 <em>foo</em>bar* 与 *foo<em>bar</em>。然后解析器将每个标记呈现为相应的 HTML 元素并连接结果。漂亮打印、缩进和代码块语法高亮由渲染选项分层。

为什么一开始就将 MD 转换为 HTML?

值得了解的输出选项

不同的下游用途希望从转换的 HTML 中得到不同的东西。完整文档 vs 片段。完整的 HTML 文档包括 <!DOCTYPE html>、<html>、带元数据的 <head> 和 <body> 包装器,适合当你将文件保存为 .html 并在浏览器中打开时。片段只是正文内容,没有包装器,适合当你将粘贴到已经提供文档结构的 CMS 字段时。此工具默认发出片段;如果需要完整文档,请用你自己的样板包装。清理。默认情况下,Markdown 解析器原样传递原始 HTML,因此如果你的源代码包含 <script>alert(1)</script>,该脚本标签将出现在输出中。对于进入多用户系统的文档,在注入 DOM 之前通过 DOMPurify(Cure53,2014 年 2 月开始)运行输出。对于一次性个人使用,原始输出就可以了。标题 ID。在标题上生成 id 属性(从标题文本 slug 化)可以让你构建带锚链接的目录。确切的 slug 算法在不同平台之间有所不同,GitHub 使用一条规则,MkDocs 另一条,marked.js 第三条,因此当内容在系统之间移动时,锚链接可能会断裂。硬换行。CommonMark 要求行末尾有两个尾随空格或反斜杠以强制 <br>;一些平台(Discord、GitHub issues)将单个换行视为换行。选择取决于源代码的预期样式。

常见陷阱

此工具 vs Markdown 预览器

Absolutool 提供两个相关工具,它们在同一解析器上重叠。Markdown 预览器用于实时编辑,在左侧写 Markdown,在右侧看到渲染的视觉输出,没有「HTML 输出」的概念。此 Markdown-到-HTML 转换器用于一次性转换,粘贴 Markdown,复制原始 HTML,粘贴到你的 CMS 或邮件客户端中。在起草并需要视觉反馈时使用预览器;当你有完成的 Markdown 并需要可以传输到其他地方的 HTML 时使用此转换器。两个工具都在底层使用 marked.js 并接受相同的 CommonMark + GFM 方言,因此它们之间的转换行为是相同的。

隐私:为什么仅浏览器在这里重要

未发表写作的草稿、进行中的博客文章、内部文档、NDA 下的客户交付物、手稿章节、学术论文,正是你不希望上传到第三方服务的那种文本。服务器端 Markdown 转换器需要将整个文档发送到远程端点,这意味着它停留在服务器的日志中,可能在 CDN 缓存中,可能在分析管道中,可能在备份中。对于已发表的文本,问题是没有意义的。对于草稿工作,架构很重要。此工具通过 JavaScript 和 marked.js 在你的浏览器中运行整个管道。Markdown 永远不会越过网络,在你输入时在 DevTools 的 Network 选项卡中验证,或在页面加载后将其离线(飞行模式)并确认转换器仍然工作。对机密草稿、客户交付物、NDA 下的手稿章节、内部备忘录或你不希望被复制到陌生人硬盘上的任何其他内容都安全。

常见问题

此转换器支持哪种 Markdown 方言?

CommonMark 启用了最常见的 GFM 扩展,表格(管道分隔,带可选 : 对齐)、带语言提示的围栏代码块、通过 ~~文本~~ 的删除线、用于裸 URL 的自动链接,以及通过 [ ] 和 [x] 的任务列表项。标题、粗体、斜体、链接、图像、列表、块引用、水平规则和内联代码都按你期望的在 GitHub 上工作。渲染器是 marked.js,即 Markdown 预览器使用的相同解析器。

这支持 GitHub Flavored Markdown(GFM)吗?

是的,带管道的表格、带语言提示的围栏代码块、任务列表、自动链接和删除线都有效。如果 GFM 扩展未渲染,请仔细检查输入是否遵循 CommonMark/GFM 语法规则:块元素周围的空行、围栏代码块上匹配的反引号计数、用于硬换行的恰好两个尾随空格(或反斜杠)。「GFM 不工作」最常见的原因是保存时去除尾随空白的编辑器,这会杀死硬换行语法。

输出在 GitHub 上看起来会一样吗?

结构 HTML、段落、列表、表格、标题将与任何有效的 CommonMark + GFM 输入匹配。两层将不同。GitHub 应用其自己的 CSS 主题和语法高亮,因此颜色、字体和间距看起来会不同。GitHub 还在规范之上分层后处理,表情简码(:smile:)、@user 提及、#issue 自动链接、相对存储库的图像路径,任何符合规范的转换器都不能复制。此工具发出的 HTML 在结构上是可移植的;视觉外观取决于目的地的 CSS。

我应该在发布前清理输出吗?

如果源代码可能包含用户提供的内容,是的。Markdown 解析器原样传递原始 HTML,因此包含 <img src=x onerror="alert(1)"> 的源将在输出中产生该标签。对于多用户系统,在注入 DOM 之前通过 DOMPurify(Cure53,2014 年 2 月,事实上的 JavaScript 清理器)运行输出。对于源代码是你自己写作的一次性个人使用,这不是问题,你能对自己页面做的最糟糕的事情是粘贴你自己的 HTML。

我可以获得带 head 和 body 的完整 HTML 文档吗?

目前此工具仅发出正文片段,转换的 Markdown 包装在语义 HTML 标签中,但不在完整的 <html>/<head>/<body> 文档中。要保存为独立的 .html 文件,请自己包装输出:<!DOCTYPE html><html><head><meta charset="utf-8"><title>...</title></head><body>[片段]</body></html>。或使用 Pandoc 的 --standalone 标志,以获得带模板驱动 CSS 的完全独立输出。

我的 Markdown 会被发送到任何地方吗?

不会。转换完全通过 marked.js 在你的浏览器中运行。你粘贴的 Markdown 永远不会越过网络,在你输入时在 DevTools 的 Network 选项卡中验证,或在页面加载后将其离线(飞行模式)并确认转换器仍然工作。对机密草稿、NDA 下的客户交付物、手稿章节或你不希望被复制到陌生人硬盘上的任何文本都安全。

相关工具

HTML → Markdown

将 HTML 转换为干净的 Markdown。支持标题、链接、列表、表格等。

Markdown 预览

书写 Markdown 并实时查看渲染。支持表格、代码块等。

Markdown 表格生成器

用电子表格式界面可视化构建 Markdown 表格。设置对齐方式并复制输出。