| 互联网工程任务组 | A. Wright，编辑 |
| 互联网草案 | |
| 预期状态：信息性 | H. Andrews，编辑 |
| 到期日期：2020 年 3 月 20 日 | |
| B. Hutton，编辑 | |
| Wellcome Sanger 研究所 | |
| 2019 年 9 月 17 日 |
JSON Schema 验证：用于 JSON 结构验证的词汇表
draft-handrews-json-schema-validation-02
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) 的工作文档。请注意，其他组也可能将工作文档作为互联网草案分发。当前互联网草案列表位于 https://datatracker.ietf.org/drafts/current/。
互联网草案是有效期最多为六个月的草案文档，可能会随时更新、替换或被其他文档废弃。不应将互联网草案用作参考材料或引用，除非是“正在进行的工作”。
本互联网草案将于 2020 年 3 月 20 日到期。
版权所有 (c) 2019 IETF 信托和被认定为文档作者的人员。保留所有权利。
本文件受 BCP 78 和 IETF 信托与 IETF 文档相关的法律条款 (https://trustee.ietf.org/license-info) 约束，这些条款在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文档的权利和限制。从本文档中提取的代码组件必须包含简化的 BSD 许可证文本，如信托法律条款第 4.e 节中所述，并按简化的 BSD 许可证中所述提供，不提供任何担保。
JSON Schema 可用于要求给定的 JSON 文档（实例）满足特定数量的标准。这些标准通过使用本文档中描述的关键字来断言。此外，还定义了一组关键字，以帮助交互式用户界面实例生成。
本文档将使用 JSON Schema 核心 规范中定义的概念、语法和术语。
本文档中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“推荐”、“可以”和“可选”应按 RFC 2119 中的描述进行解释。
本文档使用术语“容器实例”来指代数组和对象实例。它使用术语“子实例”来指代数组元素或对象成员值。
数组值中的元素被称为唯一，如果该数组中没有两个元素是 相等 的。
JSON Schema 验证断言对实例数据的结构的约束。满足所有断言约束的实例位置将被注释为包含任何包含非断言信息的关键字，例如描述性元数据和使用提示。如果实例中的所有位置都满足所有断言约束，则该实例被称为相对于该模式有效。
每个模式对象都独立地针对其适用的每个实例位置进行评估。这通过确保验证器不需要在整个文档范围的验证过程中维护状态，从而极大地简化了验证器的实施要求。
本文档定义了一组断言关键字，以及一个可以用来注释 JSON 实例的有用信息的元数据关键字的小词汇表。 第 7 节 关键字主要被用作注释，但可以选择性地用作断言。 第 8 节 关键字是用于处理嵌入为 JSON 字符串的文档的注释。
需要注意的是，空字符 (\u0000) 在 JSON 字符串中是有效的。要验证的实例可能包含具有此字符的字符串值，无论底层编程语言是否能够处理此类数据。
JSON 规范允许使用任意精度的数字，而 JSON Schema 不会添加任何此类边界。这意味着，由 JSON Schema 处理的数值实例可以是任意大的，或者具有任意长的十进制部分，无论底层编程语言是否能够处理此类数据。
使用正则表达式或将实例值约束为正则表达式的关键字，受 JSON Schema 核心 规范中正则表达式的互操作性注意事项约束。
默认 JSON Schema 元模式的当前 URI 为 <https://json-schema.fullstack.org.cn/draft/2019-09/schema>。为了方便模式作者，此元模式描述了本文档和 JSON Schema 核心规范中定义的所有词汇表，以及两个以前保留用于过渡期的关键字。每个部分下方提供了每个词汇表和词汇表元模式的 URI。某些词汇表是可选支持的，这将在相关部分中详细解释。
为了更正错误，可以在规范草案之间发布更新的词汇表和元模式 URI。实施应考虑在本文档草案之后和下一个草案之前的日期为的 URI，以表示与此处列出的相同语法和语义。
模式中的验证关键字对实例的成功验证施加要求。这些关键字都是断言，没有任何注释行为。
不使用“$vocabulary”的元模式应被认为需要此词汇表，就好像其 URI 存在且值为 true 一样。
此词汇表的当前 URI（称为验证词汇表）是：<https://json-schema.fullstack.org.cn/draft/2019-09/vocab/validation>。
相应元模式的当前 URI 是：<https://json-schema.fullstack.org.cn/draft/2019-09/meta/validation>。
此关键字的值必须是字符串或数组。如果它是数组，则数组的元素必须是字符串，并且必须是唯一的。
字符串值必须是六种原始类型之一（“null”、“boolean”、“object”、“array”、“number”或“string”），或“integer”，它与任何小数部分为零的数字匹配。
实例仅当且仅当实例位于此关键字列出的集合中的任何一个时才有效。
此关键字的值必须是数组。此数组应至少包含一个元素。数组中的元素应是唯一的。
如果实例的值等于此关键字数组值中的一个元素，则实例相对于此关键字成功验证。
数组中的元素可以是任何类型，包括 null。
此关键字的值可以是任何类型，包括 null。
使用此关键字在功能上等同于具有单个值的 "enum"。
如果实例的值等于关键字的值，则实例验证成功。
"multipleOf" 的值必须是一个数字，严格大于 0。
只有当数值实例除以此关键字的值得到一个整数时，该实例才有效。
"maximum" 的值必须是一个数字，表示数值实例的包含上限。
如果实例是一个数字，则只有当实例小于或等于 "maximum" 时，此关键字才有效。
"exclusiveMaximum" 的值必须是数字，表示数值实例的独占上限。
如果实例是一个数字，则只有当实例的值严格小于（不等于）"exclusiveMaximum" 时，该实例才有效。
"minimum" 的值必须是一个数字，表示数值实例的包含下限。
如果实例是一个数字，则只有当实例大于或等于 "minimum" 时，此关键字才有效。
"exclusiveMinimum" 的值必须是数字，表示数值实例的独占下限。
如果实例是一个数字，则只有当实例的值严格大于（不等于）"exclusiveMinimum" 时，该实例才有效。
此关键字的值必须是一个非负整数。
如果字符串实例的长度小于或等于此关键字的值，则该实例针对此关键字有效。
字符串实例的长度定义为其字符的数量，如 RFC 8259 中所定义。
此关键字的值必须是一个非负整数。
如果字符串实例的长度大于或等于此关键字的值，则该实例针对此关键字有效。
字符串实例的长度定义为其字符的数量，如 RFC 8259 中所定义。
省略此关键字与值 0 的行为相同。
此关键字的值必须是一个字符串。此字符串应根据 ECMA 262 正则表达式方言，是一个有效的正则表达式。
如果正则表达式成功匹配实例，则字符串实例被认为有效。回想一下：正则表达式不会隐式锚定。
此关键字的值必须是一个非负整数。
如果数组实例的大小小于或等于此关键字的值，则该实例针对 "maxItems" 有效。
此关键字的值必须是一个非负整数。
如果数组实例的大小大于或等于此关键字的值，则该实例针对 "minItems" 有效。
省略此关键字与值 0 的行为相同。
此关键字的值必须是布尔值。
如果此关键字的布尔值为 false，则实例验证成功。如果此关键字的布尔值为 true，则只有当实例的所有元素都是唯一的时，实例验证成功。
省略此关键字与值 false 的行为相同。
此关键字的值必须是一个非负整数。
如果针对 "contains" 的模式有效的元素数量小于或等于此关键字的值，则数组实例针对 "maxContains" 有效。
如果在同一个模式对象中不存在 "contains"，则此关键字无效。
此关键字的值必须是一个非负整数。
如果针对 "contains" 的模式有效的元素数量大于或等于此关键字的值，则数组实例针对 "minContains" 有效。
允许值为 0，但它仅用于设置从 0 到 "maxContains" 值的出现范围。值为 0 且没有 "maxContains" 会导致 "contains" 始终通过验证。
如果在同一个模式对象中不存在 "contains"，则此关键字无效。
省略此关键字与值 1 的行为相同。
此关键字的值必须是一个非负整数。
如果对象实例的属性数量小于或等于此关键字的值，则该实例针对 "maxProperties" 有效。
此关键字的值必须是一个非负整数。
如果对象实例的属性数量大于或等于此关键字的值，则该实例针对 "minProperties" 有效。
省略此关键字与值 0 的行为相同。
此关键字的值必须是一个数组。此数组中的元素（如果有）必须是字符串，并且必须是唯一的。
如果数组中的每个项目都是实例中属性的名称，则对象实例针对此关键字有效。
省略此关键字与空数组的行为相同。
此关键字的值必须是一个对象。此对象中的属性（如果有）必须是数组。每个数组中的元素（如果有）必须是字符串，并且必须是唯一的。
此关键字指定如果存在特定其他属性，则需要哪些属性。它们的要求取决于其他属性的存在。
如果对于同时出现在实例中以及作为此关键字的值中的名称，对应数组中的每个项目也是实例中属性的名称，则验证成功。
省略此关键字与空对象的行為相同。
仅结构验证可能不足以让应用程序正确使用某些值。定义了 "format" 注释关键字，以允许模式作者传达一组固定值的语义信息，这些值被权威资源准确描述，无论是 RFC 还是其他外部规范。
实现可以将 "format" 视为断言以及注释，并尝试验证值是否符合指定的语义。有关详细信息，请参阅下面的实现要求。
此关键字的值称为格式属性。它必须是一个字符串。格式属性通常只能验证给定的一组实例类型。如果要验证的实例的类型不在此集合中，则针对此格式属性和实例的验证应成功。本节中定义的所有格式属性都适用于字符串，但可以指定格式属性以应用于 核心 JSON 模式 中定义的任何实例类型。 [CREF1]请注意，本规范中的 "type" 关键字定义了一个 "integer" 类型，它不是数据模型的一部分。因此，格式属性可以限于数字，但不能专门限于整数。但是，可以将数字格式与 "type" 关键字一起使用，其值为 "integer"，或者可以明确定义为始终通过，如果数字不是整数，则产生与仅应用于整数本质上相同的效果。
不使用 "$vocabulary" 的元模式应被认为使用此词汇表，就好像它的 URI 存在且值为 false 一样。有关详细信息，请参阅下面的实现要求。
此词汇表的当前 URI，称为 Format 词汇表，为：<https://json-schema.fullstack.org.cn/draft/2019-09/vocab/format>.
相应元模式的当前 URI 为：<https://json-schema.fullstack.org.cn/draft/2019-09/meta/format>.
"format" 关键字充当注释，以及可选的断言。 [CREF2]这是由于关键字的历史，与当前关键字设计原则不一致。 为了管理这种歧义，"format" 关键字在它自己的单独词汇表中定义，如上所述。词汇表声明的真或假值决定了处理使用 "format" 的模式所需的实现要求，以及模式作者可以依赖的行为。
如果实现支持注释收集，则必须收集 "format" 的值作为注释。这在模式验证不可用或不足的情况下，支持应用程序级验证。
此要求不受词汇表声明的布尔值、下一节中描述的 "format" 断言行为配置的影响。 [CREF3]即使词汇表声明的值为 false，也要求收集注释是不典型的，但必须确保即使没有实现断言评估，也可以执行应用程序级验证的最佳实践。由于 "format" 一直是本规范的一部分，因此要求即使词汇表声明为 false，实现也必须意识到它，这被认为不是负担。
无论词汇表声明的布尔值如何，能够将 "format" 评估为断言的实现都必须提供启用和禁用此类评估的选项。当选项未明确指定时，断言评估行为取决于词汇表声明的布尔值。
在实现本规范的整体时，此词汇表必须支持值为 false（但请参见下面的详细信息），并且可以支持值为 true。
当词汇表声明的值为 false 时，实现： [CREF4]这与实现的当前现实相匹配，实现为某些或所有格式属性提供各种水平的验证，包括根本没有验证。它还旨在鼓励仅依赖于注释行为并在应用程序中执行语义验证，这是推荐的最佳实践。
当词汇表声明的值为 true 时，支持此形式词汇表的实现： [CREF5]预期对于像日期时间这样的简单格式，语法验证将是彻底的。对于像电子邮件地址这样复杂的格式，它是各种标准和许多调整的融合，随着时间的推移而发展，并存在模糊和/或过时的规则，这些规则可能受到使用该值的其他应用程序的限制或不受其限制，最小的验证就足够了。例如，不包含 "@" 字符的实例字符串显然不是有效的电子邮件地址，而包含 7 位 ASCII 之外的字符的 "email" 或 "hostname" 也同样明显无效。
由于涉及许多属性的复杂性，对格式属性进行最小验证的要求是有意地含糊不清和宽松的。特别要注意，该要求仅限于语法检查；不应期望实现发送电子邮件，尝试连接到 URL，或者以其他方式检查由格式实例标识的实体的存在。
建议实现使用每个格式的通用解析库或知名正则表达式。实现应明确记录每个格式属性是如何以及在何种程度上进行验证的。
标准核心和验证元模式在它的 "$vocabulary" 关键字中包含此词汇表，其值为 false，因为默认情况下，实现不需要将此关键字作为断言进行支持。使用值为 true 来支持格式词汇表，意味着代码量会大幅增加，在某些情况下执行时间也会增加，并非所有实现都适用。
实现可以支持自定义格式属性。除了各方之间的协议之外，模式作者不应期望同级实现支持此类自定义格式属性。实现不得因未知格式属性而导致验证失败或停止处理。当将“format”视为注释时，实现应该收集已知和未知的格式属性值。
词汇表不支持专门为关键字声明不同的值集。由于此限制以及此关键字在历史上的实现不一致，建议在自定义词汇表中定义额外的关键字，而不是定义额外的格式属性，尤其是在需要互操作性的情况下。
这些属性适用于字符串实例。
日期和时间格式名称源自 RFC 3339，第 5.6 节。持续时间格式来自 RFC 3339 附录 A 中给出的 ISO 8601 ABNF。
支持格式的实现应该实现对以下属性的支持
实现可以支持使用该节中定义的其他生成规则名称的额外属性。如果实现了“full-date”或“full-time”，则必须实现相应的简短形式（分别是“date”或“time”），并且必须行为相同。实现不应使用与 RFC 3339 生成规则名称匹配的任何名称定义扩展属性，除非它根据该生成规则的规则进行验证。 [CREF6]目前还没有共识表明需要支持所有 RFC 3339 格式，因此这种保留命名空间的做法将鼓励实验，而不必承诺使用整套格式。要么格式实现要求会变得更加灵活，要么这些格式很可能要么会被提升为完全指定的属性，要么会被删除。
这些属性适用于字符串实例。
如果一个字符串实例是有效的互联网电子邮件地址，那么它相对于这些属性就是有效的，具体如下
请注意，所有相对于“email”属性有效的字符串也相对于“idn-email”属性有效。
这些属性适用于字符串实例。
如果一个字符串实例是有效的互联网主机名的表示，那么它相对于这些属性就是有效的，具体如下
请注意，所有相对于“hostname”属性有效的字符串也相对于“idn-hostname”属性有效。
这些属性适用于字符串实例。
如果一个字符串实例是 IP 地址的有效表示，那么它相对于这些属性就是有效的，具体如下
这些属性适用于字符串实例。
请注意，所有有效的 URI 都是有效的 IRI，所有有效的 URI 引用也是有效的 IRI 引用。
还要注意，“uuid”格式用于纯 UUID，而不是 URN 中的 UUID。例如，“f81d4fae-7dec-11d0-a765-00a0c91e6bf6”。对于作为 URN 的 UUID，请使用“uri”格式，并使用“pattern”正则表达式“^urn:uuid:”来指示 URI 方案和 URN 命名空间。
此属性适用于字符串实例。
如果一个字符串实例是有效的 URI 模板（任何级别），那么它相对于此属性就是有效的，根据 [RFC6570]。
请注意，URI 模板可用于 IRI；没有单独的 IRI 模板规范。
这些属性适用于字符串实例。
为了允许使用绝对和相对 JSON 指针，请使用“anyOf”或“oneOf”来指示对两种格式的支持。
此属性适用于字符串实例。
正则表达式，应根据 ECMA 262 正则表达式方言有效。
验证格式的实现必须至少接受此规范的 正则表达式 部分中定义的 ECMA 262 子集，并且应该接受所有有效的 ECMA 262 表达式。
本节中定义的注释表示一个实例包含以 JSON 字符串编码的非 JSON 数据。
这些属性提供了将 JSON 数据解释为富媒体文档所需的其他信息。它们描述了内容的类型、编码方式和/或验证方式。它们不充当验证断言；格式错误的字符串编码文档不得导致包含的实例被视为无效。
不使用“$vocabulary”的元模式应被认为需要此词汇表，就好像其 URI 存在且值为 true 一样。
此词汇表（称为内容词汇表）的当前 URI 为：<https://json-schema.fullstack.org.cn/draft/2019-09/vocab/content>.
相应元模式的当前 URI 为：<https://json-schema.fullstack.org.cn/draft/2019-09/meta/content>.
由于安全和性能问题，以及可能的内容类型是开放式的，实现不应默认情况下自动解码、解析和/或验证字符串内容。这也支持嵌入文档的用例，这些文档旨在由与处理包含文档的消费者不同的消费者进行处理。
本节中的所有关键字仅适用于字符串，对其他数据类型没有影响。
实现可以提供自动解码、解析和/或验证字符串内容的功能。但是，它不应默认执行这些操作，并且必须分别提供每个字符串编码文档的验证结果，而不是包含的文档。此过程应等同于根据原始模式完全评估实例，然后使用注释解码、解析和/或验证每个字符串编码文档。 [CREF7]目前，此类自动解码、解析和验证功能执行和返回解析数据和/或验证结果的具体机制尚未指定。如果此类功能流行起来，可能会在以后的草案中更详细地指定。
另请参见 安全注意事项 部分，了解根据这些关键字自动处理实例字符串可能引入的漏洞。
如果实例值是字符串，则此属性定义应将该字符串解释为二进制数据，并使用此属性命名的编码对其进行解码。
此属性的可能值列在 RFC 2045，第 6.1 节 和 RFC 4648 中。对于在两个 RFC 中都定义的“base64”，应使用 RFC 4648 中的定义，该定义删除了行长度限制，因为各种其他规范已经强制执行了不同的长度。请注意，可以使用 "pattern" 关键字来限制字符串中的行长度。
如果此关键字不存在，但“contentMediaType”存在，则表示媒体类型可以像任何其他 JSON 字符串值一样编码为 UTF-8，不需要额外的解码。
此属性的值必须是字符串。
如果实例是字符串，则此属性表示字符串内容的媒体类型。如果“contentEncoding”存在，则此属性描述解码后的字符串。
此属性的值必须是字符串，该字符串必须是媒体类型，如 RFC 2046 中所定义。
如果实例是字符串，并且如果“contentMediaType”存在，则此属性包含描述字符串结构的模式。
此关键字可以与可以映射到 JSON Schema 数据模型的任何媒体类型一起使用。
如果“contentMediaType”不存在，则应忽略此属性的值。
以下是一个模式示例，说明了“contentEncoding”和“contentMediaType”的使用
{
"type": "string",
"contentEncoding": "base64",
"contentMediaType": "image/png"
}
此模式描述的实例应为字符串，其值应可解释为 base64 编码的 PNG 图像。
另一个示例
{
"type": "string",
"contentMediaType": "text/html"
}
此模式描述的实例应为包含 HTML 的字符串，使用 JSON 字符串解码到的任何字符集。根据 RFC 8259，第 8.1 节，在完全封闭的系统之外，这必须是 UTF-8。
此示例描述了一个使用 HMAC SHA-256 算法进行 MAC 的 JWT，并要求其声明集中包含“iss”和“exp”字段。
{
"type": "string",
"contentMediaType": "application/jwt",
"contentSchema": {
"type": "array",
"minItems": 2,
"items": [
{
"const": {
"typ": "JWT",
"alg": "HS256"
}
},
{
"type": "object",
"required": ["iss", "exp"],
"properties": {
"iss": {"type": "string"},
"exp": {"type": "integer"}
}
}
]
}
}
请注意，"contentEncoding" 并未出现。虽然 "application/jwt" 媒体类型使用 base64url 编码，但这由媒体类型定义，该媒体类型决定 JWT 字符串如何解码为两个 JSON 数据结构列表：第一个是标头，第二个是有效载荷。由于 JWT 媒体类型确保 JWT 可以用 JSON 字符串表示，因此不需要进一步编码或解码。
这些通用注释关键字提供了用于文档和用户界面显示目的的常用信息。它们并非旨在形成一组完整的特性。相反，可以为更复杂的基于注释的应用程序定义其他词汇表。
不使用“$vocabulary”的元模式应被认为需要此词汇表，就好像其 URI 存在且值为 true 一样。
此词汇表的当前 URI，称为元数据词汇表，为：<https://json-schema.fullstack.org.cn/draft/2019-09/vocab/meta-data>。
相应元模式的当前 URI 为：<https://json-schema.fullstack.org.cn/draft/2019-09/meta/meta-data>。
这两个关键字的值都必须是字符串。
这两个关键字都可以用来用有关此用户界面生成的数据的信息来装饰用户界面。标题最好简短，而描述将提供有关此模式描述的实例目的的解释。
此关键字的值没有任何限制。当此关键字的多个出现适用于单个子实例时，实现应该删除重复项。
此关键字可用于提供与特定模式关联的默认 JSON 值。建议默认值对关联模式有效。
此关键字的值必须是布尔值。当此关键字的多个出现适用于单个子实例时，应用程序应该在任何出现都指定 true 值的情况下，认为实例位置已弃用。
如果 "deprecated" 的值为布尔值 true，则表示应用程序应该避免使用声明的属性。它可能意味着该属性将在未来被删除。
包含 "deprecated" 且其值为 true 的根模式表示正在描述的整个资源可能在将来被删除。
当 "deprecated" 关键字通过 "items" 应用于数组中的项目时，如果 "items" 是单个模式，则弃用与整个数组相关，而如果 "items" 是模式数组，则弃用与根据子模式位置的相应项目相关。
省略此关键字与值 false 的行为相同。
这些关键字的值必须是布尔值。当这些关键字的多个出现适用于单个子实例时，如果任何出现都指定 true 值，则结果行为应该与 true 值相同，否则应该与 false 值相同。
如果 "readOnly" 的值为布尔值 true，则表示实例的值完全由拥有方管理，应用程序尝试修改此属性的值预计将被拥有方忽略或拒绝。
标记为 "readOnly" 的整个文档的实例文档可能在发送到拥有方时被忽略，或者可能导致错误，这由拥有方自行决定。
如果 "writeOnly" 的值为布尔值 true，则表示当从拥有方检索实例时，该值永远不会出现。它可以在发送到拥有方以更新或创建文档（或其代表的资源）时出现，但它不会包含在任何更新的或新创建的实例版本中。
标记为 "writeOnly" 的整个文档的实例文档可能作为某种空白文档返回，或者可能在检索时产生错误，或者检索请求被忽略，这由拥有方自行决定。
例如，"readOnly" 用于将数据库生成的序列号标记为只读，而 "writeOnly" 用于将密码输入字段标记为只写。
这些关键字可用于辅助用户界面实例生成。特别地，应用程序可以选择使用一个小部件，该小部件隐藏写入的字段中输入值随着它们被键入而显示。
省略这些关键字的行为与 false 值相同。
此关键字的值必须是数组。数组中的值没有任何限制。当此关键字的多个出现适用于单个子实例时，实现必须提供所有值的扁平数组，而不是数组的数组。
此关键字可用于提供与特定模式关联的示例 JSON 值，以说明用法。建议这些值对关联模式有效。
实现可以使用 "default" 的值（如果存在）作为附加示例。如果 "examples" 缺失，"default" 仍可用于这种方式。
JSON Schema 验证定义了 JSON Schema 核心词汇表，并且涉及到那里列出的所有安全注意事项。
JSON Schema 验证允许使用正则表达式，正则表达式有许多不同的（通常不兼容）实现。一些实现允许嵌入任意代码，这超出了 JSON Schema 的范围，并且必须禁止。正则表达式通常也可以被设计成计算起来非常昂贵（使用所谓的“灾难性回溯”），从而导致拒绝服务攻击。
支持基于 "contentEncoding" 和/或 "contentMediaType" 验证或以其他方式评估实例字符串数据的实现有风险，即以基于误导性信息的不安全方式评估数据。应用程序可以通过仅在建立模式和实例之间的关系时（例如，它们共享相同的权限）才执行此类处理来降低此风险。
处理媒体类型或编码受该媒体类型或编码的安全注意事项的影响。例如，当处理 JSON 字符串中编码的 JavaScript 或 ECMAScript 时，RFC 4329 脚本媒体类型 的安全注意事项适用。
| [ecma262] | "ECMA 262 规范" |
| [json-schema] | Wright, A. 和 H. Andrews，"JSON Schema: 用于描述 JSON 文档的媒体类型"，互联网草案 draft-handrews-json-schema-02，2017 年 11 月。 |
| [relative-json-pointer] | Luff, G. 和 H. Andrews，"相对 JSON 指针"，互联网草案 draft-handrews-relative-json-pointer-01，2017 年 11 月。 |
| [RFC1123] | Braden, R.，"互联网主机要求 - 应用程序和支持"，STD 3，RFC 1123，DOI 10.17487/RFC1123，1989 年 10 月。 |
| [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 月。 |
| [RFC2119] | Bradner, S.，"用于 RFC 中指示要求级别的关键词"，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997 年 3 月。 |
| [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 月。 |
| [RFC4122] | Leach, P.，Mealling, M. 和 R. Salz，"通用唯一标识符 (UUID) URN 命名空间"，RFC 4122，DOI 10.17487/RFC4122，2005 年 7 月。 |
| [RFC4291] | Hinden, R. 和 S. Deering，"IPv6 地址体系结构"，RFC 4291，DOI 10.17487/RFC4291，2006 年 2 月。 |
| [RFC4648] | Josefsson, S.，"Base16、Base32 和 Base64 数据编码"，RFC 4648，DOI 10.17487/RFC4648，2006 年 10 月。 |
| [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 月。 |
| [RFC6531] | Yao, J. 和 W. Mao，"SMTP 国际化电子邮件扩展"，RFC 6531，DOI 10.17487/RFC6531，2012 年 2 月。 |
| [RFC6570] | Gregorio, J.，Fielding, R.，Hadley, M.，Nottingham, M. 和 D. Orchard，"URI 模板"，RFC 6570，DOI 10.17487/RFC6570，2012 年 3 月。 |
| [RFC6901] | Bryan, P.，Zyp, K. 和 M. Nottingham，"JavaScript 对象表示法 (JSON) 指针"，RFC 6901，DOI 10.17487/RFC6901，2013 年 4 月。 |
| [RFC8259] | Bray, T.，"JavaScript 对象表示法 (JSON) 数据交换格式"，STD 90，RFC 8259，DOI 10.17487/RFC8259，2017 年 12 月。 |
| [RFC4329] | Hoehrmann, B.，"脚本媒体类型"，RFC 4329，DOI 10.17487/RFC4329，2006 年 4 月。 |
从本草案开始，一些关键字已从本文档中迁移到 核心规范，在某些情况下已重命名或进行了其他更改。这影响了以下以前的验证关键字
感谢 Gary Court、Francis Galiegue、Kris Zyp 和 Geraint Luff 对 JSON Schema 初稿的贡献。
感谢 Jason Desrosiers、Daniel Perrett、Erik Wilde、Ben Hutton、Evgeny Poberezkin、Brad Bowman、Gowry Sankar、Donald Pipowitch、Dave Finlay 和 Denis Laxalde 对文档的提交和修补。