8. 문자열로 인코딩된 데이터의 내용을 위한 어휘
8.1. 머리말
이 절에 정의된 주석은 인스턴스가 JSON 문자열로 인코딩된 비 JSON 데이터를 포함함을 나타냅니다.¶
이러한 프로퍼티는 JSON 데이터를 풍부한 멀티미디어 문서로 해석하는 데 필요한 추가 정보를 제공합니다. 콘텐츠의 타입, 인코딩 방식, 그리고/또는 검증될 수 있는 방식을 설명합니다. 이들은 검증 단언으로 동작하지 않습니다. 잘못 형성된 문자열 인코딩 문서가 포함하는 인스턴스를 유효하지 않은 것으로 간주하게 해서는 안 됩니다(MUST NOT).¶
"$vocabulary"를 사용하지 않는 메타 스키마는 이 어휘의 URI가 true 값으로 존재하는 것처럼 이 어휘를 요구하는 것으로 간주하는 것이 좋습니다(SHOULD).¶
Content 어휘로 알려진 이 어휘의 현재 URI는 다음과 같습니다. <https://json-schema.org/draft/2020-12/vocab/content>.¶
대응하는 메타 스키마의 현재 URI는 다음과 같습니다. https://json-schema.org/draft/2020-12/meta/content.¶
8.2. 구현 요구사항
보안 및 성능 문제와 가능한 콘텐츠 타입의 개방적인 특성 때문에, 구현은 기본적으로 문자열 내용을 자동으로 디코딩, 파싱, 그리고/또는 검증해서는 안 됩니다(MUST NOT). 이는 포함하는 문서를 처리한 소비자와 다른 소비자가 처리하도록 의도된 임베디드 문서의 사용 사례도 추가로 지원합니다.¶
이 절의 모든 키워드는 문자열에만 적용되며, 다른 데이터 타입에는 효과가 없습니다.¶
구현은 문자열 내용을 자동으로 디코딩, 파싱, 그리고/또는 검증하는 기능을 제공할 수 있습니다(MAY). 그러나 이러한 작업을 기본적으로 수행해서는 안 되며(MUST NOT), 각 문자열 인코딩 문서의 검증 결과를 둘러싼 문서와 별도로 제공해야 합니다(MUST). 이 프로세스는 원래 스키마에 대해 인스턴스를 완전히 평가한 뒤, 주석을 사용하여 각 문자열 인코딩 문서를 디코딩, 파싱, 그리고/또는 검증하는 것과 동등한 것이 좋습니다(SHOULD). 현재로서는 이러한 자동 디코딩, 파싱 및 검증 기능에서 파싱된 데이터 및/또는 검증 결과를 수행하고 반환하는 정확한 메커니즘은 명세하지 않습니다. 그러한 기능이 널리 사용되는 것으로 입증되면, 향후 초안에서 더 철저히 명세될 수 있습니다. ¶
이러한 키워드에 따라 인스턴스 문자열을 자동으로 처리함으로써 도입될 수 있는 취약점에 대해서는 보안 고려사항 (10절) 절도 참조하십시오.¶
8.3. contentEncoding
인스턴스 값이 문자열이면, 이 프로퍼티는 해당 문자열이 인코딩된 바이너리 데이터로 해석되고 이 프로퍼티가 이름으로 지정한 인코딩을 사용하여 디코딩되는 것이 좋음을 정의합니다(SHOULD).¶
여러 변형을 포함한 base 16, 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"이 존재하는 경우, 이는 인코딩이 identity 인코딩임을 나타냅니다. 즉, 콘텐츠를 UTF-8 문자열로 표현하기 위해 변환이 필요하지 않았다는 뜻입니다.¶
이 프로퍼티의 값은 문자열이어야 합니다(MUST).¶
8.4. contentMediaType
인스턴스가 문자열이면, 이 프로퍼티는 문자열 내용의 미디어 타입을 나타냅니다. "contentEncoding"이 존재하면, 이 프로퍼티는 디코딩된 문자열을 설명합니다.¶
이 프로퍼티의 값은 문자열이어야 하며(MUST), RFC 2046 [RFC2046]에 정의된 미디어 타입이어야 합니다(MUST).¶
8.5. contentSchema
인스턴스가 문자열이고 "contentMediaType"이 존재하면, 이 프로퍼티는 문자열의 구조를 설명하는 스키마를 포함합니다.¶
이 키워드는 JSON Schema의 데이터 모델로 매핑될 수 있는 모든 미디어 타입과 함께 사용할 수 있습니다(MAY).¶
이 프로퍼티의 값은 유효한 JSON Schema여야 합니다(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를 설명하며, claim set 안에 "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 문자열로 표현될 수 있음을 보장하므로, 추가 인코딩 또는 디코딩이 필요하지 않습니다.¶