8. 字符串编码数据内容词汇表
8.1. 前言
本节中定义的注解表示实例包含 编码在 JSON 字符串中的非 JSON 数据。¶
这些属性提供了解释 JSON 数据为富媒体文档所需的额外信息。 它们描述内容的类型、其编码方式， 以及/或者其可能如何被验证。它们不作为验证断言； 格式错误的字符串编码文档不得导致包含它的实例 被视为无效。¶
不使用 "$vocabulary" 的元模式应被视为 需要此词汇表，就好像其 URI 以 true 值存在一样。¶
此词汇表的当前 URI（称为 Content 词汇表）是： <https://json-schema.org/draft/2020-12/vocab/content>。¶
对应元模式的当前 URI 是： https://json-schema.org/draft/2020-12/meta/content。¶
8.2. 实现 要求
由于安全和性能方面的考虑，以及可能内容类型的开放性， 实现默认不得自动解码、解析， 以及/或者验证字符串内容。这还支持 嵌入式文档的用例：这些文档意图由不同于 处理包含文档的消费者来处理。¶
本节中的所有关键字仅适用于字符串，并且对其他 数据类型没有效果。¶
实现可以提供自动解码、解析，以及/或者验证 字符串内容的能力。但是，它默认不得执行这些 操作，并且必须将每个字符串编码文档的验证结果 与外层文档分开提供。此过程应等价于 先根据原始模式完整求值实例， 然后使用注解来解码、解析， 以及/或者验证每个字符串编码文档。 目前，从这种自动解码、解析和验证功能中 执行并返回已解析数据以及/或者验证结果的确切机制 暂未指定。如果此类功能被证明很受欢迎， 它可能会在未来草案中更完整地指定。 ¶
8.3. contentEncoding
如果实例值是字符串，则此属性定义该字符串 应被解释为编码后的二进制数据，并使用 此属性命名的编码进行解码。¶
RFC 4648 [RFC4648] 中列出了表示 base 16、32 和 64 编码及其若干 变体的可能值。此外， RFC 2045 [RFC2045] 第 6.7 和 6.8 节提供了 MIME 中使用的编码。此关键字源自 MIME 的 Content-Transfer-Encoding 标头，该标头设计用于将二进制数据 映射为 ASCII 字符。它与 HTTP 的 Content-Encoding 标头无关， 后者用于编码（例如压缩或加密） HTTP 请求和响应的内容。¶
由于 "base64" 在两个 RFC 中均有定义，除非字符串专门意图 用于 MIME 上下文，否则应假定采用 RFC 4648 中的定义。请注意，所有这些编码都会产生 仅由 7 位 ASCII 字符组成的字符串。因此，此关键字 对包含该范围之外字符的字符串没有意义。¶
如果此关键字不存在，但存在 "contentMediaType"，则这 表示编码是 identity encoding，即 为了在 UTF-8 字符串中表示该内容， 不需要任何转换。¶
此属性的值必须是字符串。¶
8.4. contentMediaType
如果实例是字符串，则此属性指示该字符串内容的媒体类型。 如果存在 "contentEncoding"， 则此属性描述解码后的字符串。¶
8.5. contentSchema
如果实例是字符串，并且存在 "contentMediaType"，则此 属性包含一个描述该字符串结构的模式。¶
此关键字可以与任何可映射到 JSON Schema 数据模型的媒体类型一起使用。¶
此属性的值必须是有效的 JSON schema。如果 "contentMediaType" 不存在，则应忽略它。¶
8.6. 示例
下面是一个示例模式，展示 "contentEncoding" 和 "contentMediaType" 的用法：¶
{
"type": "string",
"contentEncoding": "base64",
"contentMediaType": "image/png"
}
¶
此模式描述的实例预期为字符串， 并且其值应可解释为 base64 编码的 PNG 图像。¶
另一个示例：¶
{
"type": "string",
"contentMediaType": "text/html"
}
¶
此模式描述的实例预期为包含 HTML 的字符串， 使用 JSON 字符串被解码成的任何字符集。 根据 RFC 8259 [RFC8259] 第 8.1 节，在完全封闭的 系统之外，这必须是 UTF-8。¶
此示例描述了一个使用 HMAC SHA-256 算法进行 MAC 处理的 JWT，并要求其声明集中的 "iss" 和 "exp" 字段。¶
{
"type": "string",
"contentMediaType": "application/jwt",
"contentSchema": {
"type": "array",
"minItems": 2,
"prefixItems": [
{
"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 字符串中， 因此无需进一步编码或解码。¶