marked 解析 GFM 非管道表格（nptable）：strong_following_nptables 用例源码级剖析

marked 解析 GFM 非管道表格（nptable）：strong_following_nptables 用例源码级剖析

【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked

摘要：本文以 marked 仓库中test/specs/new/strong_following_nptables.md测试用例为切入口，深入讲解 GFM 非管道表格（Non-Pipe Table，简称 nptable）的解析规则。通过该用例可以完整理解：什么语法会被识别为 nptable、表头/对齐行/数据行的组织方式、单元格内联 Markdown（如**strong**）的处理流程，以及它与普通管道表格、setext 标题之间的边界判定。读者读完将掌握 marked 表格解析的完整调用链（Lexer → Tokenizer → Parser → Renderer），并能据此写出符合预期的表格 Markdown。

用例原始内容：一个 5 行输入引发的解析细节

关联文档test/specs/new/strong_following_nptables.md全文只有 5 行：

abc | def --- | --- bar | foo baz | boo **strong**

其对应的预期输出test/specs/new/strong_following_nptables.html是一张 2 列 3 行的完整表格，其中最后一行第一列渲染为<strong>strong</strong>，第二列为空单元格：

<table> <thead> <tr> <th>abc</th> <th>def</th> </tr> </thead> <tbody> <tr> <td>bar</td> <td>foo</td> </tr> <tr> <td>baz</td> <td>boo</td> </tr> <tr> <td><strong>strong</strong></td> <td></td> </tr> </tbody> </table>

这个用例之所以特殊，在于第 5 行**strong**既没有管道符|，也没有被当作普通段落输出——它被并入表格的最后一行作为第一个单元格的内容。这正是 nptable（非管道表格）的典型行为：只要没有空行、也没有能中断表格的块级元素（如标题、列表、围栏代码、HTML 块等），后续行会持续作为表格数据行被吞并。

一、什么是 nptable：与管道表格的同源不同形

marked 的表格解析由 GFM（GitHub Flavored Markdown）扩展提供，默认开启（见 src/defaults.ts 中gfm: true）。GFM 表格有两种写法：

仓库中有一对几乎一一对应的测试用例：

• test/specs/new/strong_following_nptables.md（本用例，无首尾管道符）
• test/specs/new/strong_following_tables.md（每行首尾带|的管道版本）

两者预期 HTML 输出完全相同。这组对照测试说明：nptable 与 pipe table 在标记解析和渲染层面共享同一条路径，区别只在于是否要求行首行尾出现管道符。

二、核心正则：gfmTable 如何识别 nptable

marked 的词法规则集中定义在 src/rules.ts。GFM 表格正则gfmTable（src/rules.ts）由三部分拼接而成：

const gfmTable = edit( '^ *([^\n ].*)\n' // ① 表头行 + ' {0,3}((?:\| *)?:?-+:? *(?:\| *:?-+:? *)*(?:\| *)?)' // ② 对齐行（分隔行） + '(?:\n((?:(?! *\n|hr|heading|blockquote|code|fences|list|html).*(?:\n|$))*)\n*|$)' // ③ 数据行 ...

对照本用例逐行匹配：

1. 表头行abc | def：匹配^ *([^\n ].*)\n，得到表头字符串abc | def；
2. 对齐行--- | ---：匹配第二部分，其中:?-+:?允许-、:-、-:、:-:等对齐写法（本用例为无对齐的---）；
3. 数据行bar | foo、baz | boo、**strong**：匹配第三部分——只要下一行不是空行，也不是hr、标题、引用、代码、围栏、列表、HTML 块（这些占位符会被 src/rules.ts 依次替换为具体正则，例如list替换为{0,3}(?:[*+-]|1[.)])[ \t]），就会被持续吞入表格。

第三部分的负向前瞻(?! *\n|hr|heading|blockquote|code|fences|list|html)是理解**strong**被并入表格的关键：它不以*开头视为列表项（列表要求*后必须跟空格或制表符），也不是其他中断元素，因此继续作为表格数据行处理。

三、边界判定：为何**strong**不是列表也不是段落

**strong**出现在表格数据区时容易被误判为无序列表项或新段落，marked 通过两层防线避免误判：

第一层：gfmTable 数据行正则的中断判定。如上所述，list被替换为{0,3}(?:[*+-]|1[.)])[ \t]（src/rules.ts），要求星号后必须有空白字符才算列表项。**strong**的第二个*紧跟其后，不满足条件，因此不会中断表格。

第二层：tableDelimiter 校验。在 src/Tokenizer.ts 中，marked 会对对齐行做二次校验：

