参考

JSON Schema 词汇表

本文档收集了 JSON Schema 社区中可能会遇到的术语的简短解释。

虽然以下许多条目都有精确的技术定义，但更倾向于解释它们在对话中的用法，并链接附加参考以获取更多信息。此页面并非规范性的，也不是为了包含完全原创的研究或解释。它旨在帮助那些不太熟悉 JSON Schema 或更广泛规范中使用的正式语言的人理解。 (事实上，以下条目努力避免使用像“规范性”这样的术语，原因正如上面提到的。）

如果您遇到希望在此定义的术语，请随时提交问题请求它。

此页面上的条目可以通过锚链接（例如 https://json-schema.fullstack.org.cn/learn/glossary.html#vocabulary）链接，以便在与他人分享定义时使用。

方言

一个内聚的关键字集合，可在模式中使用，通常代表 JSON Schema 规范的特定用例的单个发布。

方言，特别是 2019-09 和 2020-12 方言，通常通过一系列词汇表定义。

每个方言都由一个 URI 标识，即其方言标识符，模式可以将其引用在它们的 $schema 关键字中。这样做将模式标识为用该方言编写，并因此指示该方言中可以使用哪些关键字以及它们的预期含义。

JSON Schema 规范定义了许多方言，每种方言都支持适合方言特定用例的词汇表。这些词汇表在元模式中描述。

草案

JSON Schema 规范的单个版本。

JSON Schema 草案并非旨在作为临时文档，正如外行人对“草案”一词的理解。

虽然未来的草案可能会引入新的行为或对现有行为进行更改，但每个草案都是一个完整的、已发布的文档，将规范更改汇集在一起，并旨在实施和使用。

当前草案列表可以在此处找到。

JSON

一种普遍存在的数据交换格式，用于将数据表示和传输为人类可读的文本。JSON 被广泛使用，并且对于几乎所有常用的编程语言，都存在可以读取和写入它的解析器。

JSON Schema 不同的是，它构建在 JSON 之上，即 JSON 模式本身是 JSON 对象，用于描述 JSON 值。然而，这两个是概念谜题中完全不同的部分，JSON 是用于表示数据的具体格式，而 JSON Schema 是一种模式化以 JSON 兼容格式编写的数据的方式。

JSON 格式是一种开放格式，它有自己的主页，并且规范发布在 ECMA 和 IETF 的 ECMA-404 和 RFC-8259 文档中。特别是，它不是由 JSON Schema 团队管理或开发的，他们只是利用了这种格式。

JSON 超级模式

JSON 超级模式扩展了 JSON Schema，提供了一个词汇表来用超媒体控件注释 JSON 文档。这种扩展有助于描述可以在 JSON 数据上执行的链接和操作，使其成为开发超媒体驱动 API 的强大工具。

JSON 超级模式的核心在于它能够定义链接和操作，这些链接和操作可以在 JSON 数据上执行。这是通过使用 links 关键字实现的，该关键字允许创建动态的交互式数据表示。例如，一个表示博客文章的 JSON 文档可能包含一个“author”属性。描述该文档的 JSON 超级模式可以包含一个超媒体控件的模板，该模板使用实例中的作者标识符来构造指向作者个人资料的链接。开发人员无需手动构建 URL，这通过提供无缝导航体验来增强开发人员体验。

换句话说，JSON 超级模式通过引入创建超媒体控件的功能扩展了 JSON 模式。这有助于创建交互式 API，并确保与现有的 JSON HTTP API 兼容，从而保持无缝集成。它为 JSON 文档添加了一层交互性，使与远程 JSON 资源的交互变得更加容易。

JSON 指针

JSON 指针是一种字符串语法，用于标识 JSON 文档中指定位置的值。它用于精确地引用文档的特定部分以进行检索或操作。子模式通常使用 JSON 指针进行标识，以指定其在包含资源中的位置。

关键字

出现在模式对象中的属性。

JSON 模式规范定义了大量关键字的行为，这些关键字可以用于描述实例。

实现

历史上，“实现”一词一直被用来描述验证器/注释器（规范的范围）以及其他各种 JSON 模式工具。但是，由于这种歧义，我们已经决定首选的对话术语应该是 “工具”。

实例

要由模式描述的 JSON 数据片段。

JSON 模式可用于描述任何类型（以及可以合理地表示为 JSON 的许多 JSON 类格式的值）的 JSON 值。

JSON 模式规范对实例本身的结构没有做出任何广泛的假设，除了 JSON 规范本身的那些假设之外。特别是，它不会在 JSON 对象中为其自身保留任何属性，也不会要求 JSON 解析器支持超出 JSON 实现已强制执行的那些功能。

元模式

旨在描述其他模式的模式。

JSON 模式定义了一种语言，可以使用 JSON 编写的模式来描述任何实例。由于模式本身是 JSON 值，因此它们也可以被视为实例，因此可以通过其他模式进行描述。

我们称模式的模式为“元模式”来表达这种用法。

规范性

在 JSON 模式以及更广泛的正式规范的上下文中，概述标准化行为的文档。这不同于非规范性或信息性文档，这些文档旨在解释、简化或提供意见。

区分文档是否规范性旨在向使用文档的人员明确说明其内容是否允许与其他规范性文档中描述的行为相矛盾或对其进行补充。JSON 模式的规范性文档尤其包括其规范。例如，本页不是规范性文档，因此不能规定规范中未涵盖的新的 JSON 模式行为。

另请参阅

规范性和非规范性在 Mozilla 词汇表中，以及其链接

模式

根据 JSON 模式规范规定的结构编写的文档，可用于描述实例。

构成哪些模式符合以及在验证实例时控制其行为的规则由 JSON 模式规范定义。

严格来说，根据规范，模式本身是 JSON 文档，尽管它们通常是用其他语言（例如 YAML）编写或维护的，这些语言很容易转换为 JSON。

在规范的最新草案中，模式要么是 JSON 对象，要么是 JSON 布尔值。

子模式

本身包含在周围父模式中的模式。就像模式本身一样，在 JSON 模式的最新草案中，子模式要么是 JSON 对象，要么是 JSON 布尔值。

在 JSON 模式规范及其方言中，许多关键字将子模式作为其值的一部分。例如，not 关键字采用子模式值并反转其结果，只要子模式不成功，它就会成功，这样实例 12 在 {"type": "string"} 下无效，但在 {"not": {"type": "string"}} 下有效，其中 {"type": "string"} 是包含在完整模式中的子模式。

一些子模式可能出现在父模式中更复杂的嵌套位置。例如，allOf 关键字接受多个子模式的数组，只要所有子模式都单独成功，它就会成功。

如果某样东西看起来像一个模式（基于其内容），但实际上是一个子模式，乍一看可能会让人误解，因为没有上下文或了解它在父模式中的位置。具体来说，在我们上面的示例中，{"type": "string"} 是一个更大模式的子模式，但在模式 {"const": {"type": "string"}} 中，它不是子模式。即使作为值，它看起来相同，但 const 关键字（将实例与特定预期值进行比较）不接受子模式作为其值，其值是一个不透明的值，没有特定的含义（这样在这个模式中，数字 12 将是无效的，但精确的实例 {"type": "string"} 是有效的）。更简单地说，特定值是否是子模式取决于它在父模式中的确切位置，因为值的解释取决于它所处的关键字的行为。

子模式本身可以包含子子模式，尽管口头上通常无论嵌套级别如何都使用“子模式”一词，并在需要时进一步澄清哪个更大的模式是父模式。