Biome Markdown 格式化器行内图片Inline Image格式化规范与实现解析【免费下载链接】biomeA toolchain for web projects, aimed to provide functionalities to maintain them. Biome offers formatter and linter, usable via CLI and LSP.项目地址: https://gitcode.com/gh_mirrors/bi/biome导读行内图片是 Markdown 中最常用的语法之一格式看似简单却同时涉及 alt 文本、图片地址destination与可选标题title三个部分的规范化处理。本文以 Biome 仓库中的格式化规格测试 inline_image.md 及其快照 inline_image.md.snap 为骨架逐条拆解 Biome 对行内图片的全部 21 个格式化行为并结合格式化器源码inline_image.rs、inline_link.rs与语法树定义讲清输入什么、输出什么、为什么。读完本文你将能准确预测 Biome 对任意行内图片语法的格式化结果并理解这些规则在 AST 层面是如何落地的。一、这份文档是什么一个以测试用例为规格的规格文件inline_image.md不是传统意义上的说明文档而是 Biome Markdown 格式化器测试体系中一份以输入为规格、以快照为期望输出的测试输入文件。它的定位可以从测试基础设施看出测试入口 spec_tests.rs 通过宏tests_macros::gen_tests! {tests/specs/markdown/**/*.md, crate::spec_test::run, }将tests/specs/markdown/目录下每一个.md文件自动注册为一个规格测试每个输入文件对应的.snap快照由 snapshot_builder.rs 生成记录了Input原始输入与Formatted格式化结果两者对照即构成完整的规则说明书。因此阅读本规格的正确姿势是把 21 个输入用例当作问题集合把快照中的输出当作标准答案。下面先给出全部用例的输入原文与规格文件逐字一致再逐一对照快照输出讲解每条规则。规格输入全文21 个用例alt text alt text alt text alt text alt text alt text  alt text alt with spaces alt alt text alt   a  alt with **bold** and *italic* alt with code alt with code foo-bar) encodedfoo-%3Ebar)二、行内图片的语法结构与格式化入口在深入行为之前先建立语法层面的认知。Biome 的 Markdown 语法树把行内图片建模为MdInlineImage节点其字段定义位于 nodes.rspub struct MdInlineImageFields { pub excl_token: SyntaxResultSyntaxToken, // ! pub l_brack_token: SyntaxResultSyntaxToken, // [ pub alt: MdInlineItemList, // alt 文本行内元素列表 pub r_brack_token: SyntaxResultSyntaxToken, // ] pub l_paren_token: SyntaxResultSyntaxToken, // ( pub destination: MdInlineItemList, // 图片地址行内元素列表 pub title: OptionMdLinkTitle, // 可选标题 pub r_paren_token: SyntaxResultSyntaxToken, // ) }注意两个关键点alt 与 destination 都是MdInlineItemList行内元素列表而非普通字符串。这意味着 alt 文本内部可以嵌套行内强调**bold**、行内代码code等元素格式化时必须按行内元素而非纯文本来处理title 是可选的OptionMdLinkTitle这为空标题被删除的规则提供了类型层面的基础。对应的格式化实现是 inline_image.rs 中的FormatMdInlineImage其fmt_fields按照! [ alt ] ( destination [title] )的顺序逐段输出其中三个关键决策点分别是alt 文本以TextPrintMode::trim_all()模式打印keep_fences_in_italics: false允许在斜体场景下归一化围栏字符destination调用format_inline_destination(destination, TextPrintMode::Trim(TrimMode::AutoLinkLike))——图片地址使用AutoLinkLike风格的裁剪模式与普通链接inline_link.rs 中链接使用trim_all()存在细微差异title存在才打印不存在则跳过。三、逐条解析21 个用例的格式化行为与规则将快照Formatted段与输入逐条对照可以得到下表。这是本规格的核心成果也是本文最重要的参考表#输入格式化输出行为类别1alt textalt text常规形态原样保留2alt textalt text带标题原样保留3alt textalt text空双引号标题被移除4alt textalt text空单引号标题被移除5alt textalt text仅含空格的标题保留6alt textalt text单引号归一为双引号空格保留7空 alt 合法原样保留8alt textalt text标题内空格保留9alt with spacesalt with spacesalt 首尾空格保留10altaltdestination 首尾空白被裁剪11alt textalt textdestination 与标题间多余空格被压缩12altalt相对路径原样保留13绝对 URL 原样保留14URL 标题原样保留15aa单字符 alt destination 裁剪16长 alt 长 URL 长标题原样保留不强制换行允许超出 80 列17alt with **bold** and *italic*alt with **bold** and _italic_斜体*归一化为_18alt with \code|alt with code行内代码原样保留19alt with \code|alt with code多余的尖括号包裹被移除20foo-bar)encodedfoo-%3Ebar)括号 场景尖括号包裹 %3E编码21encodedfoo-%3Ebar)encodedfoo-%3Ebar)已编码形态保持幂等快照还额外记录了超出 80 字符最大宽度的告警段Lines exceeding max width of 80 characters其中仅用例 16 命中This is a long alt text ... And a long title too)。这说明行内图片属于不可分割的原子单元宁可超宽也不强行折行——这与链接/文本的可折行策略形成对比。下面按三个组成部分分组讲解这些行为背后的规则。3.1 规则一destination 的空白裁剪与AutolinkLike模式destination图片地址是格式化最积极的部分首尾空白一律裁剪![alt→alta→adestination 与 title 之间的多余空格被压缩为单个空格alt text→alt text无必要性的尖括号包裹被剥离alt with \code→alt with code。实现上这些行为由 inline_link.rs 的format_inline_destination统一驱动普通情况走Fallback分支以调用方传入的打印模式输出图片为Trim(TrimMode::AutoLinkLike)链接为trim_all()因此图片与链接在空白处理上会呈现细微的行为差异。3.2 规则二title 的空则删、非空则归一策略标题title规则可以概括为三句话空字符串标题直接删除无论使用双引号还是单引号只要内容为空title整体被丢弃对应语法节点中title: OptionMdLinkTitle为None的情况输出退化为alt text仅含空格的标题予以保留 与 都保留因为空标题与有内容虽然是空白在语义上被区分对待引号风格归一为双引号单引号标题 被统一改写为 含实际内容的标题如title、title with spaces、Image Title原样保留引号内空格也不做压缩。3.3 规则三alt 文本的元素级处理alt 文本是三个部分中最克制的部分普通文本 alt 原样保留包括首尾空格alt with spaces输出不变。这是有意为之的保守策略——alt 的语义边界由作者决定格式化器不做猜测性裁剪行内元素按既有规则递归格式化alt with **bold** and *italic*中加粗**bold**保持不变而斜体*italic*被归一化为_italic_。这与 inline_italic.rs 中默认偏好_、仅在邻近字母数字或嵌套斜体时使用*的围栏选择策略一致在快照输出里得到了直接印证行内代码原样保留code的内容不会被改写。3.4 规则四特殊地址的...%3E...编码与幂等保护这是本规格中实现最精巧的一条规则对应用例 20/21当 destination同时包含圆括号和裸字符时如https://www.google.fr/()foo-bar直接输出会导致与)在 Markdown 解析中被误解因此格式化器将其改写为https://www.google.fr/()foo-%3Ebar用尖括号将整个地址包裹起来并把内部的转义为百分号编码%3E若输入已经是该形态...%3E...格式化器会识别并原样保留保证重复格式化幂等性不会反复改写或退化。从源码看这一逻辑对应 inline_link.rs 中的三态枚举InlineDestinationFormatWrapAndEncode地址含括号且含裸输出...包裹 内部替换为%3EPreserveWrapped检测到已是...%3E...形态should_preserve_wrapped_encoded_destination判定首尾为/且内部含括号与%3E直接保留Fallback其余所有情况走常规格式化。值得注意的是该特殊处理仅对纯文本地址生效一旦地址中出现空格、换行、等字符或包含非纯文本的行内元素就立即回退到Fallback分支inline_link.rs 中的逐项检查避免误伤用户输入。用例 19url被剥离与用例 20/21...%3E...被保留之间的差异正是尖括号何时该去掉、何时该保留的精确分界。四、从输入到输出一次格式化发生了什么综合以上规则Biome 处理一行...的完整流程可以概括为解析biome_markdown_parser将输入解析为以MdInlineImage为节点的语法树alt 与 destination 被解析为MdInlineItemList格式化alt对 alt 列表以trim_all模式递归格式化行内元素斜体围栏按 inline_italic.rs 的策略归一化格式化destination调用format_inline_destination判断三态——需要编码则包裹并转义已编码则幂等保留否则裁剪空白后原样输出格式化title空标题节点被跳过不输出非空标题统一使用双引号输出输出按alt重组行内图片整体作为不可折行单元写入超长时宁可超过 80 列也不拆分。五、如何运行与验证这套规格如果你希望在本仓库中实际验证上述全部行为可以运行 Markdown 格式化器的规格测试cargo test -p biome_markdown_formatter其中tests/specs/markdown/**/*.md下的每个文件都会被自动注册为独立用例见 spec_tests.rs。针对本文主题可单独过滤cargo test -p biome_markdown_formatter inline_image运行后inline_image.md的输入会被格式化并与 inline_image.md.snap 中的期望输出比对任何行为变化都会导致快照不一致而暴露出来。这也是 Biome 保证格式化规则稳定、可回归的核心手段每一个格式化决策都有对应的输入用例与快照背书。六、小结通过 inline_image.md 这 21 个用例可以提炼出 Biome 行内图片格式化的四条核心设计哲学分层克制alt 文本最保守保留作者原样与内部元素规则destination 最积极裁剪空白、剥离冗余尖括号title 居中删空、归一双引号语义优先空标题与空白标题被区分对待避免格式化破坏作者的语义意图正确性优先于美观对含括号与的地址主动编码以保证语法正确同时通过PreserveWrapped保证幂等原子不可拆行内图片整体不换行宁可超出 80 列约束。这套规则既有快照层面的完整行为定义又有 inline_image.rs 与 inline_link.rs 的源码实现支撑是理解 Biome Markdown 格式化器输入—规则—输出链路的最佳入门样本。【免费下载链接】biomeA toolchain for web projects, aimed to provide functionalities to maintain them. Biome offers formatter and linter, usable via CLI and LSP.项目地址: https://gitcode.com/gh_mirrors/bi/biome创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考