if (!this.rules.other.tableDelimiter.test(cap[2])) { // delimiter row must have a pipe (|) or colon (:) otherwise it is a setext heading return; }

tableDelimiter定义为/:|/（src/rules.ts），即对齐行必须含|或:。本用例对齐行--- | ---含管道符，通过校验；若对齐行是纯---，则会被回退识别为 setext 标题，这正是Tokenizer.table注释"delimiter row must have a pipe (|) or colon (:) otherwise it is a setext heading"所表达的语义。仓库中还有一组配套用例table_vs_setext（test/specs/new/table_vs_setext.md）专门验证这条边界。

四、Token 生成：从字符串到结构化 Token

匹配成功后，src/Tokenizer.ts 的table()方法把原始文本结构化为Tokens.Table。关键步骤：

1. 表头与对齐解析：headers = splitCells(cap[1])切分表头；对齐行用tableAlignChars去掉首尾管道后按|切分；
2. 列数一致性校验：if (headers.length !== aligns.length) return;（src/Tokenizer.ts）——表头列数与对齐列数必须相等，否则整个表格判定失败（数据行列数可不同）；
3. 对齐方向映射：tableAlignRight、tableAlignCenter、tableAlignLeft（src/rules.ts）分别对应right、center、left，否则为null；
4. 单元格内联解析：每个表头与数据单元格都调用this.lexer.inline(...)（src/Tokenizer.ts），所以**strong**在 Token 阶段就被解析为strong类型的行内 Token。

单元格切分依赖 src/helpers.ts 的splitCells函数，它会：为每个未转义的|前补空格以区分转义管道、丢弃首尾空单元格、并按表头列数count补齐或截断单元格。这正是本用例最后一行**strong**只有 1 列内容却渲染出<td></td>空单元格的原因——splitCells按 2 列补齐。

五、渲染输出：Parser 与 Renderer 的协作

Token 生成后，src/Parser.ts 遇到type: 'table'时调用this.renderer.table(token)，最终由 src/Renderer.ts 输出 HTML：

• table()：遍历 header 与 rows，拼装<thead>与<tbody>；
• tablerow()：每行输出<tr>\n...\n</tr>；
• tablecell()：表头单元格用<th>、数据单元格用<td>，若有对齐信息则输出align="..."属性，单元格内容通过this.parser.parseInline(token.tokens)渲染行内 Token——strongToken 最终变成<strong>strong</strong>。

test/unit/Parser.test.js中'table'用例（test/unit/Parser.test.js）验证了table类型 Token 到 HTML 的完整转换，可作为阅读入口。

六、完整调用链与验证方式

本用例在 marked 中的完整调用链为：

Lexer.lex → block 规则匹配（blockGfm.table） → Tokenizer.table（gfmTable 正则匹配 + tableDelimiter 校验 + splitCells 切分 + inline 内联解析） → Parser.parse（table 分支） → Renderer.table / tablerow / tablecell（输出 HTML）

仓库test/specs/new/下还有一组强相关的配套用例，共同刻画 nptable 的完整行为边界：

• strong_following_tables.md/.html：管道版本的对应用例（输出一致）；
• fences_following_nptable.md/.html、html_following_nptable.md/.html、heading_following_nptable.md/.html、blockquote_following_nptable.md/.html：验证各类块级元素能否中断 nptable；
• inlinecode_following_nptables.md/.html、text_following_nptables.md/.html：验证行内元素跟随 nptable 的行为；
• table_vs_setext.md/.html：验证对齐行缺|/:时回退为 setext 标题的边界。

若需本地复现，可在仓库根目录运行npm test执行全部规格测试（含test/specs/new目录），或用test/run-spec-tests.js单独跑某一用例；单元层面test/unit/Lexer.test.js的'no pipe table'用例（test/unit/Lexer.test.js）直接断言了 nptable 的 Token 结构。

七、实战要点总结

• nptable 无需首尾管道符，只要对齐行含|或:即可被识别；
• 表格会持续吞并后续行，直到空行或标题、列表、引用、围栏、HTML 块等中断元素出现——本用例的**strong**因此成为最后一行单元格；
• 单元格支持完整行内 Markdown，**strong**、`code`、link都会在lexer.inline阶段被正确解析；
• 行内*不会误判为列表，列表中断判定要求*/-/+后跟空白；
• 表头列数必须等于对齐列数，否则整个表格判定失败；数据行列数不足时用空单元格补齐；
• 纯---对齐行是 setext 标题而非表格，这是 nptable 与 setext 标题的关键分界线。

理解strong_following_nptables这个看似微小的用例，实际上就掌握了 marked 表格扩展从词法识别、Token 结构化到 HTML 渲染的完整脉络，也能在编写带强调、代码、链接的 GFM 表格时准确预判解析结果。

【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked