개발자 도구 · JSON 포맷터 및 유효성 검사기
JSON 검사기가 오류의 정확한 행과 열을 찾는 방법
· 작동 원리
JSON 검증 개발자 워크플로
브라우저 엔진은 JSON.parse 오류를 다르게 보고하며 일부는 문자 오프셋만 제공합니다. 이 게시물에서는 유효성 검사기가 이를 선과 열로 바꾸는 방법과 위치가 실수를 저지른 위치가 아닌 구문 분석이 중지된 위치를 표시하는 이유를 설명합니다.
아무 것도 알려주지 않는 오류 메시지 - '1432 위치에 있는 JSON의 예기치 않은 토큰'이 400줄 파일에서 쓸모없는 이유
"예기치 않은 토큰"과 같은 오류는 편집기에서 열 수 있는 위치를 제공하지 않기 때문에 긴 구성에서 실망스럽습니다. JSON.parse은 브라우저의 신뢰할 수 있는 파서이지만 해당 진단 텍스트는 JavaScript 엔진 및 버전에 따라 다릅니다. ToolAcre는 불안정한 영어 오류 문자열을 일치시켜 위치를 추측하지 않습니다. JSON.parse이 실패하면 별도의 엄격한 스캐너가 원본 텍스트를 탐색하여 JSON 문법이 허용할 수 없는 첫 번째 문자를 식별합니다.
JSON 파서가 읽는 동안 실제로 수행하는 작업 — 토큰화 및 한 번에 하나의 값을 사용하는 재귀 하강 문법 살펴보기
JSON에는 중괄호, 대괄호, 콜론, 쉼표 등 6개의 구조 문자와 문자열, 숫자, 배열, 개체, true, false 또는 null이 될 수 있는 값이 있습니다. 스캐너는 쉼표를 구분 기호로 호출하기 전에 해당 문자열이 따옴표로 묶인 문자열 안에 있는지 알아야 합니다. {"note":"A,B"}에는 두 개가 아닌 하나의 값이 있습니다. 값이나 객체 멤버를 단계별로 살펴보고 다음에 합법적으로 따라올 수 있는 항목을 확인합니다. RFC 8259는 이 문법을 정의하며 JavaScript 객체 리터럴과 달리 주석이나 후행 쉼표를 허용하지 않습니다.
문자 오프셋에서 줄 및 열까지 — 실패 오프셋까지 개행 계산 및 CRLF 종료 및 다중 바이트 문자로 인해 계산이 복잡해지는 이유
스캐너는 일반적으로 원래 JavaScript 문자열에서 0부터 시작하는 오프셋으로 시작합니다. 이를 유용하게 만들려면 오프셋 전에 줄 바꿈을 세고 마지막 줄에서 오류가 얼마나 떨어져 있는지 확인하십시오. CRLF는 두 줄이 아닌 하나의 시각적 줄 끝으로 처리되어야 합니다. JavaScript 문자열의 위치는 디스크의 UTF-8 bytes이 아닌 UTF-16 코드 단위를 계산합니다. BMP가 아닌 이모티콘은 하나의 문자 모양을 시각적으로 표시하는 편집기에서 두 개의 코드 단위를 차지할 수 있습니다. UI는 행, 열 및 발췌문을 보고하므로 붙여넣은 파일과 비교하여 캐럿을 확인할 수 있습니다.
구문 분석이 중지되는 곳이 실수가 있는 곳이 아닌 경우 — 누락된 쉼표가 다음 키에 보고되고 잘못된 따옴표로 인해 오류가 여러 줄 아래로 내려갈 수 있습니다.
첫 번째 불가능한 토큰은 원래 실수 이후에 나타나는 경우가 많습니다. 객체에서 true 뒤에 쉼표를 잊어버리면 다음 속성을 시작하는 따옴표가 불법이 됩니다. 파서는 쉼표나 닫는 중괄호를 예상하고 있었습니다. 종료되지 않은 문자열로 인해 이후 줄 바꿈이나 입력 끝 부분에 오류가 나타날 수 있습니다. 누락된 구분 기호를 찾으려면 보고된 지점부터 거꾸로 읽어보세요. 캐럿 아래의 문자를 삭제해야 한다고 가정하지 마세요.
작업한 예: 쉼표가 하나 누락된 구성 — 보고된 위치, 주변 토큰 및 실제 원인을 향해 뒤로 걸어가는 방법
문자 그대로 세 줄로 된 문서 {"name":"demo", 두 번째 줄에 "enabled":true, 세 번째 줄에 "port":8080}가 옵니다. true 뒤에 쉼표는 없습니다. ToolAcre는 3행, 1열, 오프셋 31을 보고합니다. 이전 속성 뒤에 쉼표 또는 }가 있어야 하며 "port"의 첫 번째 따옴표 아래에 캐럿이 표시됩니다. 두 번째 줄 끝에 쉼표를 삽입한 후 다시 확인하세요. 이는 첫 번째 구문 장애에 대한 진단이지 "포트"라는 단어가 잘못되었다는 판단이 아닙니다.
브라우저 엔진의 차이점 - V8, SpiderMonkey 및 JavaScriptCore는 동일한 오류를 다르게 표현하므로 일관된 행 및 열 보고서가 도움이 됩니다.
V8, SpiderMonkey 및 JavaScriptCore는 동일한 JSON.parse 실패에 대해 서로 다른 표현과 때로는 서로 다른 상황별 스니펫을 사용했습니다. ToolAcre의 스캐너는 기본 파서가 값을 거부할 때 자체 구조적 이유와 위치를 제공합니다. 스캐너가 JSON.parse에 동의하지 않으면 도구는 위치를 조작하는 대신 엔진 오류를 반환합니다. 이러한 대체 방법은 추측된 문자를 자신 있게 가리키는 것보다 안전합니다.
이것이 다루지 않는 것 — 구문 검사기가 플래그를 지정하지 않는 잘못된 유형, 누락된 필드 또는 스키마 위반과 같은 의미론적 문제
구문상 유효한 객체가 애플리케이션에 여전히 잘못될 수 있습니다. 누락된 필수 필드, 텍스트로 작성된 연령, 두 개의 중복 키 또는 존재하지 않는 파일에 대한 참조는 자동으로 잘못된 JSON이 아닙니다. RFC 8259에서는 상호 운용성을 위해 멤버 이름이 고유해야 한다고 명시하고 있지만 단순한 구문 분석만으로는 API 스키마를 적용할 수 없습니다. 여기에서 구문을 검증하고 문서를 사용하는 프로그램의 의미 제약 조건을 검증하세요.
요약: '문법이 허용할 수 없는 첫 번째 토큰'으로 위치를 읽고 JSON 포맷터 및 유효성 검사기가 텍스트를 업로드하지 않고 해당 행과 열을 보고하는 방법
보고된 위치를 "이 문법이 받아들일 수 없는 첫 번째 토큰"으로 처리합니다. 원인을 파악하고 한 가지 문제를 수정한 후 다시 실행하세요. JSON 포맷터 및 유효성 검사기는 붙여넣은 구성을 업로드하지 않고 로컬에서 이 작업을 수행합니다. 오프라인 편집자가 파일을 대신 진단할 수 있는 경우 실제 프로덕션 자격 증명을 공개 웹사이트에 붙여넣지 마십시오.