8. 用于字符串编码数据内容的词汇表
8.1. 前言
本节中定义的注释表示实例包含在 JSON 字符串中编码的非 JSON 数据。¶
这些属性提供了解释 JSON 数据为丰富的多媒体文档所需的附加信息。它们描述了内容类型、编码方式和/或验证方式。它们不能作为验证断言；格式错误的字符串编码文档 MUST NOT 导致包含的实例被认为无效。¶
不使用“$vocabulary”的元模式 SHOULD 被认为需要此词汇表，就好像它的 URI 存在并且值为 true 一样。¶
此词汇表（称为 Content 词汇表）的当前 URI 为：<https://json-schema.fullstack.org.cn/draft/2020-12/vocab/content>。¶
相应元模式的当前 URI 为：https://json-schema.fullstack.org.cn/draft/2020-12/meta/content。¶
8.2. 实现要求
由于安全和性能问题，以及可能的内容类型的开放性，实现 MUST NOT 默认情况下自动解码、解析和/或验证字符串内容。这也支持将嵌入式文档用于与处理包含文档的消费者不同的消费者进行处理的用例。¶
本节中的所有关键字仅适用于字符串，并且对其他数据类型没有影响。¶
实现可以提供自动解码、解析和/或验证字符串内容的功能。但是，**不能**默认执行这些操作，**必须**分别提供每个字符串编码文档的验证结果，与包含文档分开。此过程**应该**等同于根据原始模式完全评估实例，然后使用注释解码、解析和/或验证每个字符串编码文档。 截至目前，自动解码、解析和验证功能的解析数据和/或验证结果的执行和返回的确切机制尚未确定。如果此功能得到普及，未来草案中可能会更详细地规定。 ¶
8.3. contentEncoding
如果实例值为字符串，则此属性定义该字符串**应该**被解释为编码的二进制数据，并使用此属性命名的编码进行解码。¶
可能的值表示具有多种变体的 16、32 和 64 进制编码，这些值列在RFC 4648 [RFC4648]中。此外，RFC 2045 [RFC2045]的第 6.7 节和第 6.8 节提供 MIME 中使用的编码。此关键字源自 MIME 的 Content-Transfer-Encoding 头部，该头部旨在将二进制数据映射到 ASCII 字符。它与 HTTP 的 Content-Encoding 头部无关，HTTP 的 Content-Encoding 头部用于对 HTTP 请求和响应的内容进行编码（例如，压缩或加密）。¶
由于“base64”在两个 RFC 中都有定义，因此**应该**假设来自 RFC 4648 的定义，除非字符串专门用于 MIME 上下文。请注意，所有这些编码都会导致字符串仅包含 7 位 ASCII 字符。因此，此关键字对包含该范围之外的字符的字符串没有意义。¶
如果此关键字不存在，但“contentMediaType”存在，则表示编码是标识编码，这意味着不需要转换即可将内容表示为 UTF-8 字符串。¶
此属性的值**必须**为字符串。¶
8.4. contentMediaType
如果实例为字符串，则此属性表示字符串内容的媒体类型。如果存在“contentEncoding”，则此属性描述解码后的字符串。¶
8.5. contentSchema
如果实例为字符串，且存在“contentMediaType”，则此属性包含一个模式，该模式描述字符串的结构。¶
此关键字**可以**与可以映射到 JSON Schema 数据模型的任何媒体类型一起使用。¶
此属性的值**必须**为有效的 JSON 模式。如果不存在“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 字符串表示，因此不需要进一步编码或解码。¶