Markdown spec.txt中GFM的交叉引用是如何工作的？ 序曲

在报告中，据说：

本文档由一个文本文件spec.txt生成，该文件以Markdown编写，带有一个小扩展名，用于并行测试。脚本工具/makespec.py可用于将spec.txt转换为HTML或CommonMark，然后再将其转换为其他格式

我找不到包含这些文件的公共存储库，但可以在同一网站下找到 目录作为规范本身。这不是我的主要问题，但如果有人能指出一个正式维护这些文件的存储库，我会很高兴

主要假设 根据上面的引文，我假设中的所有代码，除了用于并行测试的代码之外，都是合法的GFM

主要问题 在中，有以下代码：

## Characters and lines

Any sequence of [characters] is a valid CommonMark
document.

A [character](@) is a Unicode code point.  Although some
code points (for example, combining accents) do not correspond to
characters in an intuitive sense, all code points count as characters
for purposes of this spec.

在中，链接[字符]和链接[字符]@已转换为此交叉引用链接：

https://github.github.com/gfm/#character

---

该语法是否在GFM中实现了交叉引用（也称为命名锚）？有一个例子表明，不存在针对交叉引用的纯标记解决方案-但是，如果这种基于@的语法是在解析spec.txt的解析器中实现的，为什么不在spec中指定呢

Commonmark规范的官方回购协议可在其他回购协议的副本中找到，其他回购协议从此处复制。我们可以看到，该repo中的spec.txt文件也具有相同的语法。因此，这不是特定于GFM，而是通用标志，GFM是通用标志的扩展

如spec.txt文件中以及其他地方所述：

注意：这不是一个独立的commonmark文件。它是在一个特殊的地方 设计用于使用工具/make_spec.lua处理的格式

事实上，如果我们查看repo，我们会发现它是一个包装器脚本，它在以多种支持的格式之一输出spec之前对spec.txt文件进行预处理。请注意，其中一种输出格式是Commonmark。如果您以commonmark作为输出格式运行脚本，您将得到一个带有常规commonmark链接的commonmark文档，而不是特殊语法。事实上，如果您不在tools/make_spec.lua中进行预处理，直接将spec.txt文件馈送到Commonmark，您将无法得到一个包含正确格式链接的文档。因此，我们可以得出结论，所讨论的语法不是Commonmark，而是一些仅用于编写规范的自定义插件。这可以解释为什么规范中没有指定它

---

不幸的是，我在任何地方都找不到关于语法如何工作的任何文档。该规范的示例简要介绍了该规范中使用的特殊代码块语法，但没有涉及内部链接。

Github为其扩展版Commonmark的代码托管在。有趣的是，该回购协议的有效性引起了人们的担忧，即该协议的内容不存在公开回购协议。但是，github/cmark gfm repo中有一个的副本。我刚刚检查了，中的非扩展Commonmark实现也包含相同的语法。因此，这不是特定于GFM，而是一般的Commonmark。感谢您的关注。这是很有道理的，尽管我希望有一个秘密的GFM/CommonMark规范用于交叉引用；-。