marked 中表格后紧跟列表的解析行为list_following_table 测试用例源码级解读【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked导读在 GitHub Flavored MarkdownGFM中管道表格pipe table与无序列表相邻出现是常见排版场景例如表头 说明列表。由于表格行与列表项都以|、-、*等字符开头两者边界极易被误判——表格的单元格收集可能吞掉后续列表列表也可能反向打断表格。marked 通过test/specs/new/list_following_table.md这一回归测试用例把表格后紧跟列表的边界行为固化为可验证的契约。本文以该用例为骨架结合 marked 的规则定义、Tokenizer、Lexer 与 Renderer 源码逐层拆解这一场景的解析原理并给出如何运行与扩展测试的实战方法。一、测试用例全貌输入与期望输出该用例由一对文件组成位于 test/specs/new/ 目录下Markdown 输入list_following_table.md期望 HTML 输出list_following_table.html输入内容为一张 2 列 × 2 行的 GFM 表格紧接一个 3 项的无序列表| abc | def | | --- | --- | | bar | foo | | baz | boo | - foo - bar - bazmarked以默认gfm: true配置解析期望的输出是两个互不干扰的块级元素先是一个完整的table再是一个ultable thead tr thabc/th thdef/th /tr /thead tbody tr tdbar/td tdfoo/td /tr tr tdbaz/td tdboo/td /tr /tbody /table ul lifoo/li libar/li libaz/li /ul这个期望输出揭示了两条核心语义表格在数据行之后必须恰好终止- foo不会被当作表格的一行同时列表必须从表格结束后重新开始列表项不能拼进表格的单元格。二、边界规则从何而来GFM 表格正则中的list替换表格与列表的边界由块级语法规则决定。在 src/rules.ts 中marked 通过edit()模板构建gfmTable正则其结构分三段const gfmTable edit( ^ *([^\\n ].*)\\n // Header {0,3}((?:\\| *)?:?-:? *(?:\\| *:?-:? *)*(?:\\| *)?) // Align (?:\\n((?:(?! *\\n|hr|heading|blockquote|code|fences|list|html).*(?:\\n|$))*)\\n*|$)) // Cells .replace(list, {0,3}(?:[*-]|1[.)])[ \\t]) // any bullet ends the table rows .getRegex();关键在第三段Cells它用负向前瞻(?! *\n|hr|heading|blockquote|code|fences|list|html)逐个扫描表格数据行一旦遇到列表标记就停止收集单元格。源码注释明确写着any bullet ends the table rows——即- foo、* bar、 baz或1. xxx这类行会直接终结表格。因此输入中表格最后一行的| baz | boo |之后遇到- fooCells 段随即终止表格 token 的raw止步于baz | boo |剩余的- foo、- bar、- baz三行交由后续的list规则解析为无序列表。这就是本用例输出结构的规则级成因。需要留意gfmTable是仅 GFM 启用的规则在 src/rules.ts 中CommonMark 模式blockNormal下table被置为noopTest恒不匹配只有blockGfm才覆盖为gfmTable见 src/rules.ts。这与 src/defaults.ts 中gfm: true的默认值一致——不显式关闭 GFM 时上述表格解析行为默认生效。三、Tokenizer 如何决定这是表格而不是 setext 标题正则命中后是否真把文本识别为表格还要经过 Tokenizer.table 的语义校验table(src: string): Tokens.Table | undefined { const cap this.rules.block.table.exec(src); if (!cap) return; if (!this.rules.other.tableDelimiter.test(cap[2])) { // delimiter row must have a pipe (|) or colon (:) otherwise it is a setext heading return; } ... }分隔行本例的| --- | --- |必须含|或:对应 src/rules.ts 的tableDelimiter: /[:|]/否则按 setext 标题处理。随后用splitCells()切分表头与数据行单元格src/helpers.ts会正确处理转义管道\|与首尾管道从分隔行解析对齐方式:-:为 center、-:为 right、:-为 left否则为nullsrc/rules.ts校验表头与分隔行列数相等——if (headers.length ! aligns.length) return;列数不一致时整块回退为普通段落逐行把单元格文本交给this.lexer.inline()做行内解析产出Tokens.Table。由于- foo已被正则挡在 Cells 段之外cap[3]只包含两行数据行rows数组恰好为[| bar | foo |, | baz | boo |]表格 token 结构完整。四、Lexer 的调用顺序table 先于 paragraph 与 listtoken 的产生顺序决定了后续列表能否接得住。在 Lexer.lex 的块级循环中table的检查位置在lheading、paragraph、text之前// table (gfm) if (token this.tokenizer.table(src)) { src src.substring(token.raw.length); tokens.push(token); continue; }其意义是以管道开头的内容优先尝试表格解析成功后src前移到表格 raw 的末尾下一轮循环继续处理- foo。此时- foo已是行首匹配list规则src/rules.ts 的blockNormal.list或 GFM 变体并被切分为Tokens.List最终与前一个tabletoken 并列存放在 tokens 数组中。若 table 检查被后移- foo就可能在段落收集阶段被误并这正是该用例存在的原因。此外 GFM 段落规则blockGfm.paragraph也做了配套处理.replace(table, gfmTable)允许表格打断段落而.replace(list, {0,3}(?:[*-]|1[.)])[ \\t][^ \\t\\n])只允许非空列表打断段落src/rules.ts进一步收紧块级边界。五、Renderer 的输出契约解析得到的Tokens.Table由 Renderer.table 渲染表头包进thead每个单元格为th数据行包进tbody每个单元格为td有对齐时在标签上输出align属性tablerow生成tr行tablecell内部通过parser.parseInline处理行内 token。列表则由list渲染分支输出ul/li。这与本用例期望 HTML 的逐字符结构完全吻合也解释了为什么输出中表格与列表之间存在换行分隔。六、如何运行与验证该测试该用例属于test/specs/new规格集。运行规格测试的统一入口是 test/run-spec-tests.js它通过getTests()加载commonmark、gfm、new、original、redos五组规格test/run-spec-tests.js其中newTests使用默认的 marked 选项直接跑runTests({ tests: newTests, parse })test/run-spec-tests.js。在仓库根目录执行规格测试npm test # 运行完整测试套件含单元测试与规格测试new规格集中的每个.md/.html文件对即一个断言marked 解析.md的产物必须与.html完全一致忽略行尾空白差异。list_following_table一旦被破坏例如修改gfmTable的 Cells 前瞻、调整 Lexer 中 table 的检查位置或改变splitCells的切分逻辑测试即失败从而为表格后接列表这一边界提供持续回归保护。七、同类边界的横向印证test/specs/new/下存在一整组X following table用例与本用例互为参照共同锁定表格的终止边界fences_following_table.md表格后接围栏代码块heading_following_table.md 与 lheading_following_table.md表格后接 ATX / setext 标题code_following_table.md表格后接缩进代码块html_following_table.md表格后接 HTML 块strong_following_tables.md、inlinecode_following_tables.md、text_following_tables.md关注行内元素与文本在表格后的表现。对比可见gfmTable的 Cells 负向前瞻把hr、heading、blockquote、code、fences、list、html全部列为表格终止信号src/rules.tslist只是其中之一。理解了list_following_table即可举一反三掌握整组用例的规则基础。八、小结list_following_table虽然只有 7 行 Markdown却完整刻画了 marked 在 GFM 模式下的一条关键边界契约表格单元格收集被列表行精确终止后续列表作为独立块级元素输出。其实现证据链清晰——规则层由gfmTable的 Cells 前瞻定义src/rules.tstoken 层由Tokenizer.table校验src/Tokenizer.ts调度层由Lexer中 table 优先于 paragraph/list 的顺序保证src/Lexer.ts输出层由Renderer.table落实src/Renderer.ts。对使用者而言这意味着表格 列表组合无需任何额外分隔或转义即可安全书写对维护者而言任何对表格正则或调度顺序的改动都受该用例持续监督。【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考