8. 文字列エンコードデータのコンテンツのための語彙
8.1. 前書き
このセクションで定義されたアノテーションは、インスタンスにJSON文字列でエンコードされた非JSONデータが含まれていることを示します。¶
これらのプロパティは、JSONデータをリッチマルチメディアドキュメントとして解釈するために必要な追加情報を提供します。それらは、コンテンツのタイプ、エンコード方法、および/または検証方法を記述します。それらは検証アサーションとして機能しません。不正な形式の文字列エンコードされたドキュメントによって、包含するインスタンスが無効と見なされてはなりません（MUST NOT）。¶
「$vocabulary」を使用しないメタスキーマは、そのURIがtrueの値で存在するかのように、この語彙を必要とすると見なされるべきです（SHOULD）。¶
この語彙の現在のURI（コンテンツ語彙として知られています）は、<https://json-schema.dokyumento.jp/draft/2020-12/vocab/content>です。¶
対応するメタスキーマの現在のURIは、https://json-schema.dokyumento.jp/draft/2020-12/meta/contentです。¶
8.2. 実装要件
セキュリティとパフォーマンスに関する懸念、および可能性のあるコンテンツタイプのオープンエンドな性質のため、実装はデフォルトでは文字列コンテンツを自動的にデコード、解析、および/または検証してはなりません（MUST NOT）。これにより、包含ドキュメントを処理したコンシューマーとは異なるコンシューマーによる処理を目的とした埋め込みドキュメントのユースケースもサポートされます。¶
このセクションのすべてのキーワードは文字列にのみ適用され、他のデータ型には影響しません。¶
実装は、文字列コンテンツを自動的にデコード、解析、および/または検証する機能を提供してもよい（MAY）。ただし、デフォルトではこれらの操作を実行してはならず（MUST NOT）、各文字列エンコードされたドキュメントの検証結果を、囲むドキュメントとは別に提供する必要があります（MUST）。このプロセスは、インスタンスを元のスキーマに対して完全に評価し、その後にアノテーションを使用して各文字列エンコードされたドキュメントをデコード、解析、および/または検証するのと同等であるべきです（SHOULD）。今のところ、このような自動デコード、解析、検証機能から解析されたデータおよび/または検証結果を実行および返す正確なメカニズムは、仕様化されていません。このような機能が普及した場合、将来のドラフトでより詳細に仕様化される可能性があります。¶
これらのキーワードに従ってインスタンス文字列を自動的に処理することによって導入される可能性のある脆弱性については、セキュリティに関する考慮事項 (セクション 10) セクションも参照してください。¶
8.3. contentEncoding
インスタンス値が文字列の場合、このプロパティは、文字列がエンコードされたバイナリデータとして解釈されるべきであり、このプロパティで指定されたエンコーディングを使用してデコードされるべきであることを定義します。¶
いくつかのバリエーションを持つbase16、32、および64エンコーディングを示す可能な値は、RFC 4648 [RFC4648] にリストされています。さらに、RFC 2045 [RFC2045] のセクション 6.7 および 6.8 は、MIMEで使用されるエンコーディングを提供します。このキーワードは、バイナリデータをASCII文字にマッピングするように設計されたMIMEのContent-Transfer-Encodingヘッダーに由来します。これは、HTTPリクエストとレスポンスのコンテンツをエンコード（例：圧縮または暗号化）するために使用されるHTTPのContent-Encodingヘッダーとは関係ありません。¶
「base64」は両方のRFCで定義されているため、文字列がMIMEコンテキストでの使用を特に意図していない限り、RFC 4648からの定義を想定する必要があります（SHOULD）。これらのエンコーディングはすべて、7ビットASCII文字のみで構成される文字列になることに注意してください。したがって、このキーワードは、その範囲外の文字を含む文字列には意味がありません。¶
このキーワードが存在しないが、「contentMediaType」が存在する場合、これはエンコーディングが同一エンコーディングであることを示し、つまり、コンテンツをUTF-8文字列で表すために変換は不要であったことを意味します。¶
このプロパティの値は文字列である必要があります（MUST）。¶
8.4. contentMediaType
インスタンスが文字列の場合、このプロパティは文字列の内容のメディアタイプを示します。「contentEncoding」が存在する場合、このプロパティはデコードされた文字列を記述します。¶
このプロパティの値は文字列である必要があり（MUST）、RFC 2046 [RFC2046] で定義されているメディアタイプである必要があります（MUST）。¶
8.5. contentSchema
インスタンスが文字列で、「contentMediaType」が存在する場合、このプロパティには文字列の構造を記述するスキーマが含まれます。¶
このキーワードは、JSONスキーマのデータモデルにマッピングできる任意のメディアタイプで使用できます（MAY）。¶
このプロパティの値は有効なJSONスキーマである必要があります（MUST）。「contentMediaType」が存在しない場合は無視されるべきです（SHOULD）。¶
8.6. 例
これは、「contentEncoding」と「contentMediaType」の使用例を示すスキーマ例です。¶
{
"type": "string",
"contentEncoding": "base64",
"contentMediaType": "image/png"
}
¶
このスキーマで記述されたインスタンスは文字列であると予想され、それらの値はbase64エンコードされたPNG画像として解釈できる必要があります。¶
別の例:¶
{
"type": "string",
"contentMediaType": "text/html"
}
¶
このスキーマで記述されたインスタンスは、JSON文字列がデコードされた文字セットを使用して、HTMLを含む文字列であると予想されます。RFC 8259 [RFC8259] のセクション 8.1 によると、完全に閉じたシステムの外では、これはUTF-8である必要があります（MUST）。¶
この例では、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文字列を2つのJSONデータ構造のリスト（最初にヘッダー、次にペイロード）にデコードする方法を決定します。JWTメディアタイプはJWTがJSON文字列で表現できることを保証するため、それ以上のエンコードまたはデコードは必要ありません。¶