8. 文字列エンコードデータの内容に関するボキャブラリ
8.1. まえがき
このセクションで定義されている注釈は、インスタンスにJSON文字列でエンコードされた非JSONデータが含まれていることを示しています。¶
これらのプロパティは、JSONデータをリッチマルチメディアドキュメントとして解釈するために必要な追加情報を提供します。これらは、コンテンツの種類、エンコード方法、および/または検証方法について説明しています。これらは検証アサーションとしては機能しません。不正な文字列エンコードドキュメントは、含まれているインスタンスが無効と見なされる原因になってはなりません。¶
"$vocabulary"を使用しないメタスキーマは、そのURIがtrueの値で存在する場合と同様に、このボキャブラリを必要とするものと見なす必要があります。¶
コンテンツボキャブラリとして知られるこのボキャブラリの現在のURIは、次のとおりです。<https://json-schema.dokyumento.jp/draft/2020-12/vocab/content>。¶
対応するメタスキーマの現在のURIは次のとおりです。https://json-schema.dokyumento.jp/draft/2020-12/meta/content。¶
8.2. 実装要件
セキュリティとパフォーマンスに関する懸念事項、および考えられるコンテンツタイプのオープンエンドな性質から、実装はデフォルトで文字列の内容を自動的にデコード、解析、および/または検証してはなりません。これはさらに、包含しているドキュメントを処理したコンシューマとは異なるコンシューマによって処理されることを意図した埋め込みドキュメントの使用ケースをサポートします。¶
このセクションのすべてのキーワードは、文字列のみに適用され、他のデータ型には影響しません。¶
実装では、文字列の内容のデコード、解析、および/または検証を自動的に行う機能を提供することがあります。ただし、これらの操作をデフォルトで実行してはならず、文字列でエンコードされた各ドキュメントの検証結果を、それを含むドキュメントとは別に提供しなければなりません。このプロセスは、インスタンスを元のスキーマに対して完全に評価し、次にアノテーションを使用して文字列でエンコードされた各ドキュメントをデコード、解析、および/または検証することと同等であるべきです。現時点では、そのような自動的なデコード、解析、および検証機能からの解析済みデータおよび/または検証結果を実行および返すための正確なメカニズムは未定義です。そのような機能が人気を博した場合、将来のドラフトでより詳細に規定される可能性があります。¶
インスタンス文字列をこれらのキーワードに従って自動的に処理することによって導入される可能性のある脆弱性については、セキュリティに関する考慮事項 (セクション10)セクションも参照してください。¶
8.3. contentEncoding
インスタンスの値が文字列の場合、このプロパティは、その文字列をエンコードされたバイナリデータとして解釈し、このプロパティで指定されたエンコーディングを使用してデコードする必要があることを定義します。¶
いくつかのバリエーションを含む16進数、32進数、および64進数のエンコーディングを示す可能性のある値は、RFC 4648 [RFC4648]にリストされています。さらに、RFC 2045 [RFC2045]のセクション6.7と6.8には、MIMEで使用されるエンコーディングが記載されています。このキーワードは、MIMEのContent-Transfer-Encodingヘッダーから派生したもので、バイナリデータをASCII文字にマップするように設計されています。これは、HTTPリクエストとレスポンスのコンテンツをエンコードする（例：圧縮または暗号化）ために使用されるHTTPのContent-Encodingヘッダーとは関係ありません。¶
"base64"は両方のRFCで定義されていますが、文字列がMIMEコンテキストでの使用を意図していない限り、RFC 4648の定義を想定する必要があります。これらのエンコーディングはすべて、7ビットASCII文字のみで構成される文字列になります。したがって、このキーワードは、その範囲外の文字を含む文字列には意味を持ちません。¶
このキーワードが存在せず、「contentMediaType」が存在する場合は、エンコーディングが同一性エンコーディングであることを示します。つまり、コンテンツをUTF-8文字列で表現するために変換は必要ありませんでした。¶
このプロパティの値は、文字列でなければなりません。¶
8.4. contentMediaType
インスタンスが文字列の場合、このプロパティは、文字列の内容のメディアタイプを示します。「contentEncoding」が存在する場合は、このプロパティはデコードされた文字列を記述します。¶
このプロパティの値は、文字列でなければならず、RFC 2046 [RFC2046]で定義されているように、メディアタイプでなければなりません。¶
8.5. contentSchema
インスタンスが文字列であり、「contentMediaType」が存在する場合は、このプロパティに、文字列の構造を記述するスキーマが含まれています。¶
このキーワードは、JSONスキーマのデータモデルにマップできるメディアタイプであれば、どれでも使用できます。¶
このプロパティの値は、有効なJSONスキーマでなければなりません。「contentMediaType」が存在しない場合は、無視されるべきです。¶
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でなければなりません。¶
この例は、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文字列で表現できることを保証するため、さらにエンコードまたはデコードする必要はありません。¶