marked 删除线strikethrough解析源码解读从 del_flanking 规范测试看~与~~的边界规则【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked本篇文章以 marked 仓库中 test/specs/new/del_flanking.md 及其 期望输出 HTML 为骨架深入剖析删除线语法在相邻标点、空格与数字场景下的词法判定规则。读者将掌握 marked 如何区分左/右定界符delimiter、~与~~两种删除线标记的配对逻辑以及这一规范测试如何在 run-spec-tests.js 中与源码实现相互印证。一、背景删除线在 marked 中的定位删除线strikethrough是 GFMGitHub Flavored Markdown扩展语法不属于 CommonMark 核心规范。在 marked 中它由内联inline规则中的del系列规则实现并与 GFM 开关绑定src/defaults.ts 中gfm: true为默认值delLDelim/delRDelim/del规则被挂载在inlineGfm见 src/rules.ts仅在 GFM 模式下启用内联 Token 定义见 src/Tokens.tsDel包含raw原始文本、text内部内容以及tokens内部内容的嵌套内联解析结果渲染阶段由 src/Renderer.ts 将deltoken 输出为del…/del内部tokens再交由parser.parseInline继续递归解析因此删除线内部可以继续嵌套强调、链接等内联元素。del_flanking这个名字中的 flanking邻接性直接点出了本组测试的核心删除线定界符与前后相邻字符标点、空格、数字之间的位置关系决定了它到底是左定界符开启删除线右定界符关闭删除线还是既是左又是右。二、规范测试内容全览7 个用例逐条拆解del_flanking.md 共包含 7 个输入段落del_flanking.html 给出了对应的期望输出。逐条对照如下#输入md期望输出html结论1~1,~2~1,~2原样~不开启删除线作为普通文本2Between ~1.34 and ~5.4原样输出数字邻接~不构成删除线3Between (~1.34) and (~5.4)原样输出括号包裹下数字仍邻接~不构成删除线4~ test~原样输出开头的~后跟空格不是合法左定界符5~test ~原样输出结尾的~前有空格不是合法右定界符6~125 GeV位于加粗中只渲染strong~173 GeV/strong数字前的~不被识别为删除线但强调正常解析7~~1 **~~2**~~1 strong~~2/strong~~同样不因数字而开启删除线这 7 个用例统一指向一个核心结论当~或~~紧邻数字或空格时marked 不会将其判定为删除线定界符。这与 CommonMark 强调语法的 flanking 判定思路一脉相承——数字、字母非标点非空格字符在左右两侧的邻接情况决定了定界符的开/关能力。三、源码级原理delLDelim 与 delRDelim 的 flanking 判定删除线的定界符判定没有直接复用强调em/strong的规则而是定义了两套专用正则见 src/rules.ts左定界符delLDelim/^~~?(?:((?!~)punct)|[^\s~])/u~~?匹配 1 到 2 个~后面必须是非 ~ 的标点((?!~)punct)或非空格非 ~ 字符[^\s~]换言之~之后紧跟空格或~之外的空白时不构成左定界符——这解释了用例 4~ test~为什么原样输出。右定界符delRDelim由 6 个分支组成每个分支都对应一类 flanking 情形分支模式含义(1)(?!~)punct(~~?)(?[\s]\|$)#~~只能作为右定界符(2)notPunctSpace(~~?)(?!~)(?punctSpace\|$)a~~#、a~~只能作为右定界符(3)(?!~)punctSpace(~~?)(?notPunctSpace)#~~a、~~a只能作为左定界符(4)\s(?!~)(?punct)~~#只能作为左定界符(5)(?!~)punct(~~?)(?!~)(?punct)#~~#既可左也可右(6)notPunctSpace(~~?)(?notPunctSpace)a~~a既可左也可右其中_punctuation定义为[\p{P}\p{S}]Unicode 标点 符号_notPunctuationOrSpace为[^\s\p{P}\p{S}]见 src/rules.ts。数字、字母都属于notPunctSpace因此用例 1、2、3、6、7 中的~1.34、~5.4、~125、~173开头的~左侧是空格或(punct右侧是数字notPunctSpace——这落入分支 (4) 或 (3) 的只能作为左定界符情形而左侧缺少可配对的右定界符数字前不允许出现右定界符于是删除线不成立~原样保留用例 5 的test ~结尾~左侧是空格、右侧是行尾任何分支都不满足右定界符条件故不闭合。四、Tokenizer 中的配对与截断逻辑定界符正则只解决识别真正的配对逻辑在 src/Tokenizer.ts 的del(src, maskedSrc, prevChar)方法中先用delLDelim尝试匹配左定界符match[1]取出其后紧跟的字符若nextChar为空、或prevChar为空、或prevChar是标点punctuation.exec(prevChar)则进入配对循环以delRDelim在掩码后的源码上反复exec逐个收集可能的右定界符左右定界符的~个数必须严格相等if (rLength ! lLength) continue保证~配~、~~配~~若中途遇到另一个只能作为左定界符的~~则累加到delimTotal视作嵌套的开启者直到delimTotal 0表示找到足够数量的右定界符此时截取raw与内部text并通过this.lexer.inlineTokens(text)递归解析内部内容生成嵌套的tokens最终返回type: del的 token交给 Renderer.ts 输出del。代码注释src/rules.ts明确说明这套规则similar to emStrongLDelim for asterisk与星号强调的左定界符规则相似从源码结构可以推断删除线的 flanking 判定复用了强调语法中经过大量回归测试验证的定界符栈 数量配对模式只是将字符从*/_换成~并将支持范围收敛为 1 个或 2 个~注释 Create del token - only single ~ or double ~~ supported见 src/Tokenizer.ts。五、数字与强调共存用例 6 揭示的解析次序用例 6 是整组测试中最具实战价值的一条The mass of the Higgs boson is ~125 GeV, while the top quark is **~173 GeV**期望输出pThe mass of the Higgs boson is ~125 GeV, while the top quark is strong~173 GeV/strong/p这验证了两个事实~125/~173不构成删除线——数字紧邻~左定界符规则delLDelim虽能匹配~1数字属于[^\s~]但由于右侧数字后续没有合法的关闭定界符行内没有任何~与之前缀在正确 flanking 位置上配对整个deltoken 无法成立强调**…**完全不受影响——del解析失败后inline 解析器继续尝试后续规则emStrong、text等~173 GeV作为普通文本落入strong内部最终由嵌套解析正确输出。这说明 marked 的 inline 解析采用依次尝试各规则、失败即回退的机制删除线的失败不会毒化相邻的强调解析——这也是该测试用例同时验证del与emStrong两类规则互不干扰的原因。六、测试如何接入 marked 的规范测试体系del_flanking属于 marked 的new规范目录test/run-spec-tests.js 将specs/new与commonmark、gfm、original、redos并列纳入规范测试扫描目录resolve(__dirname, ./specs/commonmark), resolve(__dirname, ./specs/gfm), resolve(__dirname, ./specs/new), resolve(__dirname, ./specs/original), resolve(__dirname, ./specs/redos),该脚本按同名.md.html成对的方式加载用例.md作为输入源码.html作为期望输出逐一运行 marked 渲染并对比结果。因此 del_flanking.md 与 del_flanking.html 必须保持同步修改任何改动都会在 CI 中被该测试捕获。此外new目录还包含大量与删除线相关的配套用例可作为深入阅读的延伸材料del_strikethrough.md删除线基本语法的正例集合~~text~~的常规渲染escape_within_del.md删除线内部反斜杠转义行为emoji_strikethrough.mdemoji 与删除线组合Unicode 按码点计长strikethrough_in_em_strong.md删除线与强调嵌套时的优先级del_flanking.md本文主题邻接标点/空格/数字的边界情形。七、实战建议与可验证结论1. 何时删除线会生效~~删除的内容~~两侧为常规字符正常输出del删除的内容/del~单波浪删除~同样受支持~~?允许 1 或 2 个~但需注意左右个数必须一致。2. 何时删除线不会生效会被当作普通文本~后紧跟空格~ test~~前紧跟空格或行首后跟数字~125 GeV、~1.34括号包裹的数字同样不生效(~5.4)~~与~~数量不对称。3. 排查与验证手段直接运行规范测试在仓库根目录执行npm test或按 package.json 中的 test 脚本观察specs/new/del_flanking是否通过使用 api/dingus.js 提供的交互式 dingus 工具快速输入~相关片段验证渲染结果阅读 src/rules.ts 与 src/Tokenizer.ts 的注释理解每个分支对应的 flanking 语义。4. 边界规则总结表场景delLDelim判定delRDelim判定删除线结果~~text~~✅ 左定界符✅ 右定界符✅deltext/del~1.34✅ 可作左定界符❌ 无配对❌ 原样输出~ test~❌ 后跟空格❌❌ 原样输出test ~—❌ 前为空格❌ 原样输出~~1 **~~2**✅ 可作左定界符❌ 无配对❌ 原样输出强调正常八、小结del_flanking.md 是一份小而精的规范测试文档7 个用例精确锁定了 marked 删除线语法在邻接标点、空格与数字时的边界行为。透过它可以看到 marked 删除线实现的两层设计规则层src/rules.ts用带 flanking 语义的delLDelim/delRDelim正则完成定界符分类配对层src/Tokenizer.ts用数量配平与掩码扫描完成 token 组装最终由 src/Renderer.ts 输出del。这套规范测试驱动 规则/配对分离的结构正是 marked 处理内联语法边界问题的典型范式值得在自定义扩展语法时借鉴。【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考