개발자 도구 · JSON 포맷터 및 유효성 검사기
후행 쉼표가 깨지는 이유 JSON 및 유효성 검사기가 가리키는 위치
· 작동 방식
JSON 개발자 워크플로 검증
후행 쉼표는 가장 일반적인 JSON 실수이며 오류는 쉼표 자체에 발생하지 않습니다. 쉼표 뒤에 문법이 무엇을 기대하는지와 보고된 위치를 읽는 방법을 알아보세요.
찾는 데 10분이 걸리는 한 글자 버그
찾는 데 10분이 걸리는 한 문자 버그(손으로 편집한 구성, 마지막 속성 뒤에 쉼표가 남음, 빌드 실패). 엄격한 파서는 문서에 실제로 존재하는 토큰 시퀀스를 따릅니다. `'enabled': true,`로 끝나는 객체와 `'blue',`로 끝나는 배열을 생각해 보세요. 두 구분 기호는 다음 토큰이 컨테이너를 닫더라도 다른 항목을 약속합니다.
ToolAcre는 브라우저 엔진 메시지에서 위치를 파생하지 않습니다. JSON.parse는 먼저 유효성을 결정합니다. 실패한 후에만 저장소 스캐너가 텍스트를 탐색하고 허용되지 않는 첫 번째 문자를 보고합니다. 후행 쉼표의 경우 해당 문자는 닫는 중괄호 또는 대괄호이며 그 이유는 명시적으로 "후행 쉼표"로 표시됩니다. 개체에 인용된 다른 멤버 이름이 없습니다. 배열에 또 다른 완전한 값이 없습니다.
쉼표 뒤에 나오는 JSON 문법의 내용
JSON 문법에서 쉼표 뒤에 표시되는 내용 — RFC 8259은 쉼표를 사용하여 배열의 값과 개체의 멤버를 구분합니다. 따라서 구분 기호에는 양쪽에 유효한 항목이 필요합니다. 객체 쉼표 뒤에 파서는 큰따옴표로 묶인 이름, 콜론 및 값을 기대합니다. 배열 쉼표 뒤에는 유효한 JSON 값이 필요합니다. 닫는 구분 기호는 두 가지 생산을 모두 충족하지 않습니다.
구분 기호는 두 멤버 또는 요소 사이에 속하며 마지막 요소 뒤에 속하지 않습니다. 마지막 쉼표를 제거하면 값이나 순서가 변경되지 않습니다. 최종 값 바로 다음에 컨테이너를 닫는 문법을 복원합니다. 이것이 바로 모든 이전 항목 뒤에 문제 없이 쉼표가 나타날 수 있는 이유이기도 합니다. 각 쉼표 뒤에는 약속한 다음 항목이 옵니다.
오류가 닫는 괄호에 표시되는 이유
오류가 닫는 괄호에 있는 이유 — 컨테이너 중간에 쉼표가 허용되므로 파서가 보기만 하면 이를 거부할 수 없습니다. 구분 기호를 사용하고 상태를 변경하여 다른 이름이나 값을 예상합니다. `}` 또는 `]`이 대신 도착하는 경우에만 모순이 확실해집니다. 해당 구분 기호는 앞의 쉼표로 인해 상태 전환이 발생했음에도 불구하고 약속된 항목이 없는 것으로 판명되는 곳입니다.
따라서 보고된 구분 기호는 중괄호나 대괄호를 삭제하라는 제안이 아니라 파서 상태에 대한 증거입니다. 왼쪽에 있는 토큰 하나를 읽습니다. 해당 토큰이 쉼표이고 구분 기호가 동일한 컨테이너를 닫는 경우 쉼표를 제거하고 닫기를 유지합니다. ToolAcre의 스캐너는 후행 쉼표 조건의 이름을 지정하고 JSON.parse가 문서를 거부한 후 소스 위치를 제공합니다.
JavaScript, Python 및 최신 린터에서는 허용되지만 JSON에서는 허용되지 않습니다.
JavaScript, Python 및 최신 린터에서는 허용되지만 JSON에서는 허용되지 않습니다. 소스 언어 리터럴은 재정렬된 줄과 향후 추가 항목을 더 쉽게 검토할 수 있도록 하기 때문에 종종 마지막 항목 뒤에 쉼표를 허용합니다. 포맷터는 해당 스타일을 삽입하거나 보존할 수도 있습니다. 이러한 편리함은 각 언어 문법에 속합니다. `.js` 개체 리터럴 또는 Python 사전은 유효한 소스가 될 수 있지만 RFC 8259 JSON 문서에서는 동일한 표시 구두점이 유효하지 않은 상태로 유지됩니다.
JavaScript용으로 구성된 편집기는 붙여넣은 조각이 쉼표로 끝나는 경우 결과적으로 경고를 표시하지 않을 수 있습니다. 대상 구문 분석기는 여전히 승인을 제어합니다. `.json` 텍스트에 JSON 언어 모드를 사용하고 API 또는 구성 필드로 전송된 정확한 페이로드를 확인하세요. 소스 파일, linter 또는 JSON5 파서의 관대함은 엄격한 JSON 소비자에 대한 양도 가능한 증거가 아닙니다.
실제 예: 한 파일에 세 개의 후행 쉼표가 있습니다.
작업된 예: 하나의 파일에 세 개의 후행 쉼표가 있습니다. `features`이 `"beta",`로 끝나고, 포함 개체가 `"enabled": true,`로 끝나고, 두 번째 루트 구성원도 같은 실수를 한다고 가정합니다. 첫 번째 유효성 검사는 `beta` 뒤의 닫는 괄호에서 중지됩니다. 해당 쉼표를 제거하면 `true` 뒤의 닫는 중괄호까지 구문 분석이 계속되고 두 번째 위치를 복구하면 나머지 루트 수준 개체 오류가 표시됩니다.
파서가 일반적으로 이후의 모든 결함이 아니라 연속이 불가능한 첫 번째 지점을 보고하기 때문에 이 순서가 예상됩니다. 각 줄과 열을 닫는 구분 기호에 매핑하고 바로 앞의 구분 기호를 검사한 다음 의도적으로 변경하고 유효성 검사를 다시 실행합니다. 모든 쉼표를 일괄 삭제하지 마세요. 실제 이웃 간의 구분 기호가 필요합니다. 유효성 검사를 반복하면 동일한 문서 전체에서 유효하지 않은 끝 쉼표 3개와 유효한 쉼표가 구별됩니다.
동일한 오류를 생성하는 변형
관련 구분 기호 오류를 생성하는 변형(선행 쉼표, 연속된 두 개의 쉼표, 루트 값 뒤의 쉼표)은 모두 동일한 문자를 오용하지만 서로 다른 파서 상태를 위반합니다. 선행 쉼표의 왼쪽에는 완성된 항목이 없습니다. 연속적인 쉼표는 구분 기호 사이에 항목을 제공하지 않습니다. JSON 텍스트가 이미 유효한 끝에 도달한 후에 전체 루트 값 뒤에 쉼표가 나타납니다.
이러한 사례에는 자동으로 후행 쉼표가 표시되어서는 안 됩니다. 정확한 이유는 위치와 컨테이너 상태에 따라 다릅니다. `{"a":1,,"b":2}` 내에서 두 번째 쉼표는 인용된 멤버 이름이 시작되어야 하는 위치에 예상치 못한 것입니다. `[ ,1]`에서는 값이 필요한 위치에 첫 번째 쉼표가 나타납니다. 닫는 구분 기호 패턴 외부에서 보편적인 "이전 쉼표 삭제" 규칙을 적용하는 대신 진단 및 주변 토큰을 검사하십시오.
여기서 다루지 않는 내용
여기서 다루지 않는 내용 - JSON5 및 일부 JSON 주석 포함 워크플로는 의도적으로 후행 쉼표를 허용합니다. 해당 문법 중 하나에 대해 작성된 파일은 선언된 파서, 확장 및 도구를 사용해야 합니다. 이를 엄격한 JSON로 취급하면 반드시 작성 실수가 아닌 형식 불일치를 반영하는 오류가 발생합니다. 반대로, 허용되는 파서로 이를 수락한다고 해서 소스가 엄격한 JSON 엔드포인트로 안전하게 전송되는 것은 아닙니다.
단지 이 진단을 침묵시키기 위해 파서를 변경하면 허용되는 언어가 변경되고 최종 소비자와의 비호환성을 숨길 수 있습니다. 주석, 따옴표가 없는 이름 및 작은따옴표로 묶인 문자열은 확장 형식에서 후행 쉼표를 동반할 수 있으므로 텍스트가 경계를 넘을 때 추가적인 오류가 발생할 수 있습니다. 먼저 대상 계약을 확인하십시오. JSON이라고 표시되면 확장 구문을 제거하세요. JSON5 또는 JSONC라고 표시된 경우 정확한 형식을 구현하는 도구를 사용하여 유효성을 검사하세요.
요약: 보고된 위치 왼쪽에 있는 토큰 하나를 살펴보세요.
요약: 보고된 위치 왼쪽에 있는 토큰 하나를 확인하세요. 캐럿이 `}` 또는 `]` 아래에 있으면 앞의 쉼표는 아직 도착하지 않은 멤버나 요소를 약속했을 수 있습니다. 구조적으로 필요한 닫는 구분 기호를 유지하고 해당 터미널 구분 기호만 제거합니다. 그런 다음 전체 문서의 유효성을 다시 검사하십시오. 첫 번째로 복구된 위치에서 이후 컨테이너의 또 다른 후행 쉼표가 발견될 수 있기 때문입니다.
ToolAcre는 책임을 좁게 유지합니다. JSON.parse는 문서가 유효하지 않다고 결정하고 로컬 스캐너는 실패 후 줄과 열과 함께 안정적인 구조적 이유를 제공합니다. 강조 표시된 문자를 따로 비난하기보다는 해당 좌표를 사용하여 파서 컨텍스트를 검사하십시오. 후행 쉼표는 한 문자 편집이지만 다음 구분 기호에 오류가 나타나는 이유를 이해하면 개체, 배열 및 깊게 중첩된 구성 전체에서 동일한 진단을 신뢰할 수 있습니다.