개발자 도구 · JSON 포맷터 및 유효성 검사기
한 페이지에 있는 전체 JSON 문법: 6개의 값 유형, 2개의 컨테이너
· 배경
JSON 표준 검증
JSON의 전체 문법은 한 페이지에 들어가며 이를 암기하면 모든 유효성 검사기 오류가 분명해집니다. 이 게시물에서는 6가지 값 유형, 2가지 컨테이너, 사람들을 당황하게 만드는 몇 가지 규칙을 살펴봅니다.
지금까지 본 모든 오류는 한 페이지에서 비롯됩니다.
모든 구문 오류는 간결한 문법에서 예상이 깨졌습니다. 객체가 열린 후 파서는 인용된 멤버 이름이나 닫는 중괄호를 기대합니다. 이름 뒤에는 콜론이 필요합니다. 값 뒤에는 쉼표나 컨테이너의 끝이 필요합니다. 오류를 실패한 전환으로 읽는 것이 보고된 문자를 신비한 것으로 취급하는 것보다 더 유용합니다.
ToolAcre는 표준 JSON 값과 공백을 허용한 다음 두 가지 실제 입력 제한을 적용합니다. 8,000,000 문자보다 긴 텍스트는 구문 분석 전에 거부되고, 512 컨테이너를 넘어서 중첩된 스캐너는 무기한 통과하는 대신 거부됩니다. 이는 새로운 JSON 유형이 아닌 제품 경계입니다. 그 안에서 진단은 토큰 스트림이 더 이상 문법을 충족할 수 없는 첫 번째 지점을 식별합니다.
6가지 값 — 객체, 배열, 문자열, 숫자, true/false 및 null, 그리고 그 외에는 아무것도 없다는 사실
JSON 값은 개체, 배열, 문자열, 숫자, 부울 또는 null입니다. 객체와 배열은 더 많은 컨테이너를 포함하여 6개 중 하나를 포함할 수 있습니다. 리터럴 철자는 정확히 `true`, `false` 및 `null`입니다. 대문자 사용은 유연하지 않습니다. `True`, `None`, `undefined`, `NaN` 및 `Infinity`와 같은 토큰은 다른 언어에서 일부를 인식하는 경우에도 엄격한 JSON 범위를 벗어납니다.
이 짧은 목록은 분류를 유용한 디버깅 기술로 만듭니다. `{"reading": NaN}`에서 콜론은 값을 올바르게 소개하지만 `N`에서는 허용되는 값을 시작할 수 없습니다. 데이터가 의미하는 바(예: `null` 또는 인용된 상태)를 결정한 후에만 교체하십시오. 구문 도구는 토큰을 거부할 수 있습니다. 애플리케이션의 대체 항목을 선택하거나 해당 필드가 거기에 속하는지 여부를 결정할 수 없습니다.
객체 및 배열 — 쉼표로 구분된 멤버, 콜론 및 RFC 8259이 순서를 유지하고 이름을 구현에 중복시키는 이유
개체에는 쉼표로 구분된 이름/value 구성원이 포함되어 있습니다. 모든 이름은 큰따옴표로 묶인 문자열, 그 뒤에 콜론과 값이 옵니다. 배열에는 이름이나 콜론 없이 쉼표로 구분된 값이 포함됩니다. 빈 `{}` 및 `[]` 컨테이너는 유효하지만 쉼표는 앞이나 뒤 또는 두 번 나타날 수 없습니다. 각 구분 기호를 해당 컨테이너와 일치시키면 명백한 "예기치 않은 토큰" 오류가 많이 노출됩니다.
개체 이름은 고유해야 하지만 이 유효성 검사기는 중복된 철자를 거부하지 않습니다. `{"port": 80, "port": 443}`는 구문 분석하고 `JSON.parse`은 이후 값을 유지합니다. 그러면 서식 지정 시 살아남은 멤버만 내보내므로 결과에서 이전 텍스트를 복구할 수 없습니다. 배열 위치는 다르게 동작합니다. 모든 요소는 그대로 유지되며 해당 순서는 값의 일부입니다.
문자열과 숫자를 정확하게
문자열은 큰따옴표를 사용합니다. 백슬래시는 따옴표, 백슬래시, 슬래시, `b`, `f`, `n`, `r`, `t` 또는 4자리 유니코드 이스케이프를 도입할 수 있습니다. 원시 제어 문자는 금지됩니다. 작은따옴표는 문자열 외부의 일반적인 유효하지 않은 토큰입니다. 이러한 규칙은 복사된 JavaScript 리터럴과 붙여넣은 여러 줄 텍스트가 엄격한 JSON 검증에 실패하더라도 읽을 수 있는 것처럼 보일 수 있는 이유를 설명합니다.
숫자에는 빼기 기호, 정수 부분, 선택적 분수 및 선택적 지수가 포함될 수 있습니다. `+`로 시작하거나, 16진수 표기법을 사용하거나, 다른 숫자 앞에 0을 붙이거나, 무한한 값을 입력할 수 없습니다. `-0.25e+2`은 유효합니다. `01`, `.5`, `2.` 및 `Infinity`는 그렇지 않습니다. 구문 분석은 JavaScript가 모든 숫자를 정확하게 보존할 수 있는지 여부가 아니라 문법을 확인합니다.
공백 및 최상위 수준
문자열 외부, JSON 공백은 공백, 가로 탭, 줄 바꿈 및 캐리지 리턴으로 제한됩니다. 웹페이지에서 복사한 줄바꿈 없는 공백은 일반 공백과 호환되지 않습니다. 형식화에서는 토큰 주위에 허용된 공백 중에서 자유롭게 선택할 수 있지만, 인용된 문자열 내부에 속하는 공백은 해당 문자가 데이터이기 때문에 보존해야 합니다.
전체 문서는 개체나 배열뿐만 아니라 단일 JSON 값일 수 있습니다. `42`, `false` 및 `"ready"`는 유효한 최상위 텍스트입니다. 금지된 것은 첫 번째 값 다음의 두 번째 값입니다. `42 43`는 하나가 아닌 두 개의 문서입니다. 이러한 차이는 개행으로 구분된 JSON에 전체 파일에 대한 일반적인 구문 분석이 아닌 레코드별 처리가 필요한 이유를 설명합니다.
작업 예: 작은 문서를 직접 구문 분석
`{"order": [17, null, {"paid": true}], "note": "ship soon"}`을 사용하세요. 루트 개체는 `order`이라는 멤버로 시작됩니다. 그 값은 숫자, null 및 다른 객체를 포함하는 배열입니다. 그런 다음 쉼표로 인해 `note`이 표시됩니다. 해당 값은 이스케이프된 개행 문자가 포함된 문자열입니다. 모든 콜론, 쉼표 및 닫는 구분 기호에는 하나의 문법적 역할이 있습니다.
이제 `paid` 앞의 인용문을 제거하세요. 중첩된 중괄호 뒤에 파서는 닫는 중괄호 또는 인용된 이름을 예상하므로 `p`에서 실패합니다. 또는 `true` 뒤에 쉼표를 추가하세요. 파서는 쉼표를 받아들이고 다른 멤버가 따라야 하기 때문에 `}`에서 실패합니다. 이러한 위치를 직접 예측하면 검증이 확인으로 바뀌고 무작위 구두점 편집을 방지할 수 있습니다.
여기서 다루지 않는 내용
문법에는 날짜, 소수, 이진수, UUID 또는 기간 유형이 없습니다. 애플리케이션은 일반적으로 이러한 개념을 문자열이나 숫자로 표현하고 별도로 규칙을 적용합니다. 타임스탬프는 불가능한 날짜를 포함하면서 완벽하게 유효한 JSON 문자열일 수 있습니다. 마찬가지로, 구문적으로 유효한 객체는 단일 구문 분석 규칙을 위반하지 않고도 필수 속성을 생략하거나 잘못된 단위를 사용할 수 있습니다.
ToolAcre는 스키마 검사, 도메인 유효성 검사 또는 표준화를 수행하지 않습니다. 또한 주석 및 후행 쉼표와 같은 JSON5 또는 JSONC 기능을 재해석하지 않습니다. 작업 범위는 더 좁습니다. 제품 제한 내에서 하나의 엄격한 JSON 텍스트를 허용하고, 구문 분석된 값의 형식을 지정하고, 구문 오류를 식별합니다. 소비하는 애플리케이션의 유효성 검사 계층에서 모양과 의미에 대한 이후 질문을 유지하세요.
요점: 문법을 외우고 위치를 신뢰하세요.
내구성 체크리스트는 짧습니다. 6개의 값 범주, 인용된 개체 이름, 항목 사이에만 쉼표, 이름과 값 사이에만 콜론, 엄격한 문자열 이스케이프, 엄격한 숫자 철자법, 4개의 공백 문자 및 정확히 1개의 최상위 값이 있습니다. 문서가 실패하면 보고된 위치 바로 앞에 허용되는 문법이 무엇인지 식별하고 해당 기대치를 실제로 존재하는 문자와 비교합니다.
위치를 첫 번째 불가능한 지점으로 신뢰하며 항상 삭제가 필요한 문자는 아닙니다. 앞의 쉼표가 다른 구성원을 약속했기 때문에 닫는 중괄호가 강조 표시될 수 있습니다. 첫 따옴표가 없기 때문에 무고한 편지가 강조 표시될 수 있습니다. 원인을 해결하고 유효성 검사를 다시 실행한 후 반복하세요. 크기가 너무 크거나 매우 깊은 입력의 경우 구문 진단이 도움이 되기 전에 8백만 자 또는 512 깊이의 제품 경계를 해결하세요.