| 互联网工程任务组 | A. Wright，编辑 |
| 互联网草案 | |
| 预期状态：信息性 | H. Andrews，编辑 |
| 过期时间：2018 年 9 月 20 日 | Cloudflare，Inc. |
| G. Luff | |
| 2018 年 3 月 19 日 |
JSON Schema 验证：JSON 结构验证的词汇表
draft-handrews-json-schema-validation-01
JSON Schema（application/schema+json）有多种用途，其中之一是 JSON 实例验证。本文档指定了 JSON Schema 的词汇表，用于描述 JSON 文档的含义，为处理 JSON 数据的用户界面提供提示，并对有效文档的外观做出断言。
此草案的问题列表可在 <https://github.com/json-schema-org/json-schema-spec/issues> 找到。
有关更多信息，请参阅 <https://json-schema.fullstack.org.cn/>。
要提供反馈，请使用此问题跟踪器，主页上列出的通信方式，或发送电子邮件给文档编辑。
此互联网草案完全符合 BCP 78 和 BCP 79 的规定提交。
互联网草案是互联网工程任务组 (IETF) 的工作文档。请注意，其他组也可能以互联网草案的形式分发工作文档。当前互联网草案的列表位于 http://datatracker.ietf.org/drafts/current/。
互联网草案是有效期最长为六个月的草案文档，可能随时被其他文档更新、替换或废弃。互联网草案不适合作为参考材料或引用，除非作为“正在进行的工作”。
此互联网草案将于 2018 年 9 月 20 日过期。
版权所有 (c) 2018 IETF 信托和被识别为文档作者的人员。保留所有权利。
本文档受 BCP 78 和 IETF 信托的《与 IETF 文档相关的法律条款》（http://trustee.ietf.org/license-info）约束，该条款在本文档发布之日生效。请仔细阅读这些文档，因为它们描述了您对本文档的权利和限制。从本文档中提取的代码组件必须包含简化 BSD 许可证文本，如信托法律条款第 4.e 节所述，并且按简化 BSD 许可证中所述的方式提供，不提供任何担保。
JSON Schema 可用于要求给定的 JSON 文档（实例）满足一定数量的标准。这些标准是通过使用本规范中描述的关键字断言的。此外，还定义了一组关键字来帮助交互式用户界面实例生成。
本规范将使用 JSON Schema 核心 [json-schema] 规范中定义的概念、语法和术语。
本文档中的关键术语“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“可以”和“可选”应按 RFC 2119 [RFC2119] 中的描述进行解释。
本规范使用术语“容器实例”来指代数组和对象实例。它使用术语“子实例”来指代数组元素或对象成员的值。
数组值中的元素被称为唯一，如果该数组的任何两个元素都不 相等 [json-schema]。
JSON Schema 验证将模式应用于实例中的位置，并对每个位置的数据结构做出约束。满足所有断言约束的实例位置将用包含非断言信息的任何关键字进行注释，例如描述性元数据和使用提示。如果实例中的所有位置都满足所有断言约束，则该实例被称为对该模式有效。
每个模式对象独立地针对它应用到的每个实例位置进行评估。这极大地简化了验证器的实现要求，确保它们不需要在整个文档范围的验证过程中维护状态。
验证从将根模式应用于完整的实例文档开始。从那里，各种关键字用于确定哪些额外的子模式被应用于当前位置或子位置。这些关键字还定义了是否以及如何修改和/或组合子模式断言结果。此类关键字本身不断言条件。相反，它们控制断言如何应用和评估。
本规范的 布尔逻辑 [logic] 和 条件 [conditional] 部分中的关键字将子模式应用于与父模式相同的位置。前一组定义了对子模式断言结果的布尔运算，而后一组则评估一个子模式，并使用其断言结果来确定要应用的另外两个子模式中的哪一个。
几个关键字确定哪些子模式被应用于数组项、对象属性值和对象属性名。它们是：“items”、“additionalItems”、“contains”、“properties”、“patternProperties”、“additionalProperties”和“propertyNames”。“contains”关键字只需要其子模式对至少一个子实例有效，而其他关键字则要求所有子模式对所有应用的子实例有效。
验证关键字通常独立运行，不会影响彼此的结果。
为了方便模式作者，控制子模式适用性的关键字之间存在一些例外。
验证是一个检查断言的过程。每个断言都添加了实例必须满足的约束才能成功验证。
不存在的断言关键字永远不会限制验证。在某些情况下，这种无操作行为与存在具有某些值的关键字相同，并且在已知的情况下会注明这些值。
一般 [general]、数值 [numeric] 和 字符串 [string] 部分中的所有关键字都是断言，以及 "minItems"、"maxItems"、"uniqueItems"、"minProperties"、"maxProperties" 和 "required"。此外，“dependencies”是条件和断言关键字组合的简写。
“format”、“contentType”和“contentEncoding”关键字也可以作为断言实现，尽管该功能是本规范的可选部分，并且这些关键字传递了额外的非断言信息。
大多数验证断言只约束某个基本类型中的值。当实例的类型不是关键字目标的类型时，该实例被认为符合断言。
例如，“maxLength”关键字将仅限制某些字符串（太长）有效。如果实例是数字、布尔值、空值、数组或对象，那么它对该断言有效。
除了断言之外，本规范还提供了一些元数据关键字词汇，这些关键字可用于用有用信息注释 JSON 实例。第 7 节 和 第 8 节 中的关键字也作为注释和可选断言很有用，因为它们传达了实例数据的额外使用指南。
一个适用于实例中特定位置的模式，根据该模式验证实例位置，将它的注释附加到实例中的该位置。由于多个子模式可以适用于任何单个位置，因此注释关键字需要指定对关键字在不同值下出现多次的任何非寻常处理方式。默认行为是简单地收集所有值。
附加词汇表 SHOULD 使用此机制将其自身的注释应用于实例。
只要实例相对于模式对象及其所有父模式有效，就会收集注释。
特别地，任何深度（包括任何数量的中间附加 “not” 子模式）中包含在 “not” 中的子模式中的注释 MUST 被忽略。如果实例相对于 “not” 子模式有效，那么根据定义它相对于包含 “not” 的模式无效，因此不使用 “not” 子模式的注释。
类似地，即使实例成功验证通过完整的模式文档，在 “oneOf”、 “anyOf”、 “then” 或 “else” 的失败分支内的注释 MUST 被忽略。
注释关键字 MUST 应用于所有可能的子实例。即使这种应用可以在仅需要断言评估时短路。例如， “contains” 关键字只需要检查断言，直到至少一个数组项被证明有效。但是，在处理注释时，必须评估数组中的所有项以确定应将注释与哪些项关联。
需要注意的是，空字符 (\u0000) 在 JSON 字符串中是有效的。要验证的实例可能包含具有此字符的字符串值，而不管底层编程语言是否能够处理此类数据。
JSON 规范允许使用任意精度的数字，JSON Schema 不会添加任何此类边界。这意味着由 JSON Schema 处理的数字实例可以任意大，或具有任意长的十进制部分，而不管底层编程语言是否能够处理此类数据。
两个验证关键字 “pattern” 和 “patternProperties” 使用正则表达式来表达约束， “format” 关键字的 “regex” 值将实例值约束为正则表达式。这些正则表达式 SHOULD 符合 ECMA 262 [ecma262] 正则表达式方言。
此外，鉴于正则表达式结构支持存在很大差异，模式作者 SHOULD 将自己限制在以下正则表达式标记中
最后，实现 MUST NOT 将正则表达式视为锚定，无论是开头还是结尾。这意味着，例如，模式 “es” 匹配 “expression”。
JSON Schema 验证的当前 URI 是 <https://json-schema.fullstack.org.cn/draft-07/schema#>.
模式中的验证关键字对实例的成功验证施加要求。
此关键字的值 MUST 是字符串或数组。如果它是数组，则数组的元素 MUST 是字符串，并且 MUST 是唯一的。
字符串值 MUST 是六种基本类型之一（“null”、 “boolean”、 “object”、 “array”、 “number” 或 “string”），或 “integer”，它匹配任何具有零小数部分的数字。
当且仅当实例位于此关键字列出的任何集合中时，实例才验证。
此关键字的值 MUST 是一个数组。此数组 SHOULD 至少包含一个元素。数组中的元素 SHOULD 是唯一的。
如果实例的值等于此关键字的数组值中的一个元素，则实例成功验证通过此关键字。
数组中的元素可能是任何值，包括 null。
此关键字的值 MAY 是任何类型，包括 null。
如果实例的值等于关键字的值，则实例成功验证通过此关键字。
“multipleOf” 的值 MUST 是一个严格大于 0 的数字。
数字实例仅当被此关键字的值除后结果为整数时才有效。
“maximum” 的值 MUST 是一个数字，表示数字实例的包含上限。
如果实例是一个数字，则此关键字仅在实例小于或等于 “maximum” 时才验证。
“exclusiveMaximum” 的值 MUST 是一个数字，表示数字实例的排除上限。
如果实例是一个数字，则实例仅当它的值严格小于（不等于） “exclusiveMaximum” 时才有效。
“minimum” 的值 MUST 是一个数字，表示数字实例的包含下限。
如果实例是一个数字，则此关键字仅在实例大于或等于 “minimum” 时才验证。
“exclusiveMinimum” 的值 MUST 是一个数字，表示数字实例的排除下限。
如果实例是一个数字，则实例仅当它的值严格大于（不等于） “exclusiveMinimum” 时才有效。
此关键字的值 MUST 是一个非负整数。
如果字符串实例的长度小于或等于此关键字的值，则它相对于此关键字有效。
字符串实例的长度定义为其字符的数量，如 RFC 7159 [RFC7159] 所定义。
此关键字的值 MUST 是一个非负整数。
如果字符串实例的长度大于或等于此关键字的值，则它相对于此关键字有效。
字符串实例的长度定义为其字符的数量，如 RFC 7159 [RFC7159] 所定义。
省略此关键字与值为 0 的行为相同。
此关键字的值 MUST 是一个字符串。此字符串 SHOULD 是一个有效的正则表达式，符合 ECMA 262 正则表达式方言。
如果正则表达式成功匹配实例，则字符串实例被认为有效。回想一下：正则表达式不会隐式地锚定。
“items” 的值 MUST 是一个有效的 JSON Schema 或一个有效的 JSON Schema 数组。
此关键字决定数组中子实例如何验证，并且不会直接验证直接实例本身。
如果 “items” 是一个模式，则当数组中的所有元素成功验证通过该模式时，验证成功。
如果 “items” 是一个模式数组，则如果实例的每个元素都验证通过与它在同一位置的模式（如果有）验证通过，则验证成功。
省略此关键字与空模式的行为相同。
“additionalItems” 的值 MUST 是一个有效的 JSON Schema。
此关键字决定数组中子实例如何验证，并且不会直接验证直接实例本身。
如果 “items” 是一个模式数组，则如果每个位置大于 “items” 大小的实例元素都验证通过 “additionalItems”，则验证成功。
否则， “additionalItems” MUST 被忽略，因为 “items” 模式（可能是空模式的默认值）应用于所有元素。
省略此关键字与空模式的行为相同。
此关键字的值 MUST 是一个非负整数。
如果数组实例的大小小于或等于此关键字的值，则它相对于 “maxItems” 有效。
此关键字的值 MUST 是一个非负整数。
如果数组实例的大小大于或等于此关键字的值，则它相对于 “minItems” 有效。
省略此关键字与值为 0 的行为相同。
此关键字的值 MUST 是一个布尔值。
如果此关键字的布尔值为 false，则实例成功验证通过。如果它具有布尔值 true，则如果实例的所有元素都是唯一的，则实例成功验证通过。
省略此关键字与值为 false 的行为相同。
此关键字的值 MUST 是一个有效的 JSON Schema。
如果数组实例的至少一个元素验证通过给定的模式，则它相对于 “contains” 有效。
此关键字的值 MUST 是一个非负整数。
如果对象实例的属性数量小于或等于此关键字的值，则它相对于 “maxProperties” 有效。
此关键字的值 MUST 是一个非负整数。
如果对象实例的属性数量大于或等于此关键字的值，则它相对于 “minProperties” 有效。
省略此关键字与值为 0 的行为相同。
此关键字的值 MUST 是一个数组。此数组的元素（如果有） MUST 是字符串，并且 MUST 是唯一的。
如果数组中的每一项都是实例中属性的名称，则对象实例相对于此关键字有效。
省略此关键字与空数组的行为相同。
“properties” 的值 MUST 是一个对象。此对象的每个值 MUST 是一个有效的 JSON Schema。
此关键字决定对象中子实例如何验证，并且不会直接验证直接实例本身。
如果对于同时出现在实例中和作为此关键字的值中的名称的每个名称，该名称的子实例都成功验证通过相应的模式，则验证成功。
省略此关键字与空对象的行為相同。
“patternProperties” 的值 MUST 是一个对象。此对象的每个属性名称 SHOULD 是一个有效的正则表达式，符合 ECMA 262 正则表达式方言。此对象的每个属性值 MUST 是一个有效的 JSON Schema。
此关键字决定对象中子实例如何验证，并且不会直接验证直接实例本身。原始实例类型相对于此关键字的验证始终成功。
如果对于每个与作为此关键字的值中的属性名称出现的任何正则表达式匹配的实例名称，该名称的子实例都成功验证通过与匹配正则表达式相对应的每个模式，则验证成功。
省略此关键字与空对象的行為相同。
“additionalProperties” 的值 MUST 是一个有效的 JSON Schema。
此关键字决定对象中子实例如何验证，并且不会直接验证直接实例本身。
使用 “additionalProperties” 的验证仅应用于实例名称的子值，这些名称与 “properties” 中的任何名称不匹配，也不与 “patternProperties” 中的任何正则表达式匹配。
对于所有此类属性，如果子实例验证通过 “additionalProperties” 模式，则验证成功。
省略此关键字与空模式的行为相同。
如果实例是对象并且包含某个属性，则此关键字指定要评估的规则。
此关键字的值必须是一个对象。每个属性都指定了一个依赖项。每个依赖项值必须是一个数组或有效的 JSON Schema。
如果依赖项值是一个子模式，并且依赖项键是实例中的一个属性，则整个实例必须根据依赖项值进行验证。
如果依赖项值是一个数组，则数组中的每个元素（如果有）必须是一个字符串，并且必须是唯一的。如果依赖项键是实例中的一个属性，则依赖项值中的每个项都必须是实例中存在的属性。
省略此关键字与空对象的行為相同。
"propertyNames" 的值必须是一个有效的 JSON Schema。
如果实例是一个对象，则此关键字验证实例中的每个属性名称是否根据提供的模式进行验证。请注意，模式正在测试的属性名称始终是一个字符串。
省略此关键字与空模式的行为相同。
这些关键字协同工作，以根据另一个子模式的结果来实现子模式的条件应用。
这些关键字必须不跨越子模式边界相互交互。换句话说，一个 "allOf" 分支中的 "if" 必须不影响另一个分支中的 "then" 或 "else"。
当这些关键字不存在时，它们没有任何默认行为。特别是，它们必须不视为存在于空模式中，并且当 "if" 不存在时，"then" 和 "else" 必须被完全忽略。
此关键字的值必须是一个有效的 JSON Schema。
此关键字的子模式的验证结果对整体验证结果没有直接影响。相反，它控制评估 "then" 或 "else" 关键字中的哪一个。
成功根据此关键字的子模式进行验证的实例也必须根据 "then" 关键字的子模式值进行验证（如果存在）。
未能根据此关键字的子模式进行验证的实例也必须根据 "else" 关键字的子模式值进行验证（如果存在）。
如果正在收集 注释 [annotations]，则它们将以通常的方式从此关键字的子模式中收集，包括当关键字存在但没有 "then" 或 "else" 时。
此关键字的值必须是一个有效的 JSON Schema。
当 "if" 存在并且实例成功根据其子模式进行验证时，如果实例也成功根据此关键字的子模式进行验证，则针对此关键字的验证将成功。
当 "if" 不存在，或实例未能根据其子模式进行验证时，此关键字无效。在这种情况下，实现必须不针对此关键字评估实例，无论是出于验证还是注释收集目的。
此关键字的值必须是一个有效的 JSON Schema。
当 "if" 存在并且实例未能根据其子模式进行验证时，如果实例成功根据此关键字的子模式进行验证，则针对此关键字的验证将成功。
当 "if" 不存在，或实例成功根据其子模式进行验证时，此关键字无效。在这种情况下，实现必须不针对此关键字评估实例，无论是出于验证还是注释收集目的。
此关键字的值必须是一个非空数组。数组中的每个项必须是一个有效的 JSON Schema。
如果实例成功根据此关键字值定义的所有模式进行验证，则它会成功根据此关键字进行验证。
此关键字的值必须是一个非空数组。数组中的每个项必须是一个有效的 JSON Schema。
如果实例成功根据此关键字值定义的至少一个模式进行验证，则它会成功根据此关键字进行验证。
此关键字的值必须是一个非空数组。数组中的每个项必须是一个有效的 JSON Schema。
如果实例成功根据此关键字值定义的恰好一个模式进行验证，则它会成功根据此关键字进行验证。
此关键字的值必须是一个有效的 JSON Schema。
如果实例未能成功根据此关键字定义的模式进行验证，则它会根据此关键字进行验证。
仅进行结构验证可能不足以验证实例是否满足应用程序的所有要求。定义了 "format" 关键字以允许对由权威资源（无论是 RFC 还是其他外部规范）准确描述的固定值子集进行可互操作的语义验证。
此关键字的值称为格式属性。它必须是一个字符串。格式属性通常只能验证给定的一组实例类型。如果要验证的实例的类型不在此集中，则此格式属性和实例的验证应成功。
"format" 关键字既充当注释（第 3.3 节），也充当断言（第 3.2 节）。虽然无需特别努力将其作为传达语义含义的注释来实现，但实现验证并非易事。
实现可以将 "format" 关键字作为验证断言来支持。如果它们选择这样做，
实现可以添加自定义格式属性。除了各方之间的协议外，模式作者不应期望对等实现支持此关键字和/或自定义格式属性。
这些属性适用于字符串实例。
日期和时间格式名称源自 RFC 3339，第 5.6 节 [RFC3339]。
支持格式的实现应实现对以下属性的支持
实现可以使用该部分中定义的其他产生式名称来支持其他属性。如果实现了 "full-date" 或 "full-time"，则必须实现相应的简短形式（分别为 "date" 或 "time"），并且必须具有相同的行为。实现不应定义任何名称与 RFC 3339 产生式匹配的扩展属性，除非它根据该产生式的规则进行验证。 [CREF2]目前尚无关于是否需要支持所有 RFC 3339 格式的共识，因此这种保留命名空间的方法将鼓励尝试，而不会承诺使用整个集合。格式实现要求将变得更加灵活，或者这些要求可能会被提升为完全指定的属性，或者被删除。
这些属性适用于字符串实例。
如果字符串实例是有效的互联网电子邮件地址，如下所示，则它会根据这些属性进行验证
请注意，所有根据 "email" 属性验证的字符串也根据 "idn-email" 属性验证。
这些属性适用于字符串实例。
如果字符串实例是有效的互联网主机名的表示形式，如下所示，则它会根据这些属性进行验证
请注意，所有根据 "hostname" 属性验证的字符串也根据 "idn-hostname" 属性验证。
这些属性适用于字符串实例。
如果字符串实例是 IP 地址的有效表示形式，如下所示，则它会根据这些属性进行验证
这些属性适用于字符串实例。
请注意，所有有效的 URI 都是有效的 IRI，所有有效的 URI 引用也是有效的 IRI 引用。
此属性适用于字符串实例。
如果字符串实例是有效的 URI 模板（任何级别），根据 [RFC6570] 进行验证，则它会根据此属性进行验证。
请注意，URI 模板可用于 IRI；没有单独的 IRI 模板规范。
这些属性适用于字符串实例。
为了允许使用绝对和相对 JSON 指针，请使用 "anyOf" 或 "oneOf" 来指示对任一格式的支持。
此属性适用于字符串实例。
正则表达式，它应该根据 ECMA 262 [ecma262] 正则表达式方言进行验证。
验证格式的实现必须至少接受此规范的 正则表达式 [regexInterop] 部分中定义的 ECMA 262 子集，并且应接受所有有效的 ECMA 262 表达式。
本节中定义的属性表明实例包含以 JSON 字符串编码的非 JSON 数据。它们描述了内容类型及其编码方式。
这些属性提供了将 JSON 数据解释为丰富的多媒体文档所需的额外信息。
内容关键字既充当注释（第 3.3 节）又充当断言（第 3.2 节）。虽然将它们作为注释来实现，以传达应用程序如何解释字符串中的数据并不需要特殊努力，但实现对媒体类型和编码的一致性验证并非易事。
实现可以支持“contentMediaType”和“contentEncoding”关键字作为验证断言。如果它们选择这样做，它们应该提供一个选项来禁用对这些关键字的验证。
如果实例值为字符串，则此属性定义该字符串应解释为二进制数据，并使用此属性命名的编码进行解码。 RFC 2045，第 6.1 节 [RFC2045] 列出了此属性的可能值。
此属性的值必须是字符串。
如果所描述的实例不是字符串，则应忽略此属性的值。
此属性的值必须是媒体类型，如 RFC 2046 [RFC2046] 中定义。此属性定义此模式定义的实例的媒体类型。
此属性的值必须是字符串。
如果所描述的实例不是字符串，则应忽略此属性的值。
如果“contentEncoding”属性不存在，但实例值为字符串，则此属性的值应指定文本文档类型，字符集应为将 JSON 字符串值解码为的字符集（默认值为 Unicode）。
以下是一个示例模式，说明了“contentEncoding”和“contentMediaType”的使用。
{
"type": "string",
"contentEncoding": "base64",
"contentMediaType": "image/png"
}
此模式描述的实例应为字符串，它们的值应可解释为 base64 编码的 PNG 图像。
另一个例子
{
"type": "string",
"contentMediaType": "text/html"
}
此模式描述的实例应为包含 HTML 的字符串，使用将 JSON 字符串解码到的任何字符集（默认值为 Unicode）。
“definitions”关键字为模式作者提供了一个标准位置，用于将可重用 JSON 模式内联到更通用的模式中。此关键字不会直接影响验证结果。
此关键字的值必须是对象。此对象的每个成员值都必须是有效的 JSON 模式。
{
"type": "array",
"items": { "$ref": "#/definitions/positiveInteger" },
"definitions": {
"positiveInteger": {
"type": "integer",
"exclusiveMinimum": 0
}
}
}
例如，以下是一个描述正整数数组的模式，其中正整数约束是“definitions”中的子模式。
模式验证是使用附加信息注释实例数据的一种有用机制。确定何时以及如何将注释与实例关联的规则在 第 3.3 节 中概述。
这些通用注释关键字提供了用于文档和用户界面显示目的的常用信息。它们不打算形成一套全面的功能。相反，可以为更复杂的基于注释的应用程序定义其他词汇表。
这两个关键字的值必须是字符串。
这两个关键字都可以用来用有关此用户界面生成的数据的信息来装饰用户界面。标题最好简短，而描述将提供有关此模式描述的实例目的的解释。
对此关键字的值没有限制。当此关键字的多个出现适用于单个子实例时，实现应该删除重复项。
此关键字可用于提供与特定模式关联的默认 JSON 值。建议默认值对关联的模式有效。
这些关键字的值必须是布尔值。当这些关键字的多个出现适用于单个子实例时，如果任何出现指定了 true 值，则结果值必须为 true，否则必须为 false。
如果“readOnly”的值为布尔值 true，则表示实例的值完全由拥有者管理，应用程序尝试修改此属性的值预计会被拥有者忽略或拒绝。
如果整个文档被标记为“readOnly”，则发送到拥有者的实例文档可能会被忽略，也可能会导致错误，这取决于拥有者的决定。
如果“writeOnly”的值为布尔值 true，则表示当从拥有者检索实例时，该值永远不会出现。它可以在发送到拥有者以更新或创建文档（或它所代表的资源）时出现，但它不会包含在任何更新的或新创建的实例版本中。
如果整个文档被标记为“writeOnly”，则返回的实例文档可能是某种空白文档，也可能会在检索时产生错误，或者检索请求会被忽略，这取决于拥有者的决定。
例如，“readOnly”将用于将数据库生成的序列号标记为只读，而“writeOnly”将用于将密码输入字段标记为只读。
这些关键字可以用来帮助用户界面实例生成。特别是，应用程序可以选择使用一个小部件，该小部件在用户键入时隐藏只写字段的输入值。
省略这些关键字的行为与 false 的值相同。
此关键字的值必须是数组。对数组中的值没有限制。当此关键字的多个出现适用于单个子实例时，实现必须提供所有值的扁平数组，而不是数组的数组。
此关键字可用于提供与特定模式关联的示例 JSON 值，以说明用法。建议这些值对关联的模式有效。
实现可以将“default”的值（如果存在）用作附加示例。如果“examples”不存在，则“default”仍然可以以这种方式使用。
JSON 模式验证定义了 JSON 模式核心的词汇表，并涉及到那里列出的所有安全注意事项。
JSON 模式验证允许使用正则表达式，正则表达式有许多不同的（通常不兼容的）实现。一些实现允许嵌入任意代码，这超出了 JSON 模式的范围，并且不应允许。正则表达式通常也可以被设计成计算起来非常昂贵（使用所谓的“灾难性回溯”），从而导致拒绝服务攻击。
支持根据“contentEncoding”和/或“contentMediaType”验证或以其他方式评估实例字符串数据的实现，存在根据误导性信息以不安全的方式评估数据的风险。应用程序可以通过仅在建立模式和实例之间的关系（例如，它们共享相同的权限）时执行此类处理来缓解这种风险。
处理媒体类型或编码受该媒体类型或编码的安全注意事项的约束。例如，RFC 4329 脚本媒体类型 [RFC4329] 的安全注意事项适用于处理 JSON 字符串中编码的 JavaScript 或 ECMAScript。
| [RFC2119] | Bradner, S., "RFC 中用于指示需求级别的关键字", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997 年 3 月。 |
| [RFC1034] | Mockapetris, P., "域名 - 概念和设施", STD 13, RFC 1034, DOI 10.17487/RFC1034, 1987 年 11 月。 |
| [RFC2045] | Freed, N. 和 N. Borenstein, "多用途互联网邮件扩展 (MIME) 第一部：互联网消息正文的格式", RFC 2045, DOI 10.17487/RFC2045, 1996 年 11 月。 |
| [RFC2046] | Freed, N. 和 N. Borenstein, "多用途互联网邮件扩展 (MIME) 第二部：媒体类型", RFC 2046, DOI 10.17487/RFC2046, 1996 年 11 月。 |
| [RFC2673] | Crawford, M., "域名系统中的二进制标签", RFC 2673, DOI 10.17487/RFC2673, 1999 年 8 月。 |
| [RFC3339] | Klyne, G. 和 C. Newman, "互联网上的日期和时间：时间戳", RFC 3339, DOI 10.17487/RFC3339, 2002 年 7 月。 |
| [RFC3986] | Berners-Lee, T., Fielding, R. 和 L. Masinter, "统一资源标识符 (URI)：通用语法", STD 66, RFC 3986, DOI 10.17487/RFC3986, 2005 年 1 月。 |
| [RFC3987] | Duerst, M. 和 M. Suignard, "国际化资源标识符 (IRI)", RFC 3987, DOI 10.17487/RFC3987, 2005 年 1 月。 |
| [RFC4291] | Hinden, R. 和 S. Deering, "IPv6 地址体系结构", RFC 4291, DOI 10.17487/RFC4291, 2006 年 2 月。 |
| [RFC5322] | Resnick, P., "互联网消息格式", RFC 5322, DOI 10.17487/RFC5322, 2008 年 10 月。 |
| [RFC5890] | Klensin, J., "应用程序的国际化域名 (IDNA)：定义和文档框架", RFC 5890, DOI 10.17487/RFC5890, 2010 年 8 月。 |
| [RFC5891] | Klensin, J., "应用程序中的国际化域名 (IDNA)：协议", RFC 5891, DOI 10.17487/RFC5891, 2010 年 8 月。 |
| [RFC6570] | Gregorio, J., Fielding, R., Hadley, M., Nottingham, M. 和 D. Orchard, "URI 模板", RFC 6570, DOI 10.17487/RFC6570, 2012 年 3 月。 |
| [RFC6531] | Yao, J. 和 W. Mao, "SMTP 国际化电子邮件扩展", RFC 6531, DOI 10.17487/RFC6531, 2012 年 2 月。 |
| [RFC6901] | Bryan, P., Zyp, K. 和 M. Nottingham, "JavaScript 对象表示法 (JSON) 指针", RFC 6901, DOI 10.17487/RFC6901, 2013 年 4 月。 |
| [RFC7159] | Bray, T., JavaScript 对象表示法 (JSON) 数据交换格式", RFC 7159, DOI 10.17487/RFC7159, 2014 年 3 月。 |
| [ecma262] | ECMA 262 规范" |
| [relative-json-pointer] | Luff, G. 和 H. Andrews, "相对 JSON 指针", Internet-Draft draft-handrews-relative-json-pointer-01, 2017 年 11 月。 |
| [json-schema] | Wright, A. 和 H. Andrews, "JSON 模式：用于描述 JSON 文档的媒体类型", Internet-Draft draft-handrews-json-schema-01, 2017 年 11 月。 |
| [RFC4329] | Hoehrmann, B., "脚本媒体类型", RFC 4329, DOI 10.17487/RFC4329, 2006 年 4 月。 |
感谢 Gary Court、Francis Galiegue、Kris Zyp 和 Geraint Luff 对 JSON 模式初始草案的贡献。
感谢 Jason Desrosiers、Daniel Perrett、Erik Wilde、Ben Hutton、Evgeny Poberezkin、Brad Bowman、Gowry Sankar、Donald Pipowitch、Dave Finlay 和 Denis Laxalde 对文档的提交和修补。
[CREF3]在离开 Internet-Draft 状态之前，此部分将被删除。