marked 中 emoji 与强调、删除线分隔符的交互原理从回归测试到源码级解析【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked本篇技术指南以 marked 仓库中的边界测试用例 test/specs/new/emoji_inline.md及其期望输出 test/specs/new/emoji_inline.html、姊妹用例 test/specs/new/emoji_strikethrough.md为核心讲解一个直接影响所有中文/emoji 内容渲染的核心问题为什么 emoji 字符曾会让**加粗**、*斜体*、~~删除线~~解析失败以及 marked 通过怎样的 Unicode 分类与分隔符delimiter规则将其修复。读完本文你将理解 marked 内联级inline解析器中左分隔符 / 右分隔符 / flanking 规则的工作机制掌握 emoji 被判定为标点的底层原因并学会如何运行与扩展这组回归测试来验证自己的边界场景。一、测试用例全景一组记录曾经失败场景的回归测试test/specs/new/目录存放 marked 的新增回归测试区别于 CommonMark / GFM 官方规范套件与original/旧版行为套件参见 test/run-spec-tests.js 中getTests对五个目录的加载方式。每个用例由一对文件组成.md为 Markdown 输入.html为期望输出。emoji_inline.md 全文结构如下Situations where it fails: **test ** ** test** ** test** **️ test** **️ test** ** test** test test ** test** test ** test** test ***test *** *** test*** *** test*** test test *** test*** test *** test*** test **** test**** Situations where it works: ** ** **⚠️ test** * test* *tt* test **tt** test注意一个关键点文件名为 Situations where it fails 的输入在 期望输出文件 中全部被正确渲染如** test**→strong test/strong。这说明该用例本质是一组回归测试它把历史上 emoji 会导致强调解析失败的输入固化下来断言 marked 当前版本必须按 CommonMark 语义正确渲染。而 Situations where it works 部分则保留了少数依然按字面输出的边界情形如** **不渲染用于锁定符合规范的保守行为。二、根因emoji 在 marked 中属于标点punct要理解 emoji 与**/*/~~的冲突必须先知道 marked 如何给字符分类。在 src/rules.ts 中// list of unicode punctuation marks, plus any missing characters from CommonMark spec const _punctuation /[\p{P}\p{S}]/u; const _punctuationOrSpace /[\s\p{P}\p{S}]/u; const _notPunctuationOrSpace /[^\s\p{P}\p{S}]/u;这是 ECMAScript 的 Unicode 属性转义\p{P}标点符号Punctuation如,、。、\p{S}符号Symbol恰好覆盖了绝大多数 emoji——U1F481、、️、⚠️、、☠️都属于\p{S}二者并集[\p{P}\p{S}]即 marked 判定标点punct的字符集。因此在 marked 的分隔符规则眼里emoji 与逗号、句号等标点属于同一类字符。GFM 变体稍有不同见 src/rules.ts_punctuationGfmStrongEm /(?!~)[\p{P}\p{S}]/u额外把~从标点中剔除以免与删除线语法冲突但 emoji 依旧被视作 punct。这个分类决定了下面所有 flanking 判定。三、分隔符规则源码剖析emoji 如何满足左/右分隔符marked 的强调解析集中在 Tokenizer.ts 的 emStrong 方法其核心分两步先匹配左分隔符再用右分隔符正则扫描配对。3.1 左分隔符规则src/rules.ts 中的左分隔符核心模式/^(?:\*(?:((?!\*)punct)|([^\s*]))?)|^_(?:((?!_)punct)|([^\s_]))?/含义*或_序列之后要么紧跟一个非星号的 punct分组 1要么紧跟一个非空白非星号字符分组 2。emoji 恰好命中第一种——**中是\p{S}因此**具备成为左分隔符的资格。同理***、****也成立。3.2 右分隔符规则src/rules.ts 的emStrongRDelimAstCore定义了星号右分隔符的六条分类规则注释中的#代表 punct(1) #*** → 只能是右分隔符 punct(\*)(?[\s]|$) (2) a***#、a*** → 只能是右分隔符 notPunctSpace(\*)(?!\*)(?punctSpace|$) (3) #***a、***a → 只能是左分隔符 punctSpace(\*)(?notPunctSpace) (4) ***# → 只能是左分隔符 \s(?!\*)(?punct) (5) #***# → 可左可右 punct(\*)(?!\*)(?punct) (6) a***a → 可左可右 notPunctSpace(\*)(?notPunctSpace)用这套规则可以解释测试文件中的所有现象** test**右**前是t非标点非空格后是行尾命中规则 (2) → 可关闭 → 渲染为strong test/strong**⚠️ test**同理命中规则 (2)且⚠️作为 punct 不影响左分隔符判定 → 正常渲染*** test***左右分隔符长度均为 3Math.min(3, 3)为奇数按 emStrong 中的逻辑 生成em其内部文本** test**再递归解析为strong最终输出emstrong test/strong/em**** test****最小分隔符长度 4 为偶数生成strong内层** test**再次递归得到strongstrong test/strong/strong的嵌套加粗** **左分隔符成立但右**前是空格、后是行尾不满足规则 (1)要求前是 punct也不满足规则 (2)要求前是非标点非空格因此无法配对按字面输出——这正是works清单中该行保持** **的原因。3.3_与~的对称处理emStrongRDelimUndsrc/rules.ts对_采用同构规则区别是普通模式刻意去掉规则 (6)a___a不能作为强调关闭并在 emStrong 方法中 额外禁止_出现在两个字母数字之间。删除线则复用同一套 flanking 思想delLDelim与delRDelimCoresrc/rules.ts处理~/~~由 Tokenizer.ts 的 del 方法 执行配对。四、姊妹用例emoji 与删除线~~的交互emoji_strikethrough.md 将同样的 emoji 矩阵搬到~~上期望输出见 emoji_strikethrough.html~~ test~~、~~️ test~~、~~⚠️ test~~→ 均正确渲染为del.../del因为~~后紧跟 punctemoji满足左分隔符闭合端满足右分隔符条件~~ ~~、~~ ~~→ 保持字面属于刻意保留的保守行为类似** **~1 ~2→ 不渲染单~需要两侧 flanking 条件~1后是数字、~2前是数字均不满足punctuation 或非空白的边界要求~~☠️~~ test→ 渲染为del☠️/del test验证了 ZWJ 序列\u200D☠\uFE0F这种多 code point 复合 emoji也能被正确处理。五、底层机制masking 与 astral 字符计数两个实现细节保证了上述规则对 emoji 完全成立。其一掩码masking机制。Lexer.ts 的 inlineTokens 方法 在扫描强调之前先构造一个maskedSrc把反斜杠转义、title、code、html等不应参与分隔符判定的片段替换为等长的与a且每个掩码必须保持原长度见 Lexer.ts。随后emStrong通过maskedSrc.slice(-1 * src.length lLength)对齐到当前扫描位置从而保证链接、代码、HTML 内部的*不会干扰 emoji 附近的强调配对。其二emoji 是 astral 字符。正则匹配基于 UTF-16 code unit而等 emoji 在字符串中占 2 个 code unit☠️甚至由 5 个 code point含 ZWJ 与变体选择符组成。emStrong与del中专门用数组展开来按 code point 计数const lLength [...match[0]].length - 1; // 左分隔符长度按 code point const lastCharLength [...match[0]][0].length; // 结尾字符的 code unit 长度emoji 为 2见 Tokenizer.ts 与 Tokenizer.ts 的注释unicode Regex counts emoji as 1 char; spread into array for proper count。这保证了***中分隔符计数为 3 而非 4️等组合字符也不会把 raw 切片切坏。六、如何运行这组测试验证行为new/目录下的用例由 test/run-spec-tests.js 以默认选项gfm: true区别于 CommonMark 套件的gfm: false驱动与 CommonMark、GFM、original、redos 四套用例一同执行。在仓库根目录可运行# 仅运行规范用例含 emoji_inline 所在的 new 套件 npm run test:specs:only # 全量测试先重建 lib 再跑 specs / unit / umd / cjs / types / lint npm test相关脚本定义见 package.json。新增输入输出对放入test/specs/new/后即可被自动发现如需批量更新期望输出可使用npm run test:update对应 test/update-specs.js。七、实践启示对开发者而言这组用例的启示有三点不要对 emoji 附近的强调做特殊豁免。marked 的做法是把 emoji 统一归入 punct[\p{P}\p{S}]让通用 flanking 规则自然生效而非为 emoji 单独写分支——这也是⚠️、☠️等各类符号都能一致工作的原因理解六条右分隔符规则即可预判渲染结果。凡是**emoji 后跟空格再闭合如** **的情形都不会渲染这与 CommonMark 的 delimiter run 规则一致属于规范行为而非 bugGFM 与 pedantic 模式存在差异。GFM 在 punct 中排除~以兼容删除线pedantic 模式则对左分隔符要求前导空白、并放宽规则 (6)见 src/rules.ts 与 src/rules.ts。如果你的渲染结果在切换pedantic/gfm选项后出现差异应从这套分隔符规则入手排查。若需进一步扩展验证建议在 test/specs/new/ 中仿照emoji_inline的格式为其他\p{S}字符如箭头符号、几何符号补充类似用例然后通过npm run test:specs:only确认输出符合预期。【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 marked 中 emoji 与强调、删除线分隔符的交互原理：从回归测试到源码级解析
marked 中 emoji 与强调、删除线分隔符的交互原理从回归测试到源码级解析【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked本篇技术指南以 marked 仓库中的边界测试用例 test/specs/new/emoji_inline.md及其期望输出 test/specs/new/emoji_inline.html、姊妹用例 test/specs/new/emoji_strikethrough.md为核心讲解一个直接影响所有中文/emoji 内容渲染的核心问题为什么 emoji 字符曾会让**加粗**、*斜体*、~~删除线~~解析失败以及 marked 通过怎样的 Unicode 分类与分隔符delimiter规则将其修复。读完本文你将理解 marked 内联级inline解析器中左分隔符 / 右分隔符 / flanking 规则的工作机制掌握 emoji 被判定为标点的底层原因并学会如何运行与扩展这组回归测试来验证自己的边界场景。一、测试用例全景一组记录曾经失败场景的回归测试test/specs/new/目录存放 marked 的新增回归测试区别于 CommonMark / GFM 官方规范套件与original/旧版行为套件参见 test/run-spec-tests.js 中getTests对五个目录的加载方式。每个用例由一对文件组成.md为 Markdown 输入.html为期望输出。emoji_inline.md 全文结构如下Situations where it fails: **test ** ** test** ** test** **️ test** **️ test** ** test** test test ** test** test ** test** test ***test *** *** test*** *** test*** test test *** test*** test *** test*** test **** test**** Situations where it works: ** ** **⚠️ test** * test* *tt* test **tt** test注意一个关键点文件名为 Situations where it fails 的输入在 期望输出文件 中全部被正确渲染如** test**→strong test/strong。这说明该用例本质是一组回归测试它把历史上 emoji 会导致强调解析失败的输入固化下来断言 marked 当前版本必须按 CommonMark 语义正确渲染。而 Situations where it works 部分则保留了少数依然按字面输出的边界情形如** **不渲染用于锁定符合规范的保守行为。二、根因emoji 在 marked 中属于标点punct要理解 emoji 与**/*/~~的冲突必须先知道 marked 如何给字符分类。在 src/rules.ts 中// list of unicode punctuation marks, plus any missing characters from CommonMark spec const _punctuation /[\p{P}\p{S}]/u; const _punctuationOrSpace /[\s\p{P}\p{S}]/u; const _notPunctuationOrSpace /[^\s\p{P}\p{S}]/u;这是 ECMAScript 的 Unicode 属性转义\p{P}标点符号Punctuation如,、。、\p{S}符号Symbol恰好覆盖了绝大多数 emoji——U1F481、、️、⚠️、、☠️都属于\p{S}二者并集[\p{P}\p{S}]即 marked 判定标点punct的字符集。因此在 marked 的分隔符规则眼里emoji 与逗号、句号等标点属于同一类字符。GFM 变体稍有不同见 src/rules.ts_punctuationGfmStrongEm /(?!~)[\p{P}\p{S}]/u额外把~从标点中剔除以免与删除线语法冲突但 emoji 依旧被视作 punct。这个分类决定了下面所有 flanking 判定。三、分隔符规则源码剖析emoji 如何满足左/右分隔符marked 的强调解析集中在 Tokenizer.ts 的 emStrong 方法其核心分两步先匹配左分隔符再用右分隔符正则扫描配对。3.1 左分隔符规则src/rules.ts 中的左分隔符核心模式/^(?:\*(?:((?!\*)punct)|([^\s*]))?)|^_(?:((?!_)punct)|([^\s_]))?/含义*或_序列之后要么紧跟一个非星号的 punct分组 1要么紧跟一个非空白非星号字符分组 2。emoji 恰好命中第一种——**中是\p{S}因此**具备成为左分隔符的资格。同理***、****也成立。3.2 右分隔符规则src/rules.ts 的emStrongRDelimAstCore定义了星号右分隔符的六条分类规则注释中的#代表 punct(1) #*** → 只能是右分隔符 punct(\*)(?[\s]|$) (2) a***#、a*** → 只能是右分隔符 notPunctSpace(\*)(?!\*)(?punctSpace|$) (3) #***a、***a → 只能是左分隔符 punctSpace(\*)(?notPunctSpace) (4) ***# → 只能是左分隔符 \s(?!\*)(?punct) (5) #***# → 可左可右 punct(\*)(?!\*)(?punct) (6) a***a → 可左可右 notPunctSpace(\*)(?notPunctSpace)用这套规则可以解释测试文件中的所有现象** test**右**前是t非标点非空格后是行尾命中规则 (2) → 可关闭 → 渲染为strong test/strong**⚠️ test**同理命中规则 (2)且⚠️作为 punct 不影响左分隔符判定 → 正常渲染*** test***左右分隔符长度均为 3Math.min(3, 3)为奇数按 emStrong 中的逻辑 生成em其内部文本** test**再递归解析为strong最终输出emstrong test/strong/em**** test****最小分隔符长度 4 为偶数生成strong内层** test**再次递归得到strongstrong test/strong/strong的嵌套加粗** **左分隔符成立但右**前是空格、后是行尾不满足规则 (1)要求前是 punct也不满足规则 (2)要求前是非标点非空格因此无法配对按字面输出——这正是works清单中该行保持** **的原因。3.3_与~的对称处理emStrongRDelimUndsrc/rules.ts对_采用同构规则区别是普通模式刻意去掉规则 (6)a___a不能作为强调关闭并在 emStrong 方法中 额外禁止_出现在两个字母数字之间。删除线则复用同一套 flanking 思想delLDelim与delRDelimCoresrc/rules.ts处理~/~~由 Tokenizer.ts 的 del 方法 执行配对。四、姊妹用例emoji 与删除线~~的交互emoji_strikethrough.md 将同样的 emoji 矩阵搬到~~上期望输出见 emoji_strikethrough.html~~ test~~、~~️ test~~、~~⚠️ test~~→ 均正确渲染为del.../del因为~~后紧跟 punctemoji满足左分隔符闭合端满足右分隔符条件~~ ~~、~~ ~~→ 保持字面属于刻意保留的保守行为类似** **~1 ~2→ 不渲染单~需要两侧 flanking 条件~1后是数字、~2前是数字均不满足punctuation 或非空白的边界要求~~☠️~~ test→ 渲染为del☠️/del test验证了 ZWJ 序列\u200D☠\uFE0F这种多 code point 复合 emoji也能被正确处理。五、底层机制masking 与 astral 字符计数两个实现细节保证了上述规则对 emoji 完全成立。其一掩码masking机制。Lexer.ts 的 inlineTokens 方法 在扫描强调之前先构造一个maskedSrc把反斜杠转义、title、code、html等不应参与分隔符判定的片段替换为等长的与a且每个掩码必须保持原长度见 Lexer.ts。随后emStrong通过maskedSrc.slice(-1 * src.length lLength)对齐到当前扫描位置从而保证链接、代码、HTML 内部的*不会干扰 emoji 附近的强调配对。其二emoji 是 astral 字符。正则匹配基于 UTF-16 code unit而等 emoji 在字符串中占 2 个 code unit☠️甚至由 5 个 code point含 ZWJ 与变体选择符组成。emStrong与del中专门用数组展开来按 code point 计数const lLength [...match[0]].length - 1; // 左分隔符长度按 code point const lastCharLength [...match[0]][0].length; // 结尾字符的 code unit 长度emoji 为 2见 Tokenizer.ts 与 Tokenizer.ts 的注释unicode Regex counts emoji as 1 char; spread into array for proper count。这保证了***中分隔符计数为 3 而非 4️等组合字符也不会把 raw 切片切坏。六、如何运行这组测试验证行为new/目录下的用例由 test/run-spec-tests.js 以默认选项gfm: true区别于 CommonMark 套件的gfm: false驱动与 CommonMark、GFM、original、redos 四套用例一同执行。在仓库根目录可运行# 仅运行规范用例含 emoji_inline 所在的 new 套件 npm run test:specs:only # 全量测试先重建 lib 再跑 specs / unit / umd / cjs / types / lint npm test相关脚本定义见 package.json。新增输入输出对放入test/specs/new/后即可被自动发现如需批量更新期望输出可使用npm run test:update对应 test/update-specs.js。七、实践启示对开发者而言这组用例的启示有三点不要对 emoji 附近的强调做特殊豁免。marked 的做法是把 emoji 统一归入 punct[\p{P}\p{S}]让通用 flanking 规则自然生效而非为 emoji 单独写分支——这也是⚠️、☠️等各类符号都能一致工作的原因理解六条右分隔符规则即可预判渲染结果。凡是**emoji 后跟空格再闭合如** **的情形都不会渲染这与 CommonMark 的 delimiter run 规则一致属于规范行为而非 bugGFM 与 pedantic 模式存在差异。GFM 在 punct 中排除~以兼容删除线pedantic 模式则对左分隔符要求前导空白、并放宽规则 (6)见 src/rules.ts 与 src/rules.ts。如果你的渲染结果在切换pedantic/gfm选项后出现差异应从这套分隔符规则入手排查。若需进一步扩展验证建议在 test/specs/new/ 中仿照emoji_inline的格式为其他\p{S}字符如箭头符号、几何符号补充类似用例然后通过npm run test:specs:only确认输出符合预期。【免费下载链接】markedA markdown parser and compiler. Built for speed.项目地址: https://gitcode.com/gh_mirrors/ma/marked创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考