나는 짓는다 Toolz.dev그리고 그 전에 나는 워드 프레스 플러그인과 라라벨 API 를 배송 년 보냈다. 그 모든에서,내가 가장 시간을 낭비 한 단일 오류 메시지는 " 의 일부 변형입니다;JSON 에서 예상치 못한 토큰 위치 428." 그것은 거의 아무것도 알려줍니다. 아무 줄도,아니 열,그리고 그것이 이름을 지정하는 위치는 자주 잘못 된 일을 지나 몇 문자. 당신은 손으로 축소 된 blob 에 문자를 계산하거나,편집기에 전체 페이로드를 붙여넣고 눈을 가늘게 뜨고있다. 나는 구축 JSON 검증인 그래서 다시는 그렇게 할 필요가 없으며, 이것이 그것이하는 일과 JSON을 검증하는 것이 보이는 것보다 까다로운 이유에 대한 가이드입니다.
TL;DR: JSON 유효성 검사기는 RFC 8259 의 문법에 대해 텍스트를 검사하고 텍스트가 깨졌을 때 예상한 대로 표현된 첫 번째 오류의 정확한 줄,열 및 문자를 알려줍니다. 또한 일반 파서가 숨기는 것들을 포착합니다: 마지막 값까지 조용히 축소되는 중복 키,유효한 문서의 구조 (객체,배열 및 키 개수,중첩 깊이 및 바이트 크기) 를 보고하는 포맷터가 아닙니다. 포맷터는 입력이 이미 유효하다고 가정합니다; 유효성 검사기는 그렇지 않을 때 정확하게 도달하는 것입니다.
JSON이 유효하다는 것은 무엇을 의미합니까?
JSON 은 문법이 엄격한 작은 형식입니다. 현재 표준은 RFC 8259와 일치합니다 ECMA-404그리고 그 사이에 유효한 문서에 포함될 수 있는 내용을 정확하게 정의합니다. JSON 텍스트는 단일 값입니다. 해당 값은 객체,배열, 문자열,숫자, 입니다 true, false, 또는 null. 개체는 중괄호로 감싸져 있으며 쉼표로 구분되어 있습니다 "key": value 쌍. 배열은 괄호로 감싸고 쉼표로 구분된 값을 유지합니다. 문자열은 큰따옴표로 감싸고 절대 작은따옴표가 없습니다. 숫자는 앞에 오는 0 이 없고 뒤에 오는 소수점도 없는 특정한 모양을 따릅니다. 주석이 없고 뒤에 오는 쉼표도 없습니다.
그 마지막 문장은 대부분의 실제 JSON 이 잘못되는 곳입니다. 왜냐하면 많은 JSON 사람들이 손으로 쓰는 것은 실제로 JSON 이 아니기 때문입니다. 와 함께 config 파일입니다 // 주석,또는 작은 따옴표와 뒤에 오는 쉼표가 괜찮은 JavaScript 소스에서 복사된 개체,또는 누군가가 필드를 추가하고 매달려 있는 쉼표를 남긴 손으로 편집한 고정물. 그 모든 것은 엄격한 파서에 의해 거부되며 validator's 작업은 어깨를 으쓱하는 것이 아니라 특정 지점에서 거부하는 것입니다.
정리할 가치가 있는 한 가지 점은 몇 년 전에 JSON을 배운 사람들을 놀라게 하기 때문입니다: 맨값은 완전하고 유효한 JSON 문서입니다. 42 그 자체로 유효한 JSON 입니다. 그래서 "hello", 그리고 그렇습니다 true. 오래된 RFC 4627 최상위 레벨이 객체 또는 배열이어야 했지만 RFC 7159 (이후 8259) 가 이를 대체하면서 2014 년에 해당 제한이 삭제되었습니다. 도구가 알려주는 경우 42 유효한 JSON이 아닙니다. 해당 도구는 10년 넘게 사용되지 않은 사양을 따르고 있습니다.
JSON.parse 가 왜 그렇게 나쁜 오류 리포터입니까?
전용 검증자가 그 자리를 차지하는 이유는 귀하의 언어에 내장된 파서가 슬픈 경로를 설명하기 위한 것이 아니라 행복한 경로에 최적화되어 있기 때문입니다. JSON.parse 브라우저에서 다음을 던집니다 SyntaxError 누구의 메시지는 엔진 특정이며 일반적으로 줄이나 열이없는 문자 오프셋을 제공합니다. V8 은 "예기치 않은 토큰}을 JSON 의 위치 148." Firefox 는 "JSON.parse: 1 줄의 예기치 않은 문자 149." Safari 는 다시 다른 것을 말합니다. 그들 중 누구도 그들이 기대했던 것을 말하지 않으며 위치는 문자열의 시작부터 측정되며 JSON 이 두 줄 이상을 갖는 순간 쓸모가 없습니다.
Toolz.dev의 유효성 검사기는 사용하지 않습니다 JSON.parse니다. 그것은 손으로 쓴 재귀 하강 파서로 텍스트 자체를 산책,그대로 라인과 열을 추적,그래서 중지 할 때 그것은 당신에게 모든 세 가지 좌표를 건네 수: 라인,열, 절대 문자 오프셋. 더 중요한 것은,그것은 문법 규칙을 알고의 중간에 있었다,그래서 메시지가 특정. 대신 "unexpected token," 당신이 "추적 쉼표는 닫는 중괄호 전에 허용되지 않습니다," 또는 "객체 키는 이중 인용 문자열이어야합니다," 또는 "객체 멤버 후 쉼표 또는 닫는 중괄호를 예상." 그 차이는 5 초 안에 파일을 고정하고 그것을 사냥 사이의 차이입니다.
또한 컴파일러가 하는 방식대로 문제가 되는 줄의 정확한 문자 아래에 캐럿을 그립니다. config 파일의 34 줄을 볼 때 "column 12"는 괜찮지만 a ^ 길 잃은 인용문 바로 아래에 앉는 것이 더 빠릅니다.
검증자가 이름으로 잡는 JSON 실수는 무엇입니까?
이것들은 제가 가장 자주 보는 실패입니다. 제 자신의 작업과 이와 같은 도구에 대한 지원 스레드 모두에서요. 유효성 검사기는 일반적인 토큰 오류를 보고하는 대신 각각의 이름을 지정합니다.
| 실수 | 어떻게 생겼는지 | 무효인 이유 |
|---|---|---|
| 후행 쉼표 | {"a": 1,} 또는 [1, 2,] |
JSON에는 후행 쉼표가 없습니다; standard's 문법은 단순히 닫는 중괄호나 괄호 앞에 쉼표를 허용하지 않습니다 |
| 작은 따옴표 | {'name': 'Liton'} |
문자열과 키는 큰따옴표를 사용해야 합니다; 작은따옴표는 JSON이 아니라 JavaScript 습관입니다 |
| 누락된 쉼표 | {"a": 1 "b": 2} |
첫 번째 멤버 이후의 모든 멤버 앞에는 쉼표가 와야 합니다 |
| 코멘트 | {"a": 1} // note |
JSON에는 주석 구문이 없습니다; 그만큼 // 그리고 그 이후의 모든 것은 예상치 못한 내용이다 |
| 인용되지 않은 키 | {name: "Liton"} |
키는 문자열이므로 JavaScript 개체 리터럴과 달리 인용해야 합니다 |
| 선두 제로 | {"n": 007} |
숫자에 선행 영점이 없을 수도 있습니다 007 유효하지 않습니다; 쓰다 7 |
| 소수점 뒤 | {"n": 5.} |
소수점 뒤의 분수에는 최소한 한 자리가 필요합니다 |
| 원시 제어 문자 | 문자열 안의 리터럴 탭 또는 개행 | 문자열 안의 제어 문자는 as로 이스케이프되어야 합니다 \t, \n등등 |
| NaN 또는 무한대 | {"n": NaN} |
이것들은 자바스크립트에서 유효하지만 JSON 값은 아닙니다 |
| 종료되지 않은 문자열 | {"a": "oops} |
닫는 따옴표가 없는 문자열은 입력의 끝까지 실행됩니다 |
이들 모두는 평어 메시지와 위치를 생성합니다. 선행 0의 경우는 특수 목적으로 구축된 파서가 도움이 되는 이유를 보여주는 좋은 예입니다: 일반 파서는 읽습니다 007 숫자로 0 그리고 여행을 떠납니다 7 "추가 콘텐츠,"을 가리키며 7를, 진짜 문제가 앞에 있는 두 개의 0 일 때, 유효성 검사기는 먼저 선행 0 패턴을 확인하고 직접 알려줍니다.
중복 키는?
여기 어떤 구문 오류보다 생산에서 나를 물린 하나가 있습니다. 왜냐하면 그것은 전혀 구문 오류가 아니기 때문입니다. 이것은 유효한 JSON:
{
"timeout": 30,
"retries": 3,
"timeout": 60
}
RFC 8259 는 객체 "SHOULD be unique," 내의 이름을 말하지만 중복을 금지하지 않으므로 파서가이를 수락해야합니다. 다음에 일어나는 일은 문제가 시작되는 곳입니다: 표준은 중복 된 이름을 가진 동작을 예측할 수 없다고 말하며 실제로 거의 모든 파서는 마지막 값을 유지하고 이전 값을 자동으로 삭제합니다. 그래서이 객체는 구문 분석합니다 {"timeout": 60, "retries": 3}, 그리고 "timeout": 30 파일 상단에 신중하게 설정한 내용이 경고 없이 사라졌습니다. 두 사람이 구성을 편집했거나 병합이 잘못되었거나 템플릿 단계에서 동일한 키가 두 번 방출된 경우 파서가 표시되지 않는 버그가 있습니다.
유효성 검사기가 플래그를 지정합니다. Duplicate-key 감지가 기본적으로 켜져 있고,duplicate 가 합법적이기 때문에 오류가 아닌 경고로 보고됩니다: 문서는 여전히 유효하지만,같은 객체에 두 번 이상 나타나는 모든 키에 대해 해당 줄과 a 로 알려줍니다 JSON 포인터 중첩된 구조 내에서 찾을 수 있는 경로입니다. 진심으로 중복을 원한다면 수표를 끌 수 있습니다. 대부분의 경우 경고를 보는 것은 무엇이 잘못되었는지 깨닫는 순간입니다.
유효성 검사기는 포맷터와 어떻게 다른가요?
사람들은 단어를 혼용하며,도구는 겹치지만,서로 다른 질문에 답한다. A JSON 포맷터 이미 유효하다고 생각하는 JSON 을 가져와 일관된 들여쓰기로 다시 인쇄하므로 사람이 읽을 수 있습니다. 포맷터 깨진 JSON 을 건네면 가장 좋은 방법은 거절하는 것입니다. validator's 전체 목적은 깨진 케이스입니다: 어디서 왜 그런지 알려줍니다. Toolz.dev validator 는 두 작업을 모두 수행합니다. 왜냐하면 일단 문서가 유효하다는 것을 확인하면 이미 구문 분석 했으므로 결과를 동일한 패스로 예쁘게 인쇄하기 때문입니다. 그러나 헤드 라인 기능은 들여쓰기가 아닌 진단입니다.
이웃 도구와도 동일한 관계가 유지됩니다. 그만큼 JSON 미니피겨 유효한 입력에서만 의미가 있는 페이로드를 축소하기 위해 공백을 제거합니다. The JSON 분류기 유효한 입력에서 안정적인 diffs에 대한 키를 다시 정렬합니다. 그만큼 JSON 탈출 및 탈출 해제 도구는 문자열 안에 JSON 을 임베딩하는 것을 다룹니다. 그리고 the JSONPath 테스터 쿼리 이미 확인 한 문서는 잘 형성되어 있습니다. 검증은 그들 모두 전에 오는 단계입니다,왜 API 응답 또는 구성 파일이 이상하게 동작 할 때마다 내가 먼저 실행하는 것입니다. 이 함께 맞는 방법에 대한 광범위한 투어가있다 the JSON 도구에 대한 궁극적 인 가이드.
구조 통계는 무엇을 말해주는가?
문서가 유효성을 검사하면 도구는 그 모양을 보고합니다: 포함된 개체와 배열 수,키 수,문자열, 숫자,부울 및 널 수,얼마나 깊이 중첩되어 있는지,문자와 UTF-8 바이트 모두에서 크기가 장식이 아닙니다. 익숙하지 않은 API 응답을 건네 받으면 깊이 숫자는 플랫 레코드를 다루고 있는지 또는 깊이 중첩된 트리를 다루고 있는지 한눈에 알 수 있으며 키 수는 대략 얼마나 많은 작업 구문 분석이 될지 알려줍니다.
바이트 수치는 사람들이 기대하는 것보다 더 중요합니다. 요청 크기 제한,메시지 큐 제한,데이터베이스 열 제한은 거의 항상 문자가 아닌 바이트 단위로 측정되며 JSON 에 ASCII 외부의 내용이 포함된 순간 두 가지가 다릅니다. 이모티콘 또는 악센트 이름은 화면에서는 한 문자이지만 와이어에서는 두 개,세 개 또는 네 바이트입니다. 페이로드가 256KB 제한과 충돌하는 경우 문자 수는 오도되고 바이트 수는 그렇지 않습니다. 유효성 검사기는 실제 UTF-8 바이트 길이를 계산하므로 표시되는 숫자는 제한이 계산하는 숫자입니다.
내가 사용하는 방법
내 워크 플로우는 지루하고 빠르며 요점이 있습니다. 통합이 중단되면 네트워크 탭에서 직접 원시 응답 본문을 복사하여 유효성 검사기에 붙여 넣습니다. 유효하면 녹색 결과와 통계는 문제가 데이터가 아닌 내 코드의 다른 곳에 있다고 말하고 2 초 만에 전체 원인 클래스를 배제했습니다. 유효하지 않은 경우 줄과 열을 가져와 수정하고 계속 진행합니다. 구성 파일을 직접 편집할 때 커밋하기 전에 붙여 넣습니다. 대부분 내가 항상 남겨 두는 것처럼 보이는 후행 쉼표와 복사 붙여 넣기에서 가끔 중복 키를 잡기 위해 자신의 키트를 조립하는 사람의 경우 유효성 검사기는 다른 필수 항목과 나란히 앉습니다 웹 개발자 툴킷.
프라이버시 측면도 나중에 생각해 볼 일이 아닙니다. 가장 검증해야 하는 JSON 사람들은 정확히 그들이 가장 주의해야 할 JSON 입니다: 토큰을 운반하는 API 응답,자격 증명 기능이 있는 구성 파일,고객 데이터가 있는 페이로드. 검증자가 하는 모든 일은 브라우저,JavaScript, 컴퓨터에서 업로드되거나 기록되거나 저장되지 않습니다. 검증하는 동안 네트워크 탭을 열거나 인터넷을 끊고 도구가 계속 작동하는 것을 지켜봄으로써 이를 증명할 수 있습니다.
자주 묻는 질문
왜 내 JSON은 괜찮아 보이는데 유효하지 않다고 말합니까?
가장 일반적인 이유는 닫는 중괄호 또는 괄호 앞에 후행 쉼표,JSON 이 큰 따옴표를 요구하는 작은 따옴표,두 구성원 사이에 누락 된 쉼표 또는 JSON 이 전혀 허용하지 않는 주석입니다. 네 가지 모두 눈으로 놓치기 쉽습니다. 특히 큰 파일에서 유효성 검사기는 찾은 이름을 지정하고 정확한 줄과 열을 제공하므로 전체 문서를 스캔하는 대신 중지 한 문자로 바로 이동합니다.
단일 숫자 또는 문자열은 그 자체로 유효한 JSON 입니까?
예. RFC 8259 하에서 모든 JSON 값은 완전한 JSON 텍스트이므로 42, "hello", true, 그리고 null 모두 스스로 검증합니다. 최상위 레벨이 객체 또는 배열이어야 한다는 규칙은 이전 RFC 4627 에서 왔으며 2014 년에 제거되었습니다. 맨값을 거부하는 도구는 더 이상 사용되지 않는 사양을 따르는 것입니다.
유효성 검사기가 내 데이터를 변경하거나 업로드합니까?
아니요. 브라우저에서 텍스트를 구문 분석하고 아무데도 보내지 않습니다. 유효한 문서에서는 편의를 위해 예쁘게 인쇄된 복사본을 생성하지만 해당 복사본은 로컬에서 생성되고 원본은 전송,기록 또는 저장되지 않습니다. 서버 왕복이 없기 때문에 도구는 페이지가 로드된 후 연결이 끊긴 네트워크에서도 작동합니다.
JSON이 여전히 유효한 경우 중복 키에 대해 왜 신경 써야합니까?
왜냐하면 중복은 거의 항상 의도하지 않은 데이터 손실을 의미하기 때문입니다. 표준은 중복 키를 허용하지만 처리를 정의되지 않은 상태로 두고 실제로 파서는 마지막 값만 유지하고 나머지는 삭제합니다. 그래서 config where timeout 두 번 나타나면 첫 번째 설정을 조용히 잃습니다. 유효성 검사기는 위치가 포함된 모든 반복 키에 대해 경고합니다. 일반적으로 배지 병합이나 복사 붙여넣기 실수를 발견하는 순간입니다.
tsconfig 또는 VS 코드 설정 파일과 같은 주석을 사용하여 JSON의 유효성을 검사할 수 있습니까?
아니요,그리고 그것은 고의적입니다. 그 파일들은 JSON (JSONC) 또는 JSON5 로 규칙을 완화하는 별도의 형식입니다. 유효성 검사기는 엄격한 RFC 8259 를 대상으로하므로 주석을 오류로 표시합니다. config 파일에 주석이 필요한 경우 형식은 표준이 허용하는 것을 지나친 JSON 이 아니라 YAML 또는 TOML 과 같이 그것을 위해 구축 된 것이어야한다는 신호입니다.
JSON을 유효성 검사하고 포맷하는 것의 차이점은 무엇입니까?
유효성 검사는 텍스트가 JSON 문법을 준수하는지 확인하고,그렇지 않은 경우 정확히 어디에서 깨졌는지 알려줍니다. 서식 지정은 텍스트가 이미 유효하다고 가정하고 가독성을 위해 공백만 조정합니다. 무언가 잘못되었을 때 유효성 검사기에 도달하고 무엇을 알아야합니다; 모든 것이 괜찮을 때 포맷터에 도달하고 단지 읽을 수 있기를 원합니다. 이 도구는 두 가지를 모두 수행하지만 존재하는 이유는 진단입니다.
얼마나 큰 파일을 검증할 수 있나요?
편안 하 게 당신의 browser's 메모리에 의해서만 제한 된 수십 메가바이트로,전체 문서는 장치에서 한 패스에서 구문 분석 되기 때문에. 업로드가 없기 때문에 업로드 크기 캡이 없습니다. 진정으로 거대한 파일의 경우 기가바이트에서 스트리밍 명령줄 유효성 검사기는 브라우저가 한 번에 메모리에 전체 텍스트를 보유 하기 때문에 더 나은 악기입니다.
