marked 解析边界行为探秘波浪线围栏代码块如何在文件末尾打断段落【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked导读本篇文章聚焦 markedA markdown parser and compiler. Built for speed仓库中一个极具代表性的规范测试用例——tilde_fence_eof_interrupts_paragraph.md。该用例验证了一个微妙的解析边界当一段普通文本后面紧跟一个未闭合、且直达文件末尾EOF的波浪线围栏标记~~~时marked 应当如何分词与渲染。读完本文你将掌握 marked 围栏代码块fenced code block的完整匹配规则、段落被打断paragraph interruption的底层正则机制以及 gfm 选项关闭后语法集如何切换并学会如何运行这条规范测试进行验证。一、测试用例速览三行内容一个边界行为该用例的 Markdown 输入与期望输出分别存放在两个同名文件中输入tilde_fence_eof_interrupts_paragraph.md期望输出tilde_fence_eof_interrupts_paragraph.html输入文件全文如下--- gfm: false --- foo ~~~--- gfm: false --- foo ~~~它由两部分组成YAML 风格的 frontmatter 头gfm: false声明这条测试必须在关闭 GFM 模式的选项下运行用于隔离验证 CommonMark 核心语法的行为正文一行foo加一行~~~且~~~之后没有换行、没有闭合围栏直接到达文件末尾。对应的期望输出 HTML 是pfoo/p precode/code/pre二、输出结果解析两个独立 token 的拼接这份期望输出揭示了两个关键结论结论一~~~成功打断了段落foo。如果~~~没有打断能力foo和~~~会合并进同一个段落输出将是包含两行文本的单个p标签。而实际输出中foo被独立渲染为pfoo/p说明围栏起始标记被识别为新的块级元素起点。结论二未闭合到 EOF 的~~~依然被识别为一个合法的围栏代码块起始并渲染为空代码块。输出中的precode/code/pre对应一个lang为空、text为空的代码块 token——围栏打开了但既没有代码内容也没有闭合围栏marked 将其视为一个空代码块而非普通文本。这与同目录下的对照用例 backtick_fence_eof_interrupts_paragraph.md反引号版本输入foo\n行为完全一致二者期望输出相同。这印证了 marked 对两种围栏字符反引号与波浪线~在 EOF 边界上的处理是统一的。三、底层原理一fences 正则如何允许未闭合直达 EOF围栏代码块的块级正则定义在 rules.tsconst fences /^ {0,3}({3,}(?[^\n]*(?:\n|$))|~{3,})([^\n]*)(?:\n|$)(?:|([\s\S]*?)(?:\n|$))(?: {0,3}\1[~]* *(?\n|$)|$)/;逐段拆解这个正则片段含义^ {0,3}围栏起始标记前允许 0~3 个空格缩进超过 3 个空格则退化为缩进代码块{3,}(?[^\n]*(?:\n|$))反引号围栏至少 3 个反引号且起始行剩余部分不得再含反引号~{3,}波浪线围栏至少 3 个波浪线无行内不能含 ~的限制([^\n]*)(?:\n|$)围栏起始行剩余部分可携带语言标识 lang以换行或 EOF 结尾(?:|([\s\S]*?)(?:\n|$))可选的代码正文非贪婪匹配(?: {0,3}\1[~]* *(?\n$)|$)| **关键分支**要么是闭合围栏至多 3 空格缩进 与起始相同的围栏字符之后只能跟空格/波浪线/反引号直到行尾要么是$——即文本已到文件末尾正是结尾的|$分支让 marked 在围栏未闭合、代码块一路延伸到文件末尾时仍能完成匹配。在本用例中~~~之后立即命中$于是生成一个 raw 为~~~、正文为空、无闭合围栏的代码块 token。四、底层原理二段落正则的否定前瞻实现打断段落paragraph正则同样位于 rules.tsconst _paragraph /^([^\n](?:\n(?!hr|heading|lheading|blockquote|fences|list|html|table|[ \t]\n)[^\n])*)/;它的核心机制是段落可以跨多行延续但每遇到新一行时都会通过否定前瞻(?!...fences...)检查该行是否以hr、heading、lheading、blockquote、fences、list、html、table等块级元素起始。如果是段落立即在此截断。在创建段落规则时fences 的打断形式被替换为rules.ts.replace(fences, {0,3}(?:{3,}(?[^\\n]*(?:\\n|$))|~~~)[^\\n]*(?:\\n|$))因此当解析到foo的下一行是~~~时否定前瞻失败段落 token 只包含foo随后在下一轮块级循环中~~~交给 fences 正则处理。五、底层原理三Lexer 的块级循环与 Tokenizer 产出块级分词的主循环位于 Lexer.ts。在blockTokens的while (src)循环中每轮依次尝试各类块级规则围栏代码块fences排在code缩进代码块之后、heading与hr之前space空行→code缩进代码→fences围栏代码→heading→hr→blockquote→list→html→def→tableGFM→lheading→paragraph→text本用例的解析轨迹为首轮循环src 为foo\n~~~缩进代码不匹配、fences 不匹配最终 paragraph 匹配foo下一行~~~触发否定前瞻截断src 剩余\n~~~次轮循环src 为\n~~~space 规则吞掉单个换行符且因为 raw 长度为 1该换行被并入上一个段落 token 的 rawLexer.tssrc 剩余~~~第三轮循环src 为~~~fences 正则命中src 被清空循环结束。围栏的 token 化实现在 Tokenizer.ts 的fences()方法中它执行this.rules.block.fences.exec(src)并返回一个type: code的 tokenreturn { type: code, raw, lang: cap[2] ? cap[2].trim().replace(this.rules.inline.anyPunctuation, $1) : cap[2], text, };其中lang取自围栏起始行的剩余部分本例为空text经indentCodeCompensation处理围栏内代码的缩进补偿本例为空字符串最终由渲染器输出为precode/code/pre。六、gfm: false 意味着什么frontmatter 中的gfm: false决定 Lexer 采用哪套语法规则集。在 Lexer.ts 的构造函数中pedantic: true→ 使用block.pedantic/inline.pedantic否则gfm: true→ 使用block.gfm并可按breaks切换内联规则否则即本用例的gfm: false→ 使用block.normal/inline.normal即纯 CommonMark 核心语法。需要特别说明的是围栏代码块是 CommonMark 语法与 GFM 无关因此gfm: false下~~~依然生效GFM 模式多出来的是表格、删除线、任务列表、自动链接、url 识别等扩展如 rules.ts 的blockGfm所示只有pedantic 模式对应 John Gruber 原始 Markdown 规范才完全不支持围栏代码块——rules.ts 中fences: noopTest将其禁用。这意味着同样的foo\n~~~输入在pedantic: true下会被当作段落文本处理与本文用例形成鲜明对比。七、纵深佐证性能测试中的同款场景该 EOF 打断行为并非孤例在性能回归测试 quadratic_tilde_paragraph_interrupt.cjs 中有同源场景的放大验证module.exports { markdown: intro\n ~.repeat(50000), html: pintro/p\nprecode\n/code/pre\n, };这条 redosReDoS正则灾难性回溯测试用 5 万个波浪线构造了段落 未闭合波浪线围栏直到 EOF的极端输入期望输出同样是pintro/p加一个代码块。它与本文用例共享相同的解析路径段落先被~~~...打断随后 5 万个~被 fences 正则非贪婪地吞入代码正文直到$。这条测试的存在说明marked 在保证该边界行为正确的同时还专门用大量重复字符验证了匹配过程的线性时间复杂度避免引入性能陷阱。八、如何运行这条规范测试该用例属于 marked 的new规范测试集由 run-spec-tests.js 统一驱动。该脚本从./specs/new目录读取全部.md/.html配对用例getTests加载runTests执行对比其中newTests使用默认选项不覆盖 frontmatter 中声明的gfm: falseconst [commonMarkTests, gfmTests, newTests, originalTests, redosTests] await getTests([ resolve(__dirname, ./specs/commonmark), resolve(__dirname, ./specs/gfm), resolve(__dirname, ./specs/new), resolve(__dirname, ./specs/original), resolve(__dirname, ./specs/redos), ]);在仓库根目录安装依赖并构建后npm install与构建流程详见 README.md 与 package.json执行node test/run-spec-tests.js即可运行全部规范测试。若某条.md用例的解析输出与对应.html文件不一致测试将报错从而把本文讨论的 EOF 边界行为纳入持续回归保护。九、小结一个用例看穿三种解析机制tilde_fence_eof_interrupts_paragraph.md虽然只有三行却同时验证了 marked 的三层核心机制段落打断规则paragraph正则中的否定前瞻保证围栏起始能干净地截断前序段落围栏 EOF 容错fences正则结尾的|$分支使未闭合直达文件末尾的围栏依然成块选项隔离gfm: false下使用 CommonMark 核心语法集围栏行为不受 GFM 开关影响而 pedantic 模式则完全禁用围栏。结合 rules.ts、Lexer.ts、Tokenizer.ts 三处源码与 run-spec-tests.js 的测试框架开发者既能精确理解这一边界行为也能举一反三——同样的分析路径可直接用于排查其他块级元素hr、heading、list 等的段落打断问题。【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 marked 解析边界行为探秘：波浪线围栏代码块如何在文件末尾打断段落
marked 解析边界行为探秘波浪线围栏代码块如何在文件末尾打断段落【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked导读本篇文章聚焦 markedA markdown parser and compiler. Built for speed仓库中一个极具代表性的规范测试用例——tilde_fence_eof_interrupts_paragraph.md。该用例验证了一个微妙的解析边界当一段普通文本后面紧跟一个未闭合、且直达文件末尾EOF的波浪线围栏标记~~~时marked 应当如何分词与渲染。读完本文你将掌握 marked 围栏代码块fenced code block的完整匹配规则、段落被打断paragraph interruption的底层正则机制以及 gfm 选项关闭后语法集如何切换并学会如何运行这条规范测试进行验证。一、测试用例速览三行内容一个边界行为该用例的 Markdown 输入与期望输出分别存放在两个同名文件中输入tilde_fence_eof_interrupts_paragraph.md期望输出tilde_fence_eof_interrupts_paragraph.html输入文件全文如下--- gfm: false --- foo ~~~--- gfm: false --- foo ~~~它由两部分组成YAML 风格的 frontmatter 头gfm: false声明这条测试必须在关闭 GFM 模式的选项下运行用于隔离验证 CommonMark 核心语法的行为正文一行foo加一行~~~且~~~之后没有换行、没有闭合围栏直接到达文件末尾。对应的期望输出 HTML 是pfoo/p precode/code/pre二、输出结果解析两个独立 token 的拼接这份期望输出揭示了两个关键结论结论一~~~成功打断了段落foo。如果~~~没有打断能力foo和~~~会合并进同一个段落输出将是包含两行文本的单个p标签。而实际输出中foo被独立渲染为pfoo/p说明围栏起始标记被识别为新的块级元素起点。结论二未闭合到 EOF 的~~~依然被识别为一个合法的围栏代码块起始并渲染为空代码块。输出中的precode/code/pre对应一个lang为空、text为空的代码块 token——围栏打开了但既没有代码内容也没有闭合围栏marked 将其视为一个空代码块而非普通文本。这与同目录下的对照用例 backtick_fence_eof_interrupts_paragraph.md反引号版本输入foo\n行为完全一致二者期望输出相同。这印证了 marked 对两种围栏字符反引号与波浪线~在 EOF 边界上的处理是统一的。三、底层原理一fences 正则如何允许未闭合直达 EOF围栏代码块的块级正则定义在 rules.tsconst fences /^ {0,3}({3,}(?[^\n]*(?:\n|$))|~{3,})([^\n]*)(?:\n|$)(?:|([\s\S]*?)(?:\n|$))(?: {0,3}\1[~]* *(?\n|$)|$)/;逐段拆解这个正则片段含义^ {0,3}围栏起始标记前允许 0~3 个空格缩进超过 3 个空格则退化为缩进代码块{3,}(?[^\n]*(?:\n|$))反引号围栏至少 3 个反引号且起始行剩余部分不得再含反引号~{3,}波浪线围栏至少 3 个波浪线无行内不能含 ~的限制([^\n]*)(?:\n|$)围栏起始行剩余部分可携带语言标识 lang以换行或 EOF 结尾(?:|([\s\S]*?)(?:\n|$))可选的代码正文非贪婪匹配(?: {0,3}\1[~]* *(?\n$)|$)| **关键分支**要么是闭合围栏至多 3 空格缩进 与起始相同的围栏字符之后只能跟空格/波浪线/反引号直到行尾要么是$——即文本已到文件末尾正是结尾的|$分支让 marked 在围栏未闭合、代码块一路延伸到文件末尾时仍能完成匹配。在本用例中~~~之后立即命中$于是生成一个 raw 为~~~、正文为空、无闭合围栏的代码块 token。四、底层原理二段落正则的否定前瞻实现打断段落paragraph正则同样位于 rules.tsconst _paragraph /^([^\n](?:\n(?!hr|heading|lheading|blockquote|fences|list|html|table|[ \t]\n)[^\n])*)/;它的核心机制是段落可以跨多行延续但每遇到新一行时都会通过否定前瞻(?!...fences...)检查该行是否以hr、heading、lheading、blockquote、fences、list、html、table等块级元素起始。如果是段落立即在此截断。在创建段落规则时fences 的打断形式被替换为rules.ts.replace(fences, {0,3}(?:{3,}(?[^\\n]*(?:\\n|$))|~~~)[^\\n]*(?:\\n|$))因此当解析到foo的下一行是~~~时否定前瞻失败段落 token 只包含foo随后在下一轮块级循环中~~~交给 fences 正则处理。五、底层原理三Lexer 的块级循环与 Tokenizer 产出块级分词的主循环位于 Lexer.ts。在blockTokens的while (src)循环中每轮依次尝试各类块级规则围栏代码块fences排在code缩进代码块之后、heading与hr之前space空行→code缩进代码→fences围栏代码→heading→hr→blockquote→list→html→def→tableGFM→lheading→paragraph→text本用例的解析轨迹为首轮循环src 为foo\n~~~缩进代码不匹配、fences 不匹配最终 paragraph 匹配foo下一行~~~触发否定前瞻截断src 剩余\n~~~次轮循环src 为\n~~~space 规则吞掉单个换行符且因为 raw 长度为 1该换行被并入上一个段落 token 的 rawLexer.tssrc 剩余~~~第三轮循环src 为~~~fences 正则命中src 被清空循环结束。围栏的 token 化实现在 Tokenizer.ts 的fences()方法中它执行this.rules.block.fences.exec(src)并返回一个type: code的 tokenreturn { type: code, raw, lang: cap[2] ? cap[2].trim().replace(this.rules.inline.anyPunctuation, $1) : cap[2], text, };其中lang取自围栏起始行的剩余部分本例为空text经indentCodeCompensation处理围栏内代码的缩进补偿本例为空字符串最终由渲染器输出为precode/code/pre。六、gfm: false 意味着什么frontmatter 中的gfm: false决定 Lexer 采用哪套语法规则集。在 Lexer.ts 的构造函数中pedantic: true→ 使用block.pedantic/inline.pedantic否则gfm: true→ 使用block.gfm并可按breaks切换内联规则否则即本用例的gfm: false→ 使用block.normal/inline.normal即纯 CommonMark 核心语法。需要特别说明的是围栏代码块是 CommonMark 语法与 GFM 无关因此gfm: false下~~~依然生效GFM 模式多出来的是表格、删除线、任务列表、自动链接、url 识别等扩展如 rules.ts 的blockGfm所示只有pedantic 模式对应 John Gruber 原始 Markdown 规范才完全不支持围栏代码块——rules.ts 中fences: noopTest将其禁用。这意味着同样的foo\n~~~输入在pedantic: true下会被当作段落文本处理与本文用例形成鲜明对比。七、纵深佐证性能测试中的同款场景该 EOF 打断行为并非孤例在性能回归测试 quadratic_tilde_paragraph_interrupt.cjs 中有同源场景的放大验证module.exports { markdown: intro\n ~.repeat(50000), html: pintro/p\nprecode\n/code/pre\n, };这条 redosReDoS正则灾难性回溯测试用 5 万个波浪线构造了段落 未闭合波浪线围栏直到 EOF的极端输入期望输出同样是pintro/p加一个代码块。它与本文用例共享相同的解析路径段落先被~~~...打断随后 5 万个~被 fences 正则非贪婪地吞入代码正文直到$。这条测试的存在说明marked 在保证该边界行为正确的同时还专门用大量重复字符验证了匹配过程的线性时间复杂度避免引入性能陷阱。八、如何运行这条规范测试该用例属于 marked 的new规范测试集由 run-spec-tests.js 统一驱动。该脚本从./specs/new目录读取全部.md/.html配对用例getTests加载runTests执行对比其中newTests使用默认选项不覆盖 frontmatter 中声明的gfm: falseconst [commonMarkTests, gfmTests, newTests, originalTests, redosTests] await getTests([ resolve(__dirname, ./specs/commonmark), resolve(__dirname, ./specs/gfm), resolve(__dirname, ./specs/new), resolve(__dirname, ./specs/original), resolve(__dirname, ./specs/redos), ]);在仓库根目录安装依赖并构建后npm install与构建流程详见 README.md 与 package.json执行node test/run-spec-tests.js即可运行全部规范测试。若某条.md用例的解析输出与对应.html文件不一致测试将报错从而把本文讨论的 EOF 边界行为纳入持续回归保护。九、小结一个用例看穿三种解析机制tilde_fence_eof_interrupts_paragraph.md虽然只有三行却同时验证了 marked 的三层核心机制段落打断规则paragraph正则中的否定前瞻保证围栏起始能干净地截断前序段落围栏 EOF 容错fences正则结尾的|$分支使未闭合直达文件末尾的围栏依然成块选项隔离gfm: false下使用 CommonMark 核心语法集围栏行为不受 GFM 开关影响而 pedantic 模式则完全禁用围栏。结合 rules.ts、Lexer.ts、Tokenizer.ts 三处源码与 run-spec-tests.js 的测试框架开发者既能精确理解这一边界行为也能举一反三——同样的分析路径可直接用于排查其他块级元素hr、heading、list 等的段落打断问题。【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考