개발자 도구 · JSON 포맷터 및 유효성 검사기
JSON의 표준 기록: RFC 4627에서 RFC 8259 및 ECMA-404까지
· 배경
JSON 표준 검증
JSON은 두 표준 기관에서 최소 4번 지정되었습니다. 이 게시물은 Douglas Crockford의 json.org에서 RFC 8259 및 ECMA-404까지의 경로를 추적하고 그 과정에서 개발자가 실제로 변경한 사항을 설명합니다.
내 파서는 어떤 사양을 따르고 있나요?
파서는 어떤 사양을 따르나요? 대답은 일반적으로 일반 개체나 배열이 아닌 가장자리에서 볼 수 있습니다. `"ready"`, 선행 바이트 순서 표시, 중복된 멤버 이름 및 비정상적으로 큰 숫자와 같은 최상위 문자열을 테스트합니다. 다양한 문서에서는 다양한 수준의 구문과 상호 운용성을 논의하고 구현에서는 자체 데이터 유형과 오류 동작을 추가합니다. 표준 이름을 지정하는 것은 관찰된 파서 계약이 모든 JSON 구현에 대한 가정과 별도로 유지되는 경우에만 유용합니다.
ToolAcre에 대한 저장소 증거는 일반 표준 기록보다 구체적이고 좁습니다. 포맷터는 `JSON.parse`을 사용하여 값을 생성하고 `JSON.stringify`을 사용하여 값을 내보냅니다. 구문 분석 실패 후 로컬 스캐너는 안정적인 진단 위치와 이유를 제공합니다.
json.org 및 JSON에 대한 초기 설명
json.org는 JSON을 JavaScript의 객체 리터럴 구문에서 파생된 간결한 표기법으로 제시하고 핵심 구조를 작은 문법으로 문서화했습니다. 이러한 초기 설명은 개발자에게 객체, 배열, 문자열, 숫자, 부울 및 null에 대한 공유 이름과 참조를 제공하는 데 도움이 되었습니다. 여기에 인용된 역사적 증거 없이 한 페이지나 사람이 혼자서 형식을 발견했거나 채택했다고 주장하는 것보다 페이지를 초기 공개 설명으로 설명하는 것이 더 안전합니다.
현재 저장소 소스에는 json.org의 보관 기록, 브라우저 사용 또는 위원회 토론이 포함되어 있지 않습니다. 오늘 이 애플리케이션이 JSON을(를) 구문 분석하고 진단하는 방법을 보여줍니다. 따라서 이 기사의 역사적 진술은 날짜가 지정된 표준 문서에 가깝게 유지되며 해당 로컬 파일이 증명할 수 없는 동기나 시장 효과에 대한 귀속을 피합니다.
RFC 4627 in 2006 — 첫 번째 IETF 설명, 애플리케이션/json 미디어 유형 및 텍스트가 객체 또는 배열이어야 한다는 규칙
RFC 4627는 2006에 게시되었으며 인터넷 교환을 위한 JSON을 설명하고 `application/json` 미디어 유형을 등록했습니다. JSON 텍스트 정의에는 문자열, 숫자 및 리터럴이 해당 컨테이너 내에 값으로 존재하더라도 최상위 수준의 개체 또는 배열이 필요했습니다. 이러한 제한은 `"ready"`만 포함하는 문서가 RFC 4627의 JSON 텍스트 정의를 벗어나면서 이후 형식에서 유효한 값이 될 수 있기 때문에 유용한 역사적 차이점입니다.
이 문서에서는 당시 사용 가능한 구현의 맥락에서 인코딩 및 보안 문제도 논의했습니다. 이 저장소에 대한 변경 로그로 읽어서는 안 됩니다. ToolAcre에는 RFC 4627 호환 모드가 포함되어 있지 않으며 해당 파서 경로는 값 구성을 호스트 JavaScript 엔진에 위임합니다.
2013의 ECMA-404 — Ecma의 최소 구문 전용 표준 및 두 조직이 하나의 형식을 설명하게 된 이유
ECMA-404는 2013에 처음 게시되었으며 의도적으로 압축된 형식으로 JSON 구문을 지정합니다. 모든 네트워크 사용에 대한 완전한 교환 프로필보다는 유효한 JSON 텍스트의 문법에 중점을 둡니다. 이 범위는 ECMA-404 및 IETF 문서가 강조하는 주변 상호 운용성 지침이 서로 다르지만 동일한 기본 표기법을 설명할 수 있는 이유를 설명하는 데 도움이 됩니다. 두 개의 표준 기관이 존재한다고 해서 일반적인 사용에서 두 가지 형식이 호환되지 않는다는 의미는 아닙니다.
조직이 특정 출판 경로를 선택한 이유에 대한 주장에는 이 코드베이스 이상의 문서 소스가 필요하므로 이 기사에서는 표준 날짜로부터 위원회 동기를 추론하지 않습니다. 관련된 실용적인 요점은 RFC 8259 및 ECMA-404이 구문에 맞게 정렬되도록 고안된 반면 RFC 8259는 상호 운용 가능한 교환에 중요한 권장 사항을 제공한다는 것입니다.
RFC 7159 및 RFC 8259
RFC 7159는 2014의 RFC 4627을 대체하고 JSON 텍스트의 정의를 직렬화된 값으로 확장하여 객체 또는 배열 전용 최상위 규칙을 제거했습니다. RFC 8259는 2017의 RFC 7159를 대체했으며 일반적으로 JSON에 대해 인용되는 IETF 참조로 남아 있습니다. 폐쇄된 생태계 외부의 시스템 간에 교환되는 JSON에 대해 UTF-8이 필요하며 문법만 가장하는 것이 아니라 숫자, 중복 이름, 유니코드 및 바이트 순서 표시에 대한 상호 운용성 주의 사항을 기록하면 어디에서나 동일한 결과를 보장합니다.
최상위 `true`은 `JSON.parse`이 이를 허용하므로 ToolAcre의 최신 루트 값 규칙을 관찰하는 간단한 방법입니다. 그 결과는 이 구현의 동작을 보여줍니다. 모든 브라우저, 서버 또는 API가 더 넓은 정의를 채택한 경우 재구성되지 않습니다.
현직 개발자를 위한 변경사항
작업 중인 개발자의 경우 가장 명확한 사양 변경은 루트에서 모든 JSON 값을 현대적으로 수용하고 상호 운용 가능한 인코딩에 대한 더 강력한 지침을 제공하는 것입니다. 덜 눈에 띄는 교훈은 유효한 구문이 여전히 구현 선택 사항을 남긴다는 것입니다. 중복된 개체 이름은 축소될 수 있고, 멤버 순서는 의미 계약이 아니며, 매우 큰 숫자는 정밀도를 잃을 수 있으며, 특이한 유니코드 시퀀스는 라이브러리를 통해 다르게 이동할 수 있습니다. 따라서 표준을 준수하는 문서에는 응용 프로그램 스키마의 추가 제약 조건이 적용될 수 있습니다.
이 포맷터에서는 중복된 이름과 숫자 토큰이 먼저 `JSON.parse`을 통과하므로 나중에 형식 지정 시 원본 어휘 문서가 아닌 결과 JavaScript 값이 반영됩니다. 스캐너는 오류 발생 후 진단을 제공합니다. 중복된 멤버나 임의 정밀도 숫자는 유지되지 않습니다. 이는 저장소 기반 관찰입니다.
여기서 다루지 않는 내용
여기서 다루지 않는 것은 JSON 위에 계층화된 사양입니다. JSON 스키마는 문서 모양 및 값에 대한 제약 조건을 설명합니다. JSON 포인터는 문서 내의 위치를 지정합니다. JSON 패치는 변경 사항을 나타냅니다. 이는 기본 문법과 다른 문제를 해결하므로 JSON 자체의 최신 버전으로 취급되어서는 안 됩니다. JSONC, JSON5 및 유사한 작성 형식도 허용되는 구문을 확장하거나 변경하며 자동으로 엄격한 검증에 포함되기보다는 자체 파서가 필요합니다.
또한 이 기사에서는 JSON 채택, 브라우저 지원 또는 XML과의 경쟁에 대한 포괄적인 사회적 역사를 피합니다. 왜냐하면 나열된 저장소 소스가 해당 설명을 입증할 수 없기 때문입니다. 공백을 메우기 위해 외부 인용이 고안되지 않았습니다.
요약: RFC 8259는 인용 참조입니다.
RFC 8259는 현재 JSON 구문 및 상호 운용성 지침을 인용하기 위한 실용적인 IETF 참조이며, ECMA-404는 정렬된 Ecma 구문 표준을 제공합니다. RFC 4627 및 RFC 7159는 게시된 정의가 특히 최상위 수준에서 어떻게 변경되었는지 이해하는 데 여전히 유용합니다. 권위에 대한 모호한 호소로 "JSON 사양"을 사용하는 대신 정확한 주장을 뒷받침하는 문서를 인용하고, 특정 파서에서 관찰되는 구현 동작과 규범적인 규칙을 구별하세요.
ToolAcre의 경우 방어 가능한 진술은 저장소가 JavaScript의 JSON 구문 분석기와 직렬 변환기를 사용하고 실패 후 진단을 위해 엄격한 로컬 스캐너를 추가한다는 것입니다. 최상위 값, 잘못된 구두점 및 숫자 처리 테스트를 통해 해당 경로가 설명됩니다. 그것들은 역사적 자료가 아닙니다.