JSON이(가) 유효합니까 YAML? YAML 1.2의 약속과 약속 위반 위치

JSON을(를) YAML 파일에 붙여넣고 문제를 해결합니다. 왜 작동하는지, 한 번은 작동하지 않았는지

일반 JSON 개체를 YAML 소스 측에 붙여넣고 ToolAcre의 YAML 1.2 JSON 스키마에서 읽을 수 있습니다. 중괄호, 대괄호, 인용된 키, 문자열, 숫자, 부울 및 null은 동일한 일반 JavaScript 값이 됩니다. 경계가 종종 하찮게 느껴지는 이유가 바로 이것이다.

보장은 파서별로 유지되어야 합니다. ToolAcre는 태그를 제한하고 별칭 및 중첩을 제한하며 입력 제한을 적용합니다. 텍스트는 더 넓은 YAML 프로세서에서 유효하지만 JSON처럼 보이는 코어와 관련 없는 안전 또는 모양상의 이유로 거부될 수 있습니다.

일반 JSON은 이 YAML 1.2 리더를 통해 로드됩니다. 지원되지 않는 확장은 별도의 이유로 실패합니다.

선택한 스키마는 JSON 모양의 값(문자열, 숫자, 부울, Null, 배열 및 매핑)을 생성합니다. 이 정렬을 사용하면 구두점 교체 대신 구문 분석 후 직렬화가 가능합니다. 소스 코드는 YAML 사양의 모든 표현이나 정오표를 설정하지 않으므로 이 기사에서는 철저한 적합성을 주장하는 대신 테스트된 동작을 보고합니다.

엄격 모드에서는 물결표, 빈 값 및 `0o755` 문자열이 유지됩니다. 이는 YAML 토큰 JSON 자체에는 포함되지 않습니다. Core는 JSON 모양의 출력을 반환하면서 이를 다르게 해결합니다.

제공된 스키마는 모든 사양 가장자리를 증명하지 않고 JSON 모양의 데이터와 일치합니다.

중복 YAML 매핑 키는 경고와 함께 마지막 값을 유지합니다. 다른 곳에서 엄격한 해석을 하면 거부될 수 있습니다. 레거시 YAML 1.1 리더는 `NO`과 같은 단어를 다르게 입력할 수 있지만 이 리더는 이를 문자열로 유지합니다. 이러한 차이점은 광범위한 이식성 설명을 복잡하게 만듭니다.

들여쓰기로 사용된 탭은 오류를 생성하는 반면, 인용된 JSON 문자열 내부의 탭은 이스케이프됩니다. 매우 깊거나 큰 값은 로컬 안전 한도에 도달할 수 있습니다. 이론적 언어 관계는 구현 경계를 무시하지 않습니다.

중복 키 및 레거시 파서 차이점은 상호 운용성 경계로 남아 있습니다.

이 가치 파이프라인의 경우 그 반대는 명백히 거짓입니다. YAML 주석에는 JSON 표현이 없으며 별칭은 반복 데이터로 해석되고 다중 문서 스트림은 배열이 되며 지원되지 않는 태그는 거부됩니다. 블록 스칼라는 문자열이 되지만 표현은 손실됩니다.

지원되는 YAML 문서도 유효한 JSON로 변환될 수 있으며 동일한 YAML 텍스트로 돌아가지 않습니다. 주석, 앵커, 철자 및 스트림 ID는 그렇지 않지만 일반 값에 대해서는 데이터 평등이 유지될 수 있습니다.

변환의 의미 — JSON에서 YAML로의 스타일 변경이고, YAML에서 JSON로의 번역은 정보가 손실될 수 있는 번역입니다.

JSON-to-YAML은 일반적으로 JSON 모양 입력에 대한 스타일 및 직렬화 변경입니다. YAML-to-JSON는 먼저 YAML 관련 구문을 해석한 다음 그 결과를 JSON의 더 작은 값 모델에 투영합니다. 방향이 대칭이 아닙니다.

ToolAcre는 중첩된 값, 유니코드, null, 배열 및 모호해 보이는 문자열을 포함하는 일반 JSON-YAML-to-JSON 문서를 테스트합니다. 이러한 고정 장치는 가능한 모든 JSON 또는 YAML 프로세서 쌍이 아닌 해당 데이터 클래스를 증명합니다.

작업 예: YAML로 로드된 JSON 문서 — 동일한 구조, JSON 도구가 중지되는 위치를 표시하기 위해 YAML 전용 기능이 추가됨

`{"country":"NO","items":[1,null],"nested":{"ok":true}}`을(를) YAML 입력으로 붙여넣습니다. 엄격한 판독기는 동일한 트리를 반환합니다. YAML 주석을 추가하면 주석이 사라지는 동안 값은 동일하게 유지됩니다. 반복되는 개체를 앵커 및 별칭으로 바꿉니다. JSON에는 이제 참조 구문이 아닌 복사본이 포함됩니다.

`---` 및 두 번째 문서를 추가합니다. 결과는 경고가 포함된 문서 배열이 됩니다. `!!binary` 추가; 제한된 독자는 그것을 거부합니다. 각 단계는 무시된 표현, 확인된 구조, 스트림 규칙 및 지원되지 않는 유형 등 뚜렷한 경계를 표시합니다.

여기서 다루지 않는 내용 — 스키마 수준 호환성, 여기서 타임스탬프와 같은 YAML 유형에는 JSON 대응 항목이 없습니다.

스키마 호환성은 표면 구문에만 관한 것이 아닙니다. Core는 JSON에서 경고와 함께 null로 기록하는 Infinity 또는 NaN을 생성할 수 있습니다. 타임스탬프 및 바이너리 태그는 변환되지 않고 제한된 스키마에서 거부됩니다. ToolAcre는 의도적으로 YAML을 안전한 JSON 형태의 데이터로 좁힙니다.

또 다른 YAML 구현은 추가 유형을 지원할 수 있습니다. 이로 인해 해당 지점에서 일반 JSON 값과의 호환성이 낮아지며 자동으로 좋아지거나 나빠지는 것은 아닙니다. 대상 계약 및 보안 요구 사항에 따라 선택하세요.

스키마 수준 호환성에는 이 제한된 판독기가 제한하거나 거부하는 무한한 값과 임시 태그가 포함됩니다.

일반적인 JSON 모양의 데이터는 이 YAML 1.2 리더 및 라이터를 통해 깔끔하게 전달됩니다. 모든 문서 또는 파서에 대한 광범위한 주장에는 중복 키, 스키마 버전, 태그 및 리소스 제한을 포함하는 고정 장치가 필요합니다.

구문 변환기를 사용하여 실제 텍스트를 테스트하고 경고를 읽으십시오. 실제 경계를 정확하게 만드는 파서, 스키마 및 지원되지 않는 기능의 이름을 지정한 후에만 "JSON은(는) YAML입니다"를 유용한 약칭으로 취급합니다.

이식성 테스트를 위해 하나의 픽스처를 JSON의 가치 모델 내부에 완전히 유지하고 다른 하나는 한 번에 하나의 YAML 전용 기능을 추가합니다. 각 의도된 소비자를 통해 둘 다 실행합니다. 첫 번째는 실질적인 하위 집합 주장을 측정합니다. 두 번째는 주석, 별칭, 스트림, 태그 또는 스칼라 규칙이 분기되는 위치를 정확히 식별합니다. 이 단계적 방법은 시스템이 실제로 사용하는 파서와 관련된 오류를 생성하기 때문에 두 언어가 추상적으로 하위 집합인지 묻는 것보다 더 유익합니다.