개발자 도구 · 구문 변환기
YAML에서 JSON 유형 강제: 예, 아니오 및 0777의 의미 변경 방법
· 작동 방식
YAML JSON 데이터 형식
YAML는 따옴표가 없는 스칼라를 유형으로 해석하며 규칙은 YAML 1.1와 1.2 간에 다릅니다. 이 게시물은 변환기가 값이 부울, 정수, 부동 소수점 또는 문자열인지 결정하는 방법과 결과를 제어하는 방법을 정확하게 보여줍니다.
true로 돌아온 값 — 텍스트를 의미하는 일반 YAML 스칼라가 부울로서 JSON로 변환되고 그 후 오작동하는 서비스
`NO`과 같은 값은 YAML 1.1 로더에서 false가 될 수 있지만 이 변환기가 제공하는 것은 아닙니다. 두 ToolAcre 선택 모두 YAML 1.2 스키마를 사용하므로 `NO`, `yes`, `no`, `on` 및 `off`는 문자열로 유지됩니다. 이 패널이 `NO`을 true 또는 false로 전환한다고 주장하는 예는 테스트된 동작과 반대되는 결과를 가르치기 때문에 수정된 시작이 중요합니다.
유형의 놀라움이 여전히 존재합니다. 기본 JSON 스키마에서 `null`은 null이고 `~`, 빈 값 및 `0o755`은 문자열로 유지됩니다. Core를 선택하면 이 세 가지 형식이 null, null 및 493로 변경됩니다. 출력은 모든 일반 YAML 토큰이 명확한 유형을 전달하는 것처럼 가장하는 대신 확인된 JavaScript 값을 노출하기 때문에 정확하게 유용합니다.
YAML 1.2 아래에 텍스트를 유지한 값
js-yaml이 소스를 읽는 동안 암시적 해결이 발생합니다. 선택한 제한된 스키마는 변환기가 JSON을 쓰기 전에 일반 스칼라가 null, 부울 또는 숫자 형식과 일치하는지 여부를 결정합니다. 인용하면 해당 결정을 무시할 수 있습니다. `"0o755"`은 두 스키마 모두에 있는 텍스트이고 블록 스칼라는 잘게 자르기 표시로 표시되는 줄 바꿈을 포함하는 문자열로 유지됩니다.
이는 정규식 대체가 아닌 구문 분석 및 직렬화입니다. 리더는 문자열, 숫자, 부울, null, 배열 및 개체를 만듭니다. 그런 다음 `JSON.stringify`는 선택한 들여쓰기로 해당 값을 내보냅니다. 주석과 토큰 철자는 이미 쓰기 단계에서 사라졌으므로 어떤 직렬 변환기도 숫자가 원래 소수인지 아니면 다른 허용된 YAML 표기법으로 쓰여졌는지 재구성할 수 없습니다.
YAML 1.1 규칙 — 예/no/on/off 부울, 0777은 8진수, 1:30는 60진수, 1.10과 같은 버전 문자열은 부동 소수점으로 읽습니다.
개요에는 60진수 시간 및 레거시 8진수와 같은 YAML 1.1 강제가 나열되어 있습니다. 관련 호환성 위험이 있지만 여기서는 사용할 수 있는 모드가 아닙니다. ToolAcre는 의도적으로 1.1 스키마를 제공하지 않습니다. 해당 UI에는 배송된 옵션 중 어느 것도 `NO`을 false로 읽지 않으며 테스트에서 해당 국가 코드와 단어 yes, no, on 및 off를 문자열로 고정한다고 나와 있습니다.
해당 경계는 디버깅 방법을 변경합니다. 다른 응용 프로그램이 해당 단어를 부울로 변환하는 경우 동일한 출력을 기대하는 대신 해당 구문 분석기 구성을 ToolAcre와 비교하십시오. 변환기는 자체 두 스키마가 생성하는 내용을 보여줄 수 있습니다. 나중에 파일을 사용하는 CI 실행기, 프레임워크 또는 배포 시스템에서 사용하는 스키마나 버전을 인증할 수는 없습니다.
YAML 1.1 강제는 이 변환기가 피하는 위험입니다.
기본 JSON 스키마는 JSON 모델과 호환되는 스칼라 철자만 허용합니다. Core는 친숙한 YAML null 형식, 16진수 및 8진수 정수, Infinity 및 NaN을 추가합니다. Core는 여전히 제한된 로더 내에 있습니다. 언어별 객체 태그, 날짜, 세트, 순서가 지정된 맵 및 바이너리 태그는 생성되기보다는 거부됩니다.
Infinity와 NaN은 또 다른 경계를 드러냅니다. JavaScript는 이를 보유할 수 있지만 JSON은 이를 작성할 수 없습니다. 변환기는 각 경로를 식별하고 값이 null이 됨을 경고합니다. 이는 무손실 변환이 아니라 인정된 손실 단계입니다. 따옴표 붙은 `.inf`은 값이 리터럴 문자열 `.inf`로 유지되므로 이를 방지합니다.
제공된 두 개의 YAML 1.2 스키마는 문서화된 스칼라 형식에서만 다릅니다.
`tilde: ~`, `empty:`, `octal: 0o755`, `country: NO` 및 `answer: yes`을(를) 붙여넣습니다. 엄격하게 선택한 경우 JSON 값은 `"~"`, `""`, `"0o755"`, `"NO"` 및 `"yes"`입니다. Core를 선택하면 처음 세 가지 변경 사항만 변경됩니다. 물결표와 공백은 null이 되고 8진수는 493이 됩니다. 국가 및 답변은 두 출력 모두에 텍스트로 유지됩니다.
이제 모든 값을 인용하고 반복하세요. 소스가 의도한 유형을 명시하므로 두 스키마 모두 문자열을 반환합니다. 이 비교는 코드가 정확하며 1.1을 로드하지 않는 도구 내에서 YAML 1.1을 1.2와 대조하는 것보다 더 유용합니다. 또한 문서만으로는 추측하지 않고 다른 파서를 확인할 수 있는 검토 가능한 장치를 제공합니다.
작업된 예: ToolAcre의 strict 및 Core 스키마 아래에 있는 파일 1개
명시적 표준 태그는 제한된 스키마가 이를 인식하는 경우에만 허용됩니다. `!!str 123`은 문자열 `123`이 되고 `!!int "7"`는 숫자 7이 됩니다. `!!binary`, `!!timestamp`, `!!set`, `!!js/function`와 같은 태그 및 Python 개체 생성자는 거부됩니다. 이렇게 하면 YAML 판독기가 임의 개체 팩토리가 되는 것을 방지할 수 있습니다.
구성 값이 단지 입력된 것처럼 보일 때 인용은 이식 가능한 선택으로 남아 있습니다. 다른 도구에서 살아남은 명시적인 태그에 의존하지 않고 선행 0, 버전 철자 및 감시 단어를 보존합니다. JSON 결과는 선택한 유형을 표시하지만 해당 값을 생성한 인용 스타일이나 태그를 전달할 수 없습니다.
여기서 다루지 않는 내용 — 결과 JSON의 애플리케이션 수준 구문 분석으로 유형을 다시 강제 변환할 수 있습니다(예: 문자열 '1'을 숫자로).
애플리케이션 코드는 결과 JSON을 다시 강제할 수 있습니다. API는 `"1"`을 읽고 이를 숫자로 변환하거나 스키마에 대해 거부할 수 있습니다. JSON 텍스트를 생성한 후 구문 변환기가 중지됩니다. 프레임워크 유효성 검사기, 환경 변수 로더 또는 비즈니스 규칙을 실행하지 않습니다. 따라서 깔끔한 변환은 최종 서비스에서 승인되는 것이 아니라 구문과 매핑을 증명합니다.
중복 YAML 키는 별도의 문제입니다. ToolAcre는 마지막 값을 유지하고 위치와 함께 반복되는 키를 보고합니다. 다중 문서 스트림은 배열이 됩니다. 이러한 선택은 모든 스칼라 유형이 예상되는 경우에도 애플리케이션이 보는 내용을 변경할 수 있으므로 형식이 지정된 JSON 본문만 판단하기보다는 경고를 읽어보세요.
요약: 기계가 잘못 읽을 수 있는 내용을 인용하세요. 그리고 브라우저에서 YAML을 JSON로 변환하면 각 스칼라가 어떻게 해석되었는지 정확히 알 수 있습니다.
머신 토큰과 유사한 텍스트를 인용한 다음 JSON 유형을 검사합니다. 가장 작은 JSON 모양의 스칼라 어휘를 원할 때는 strict를 사용하세요. YAML null 및 숫자 형식이 필요한 경우 의도적으로 Core를 선택하십시오. 두 옵션 모두 YAML 1.1가 아니며 다운스트림 소비자가 동일한 규칙을 따르도록 하지 않습니다.
패널은 파서 선택 사항을 표시하고 대상이 나타낼 수 없는 값에 대한 경고를 반환합니다. 이것이 정직한 약속입니다. 이 구현이 각 스칼라를 어떻게 해결했는지 보여줍니다. 보편적인 YAML 동작을 주장하지 않으며 왕복을 통해 주석, 태그 및 철자를 보존하지 않습니다.