JSON 유효성 검사

JSON이 실제로 금지하는 것

JSON의 문법은 의도적으로 아주 작으며, 유효성 검사 실패의 거의 전부는 사람들이 JavaScript에서 가져왔지만 JSON이 채택하지 않은 몇 가지 중 하나입니다. 마지막 요소 뒤의 후행 쉼표. 큰따옴표 대신 작은따옴표. 따옴표 없는 키. 주석. JSON에는 주석이 없으며 한 번도 있었던 적이 없습니다. NaN과 Infinity는 JavaScript에서는 유효한 숫자지만 JSON에서는 유효하지 않습니다. 그리고 맨 앞의 바이트 순서 표시(BOM)는 어떤 편집기에서도 보이지 않는데, 일부 Windows 도구가 UTF-8로 저장할 때 추가하며, 멀쩡한 문서를 첫 글자에서 실패하게 만듭니다.

문법상 허용되지만 여전히 문제를 일으키는 것이 두 가지 있으며, 그래서 “유효함”은 “올바름”과 같지 않습니다. 중복 키는 명세상 금지되어 있지 않지만 파서마다 처리 방식이 달라 대부분 마지막 값을 택하므로, 키가 반복된 문서는 여기서 유효하다고 나오면서도 언어마다 다른 의미가 됩니다. 그리고 JSON에서 숫자에는 정해진 정밀도 한계가 없지만 대부분의 파서는 이를 부동소수점으로 읽습니다. 약 9천조를 넘는 정수는 조용히 반올림되며, 큰 식별자를 문자열로 주고받는 경우가 많은 이유가 이것입니다.

결과로 파싱이 멈춘 정확한 줄, 열, 문자를 알려 드리며, 이는 보통 오류 메시지 자체보다 더 유용합니다. 파서는 실수한 곳이 아니라 문서가 말이 안 되기 시작한 지점을 보고합니다. 닫는 중괄호가 빠지면 파일 끝에서, 쉼표가 빠지면 그 다음 토큰에서 오류가 보고됩니다. 보고된 위치 바로 앞을 살펴보는 습관이 시간을 가장 많이 아껴 줍니다.

형식이 올바른 것과 내용이 올바른 것은 다르며, 이 구분은 중요합니다. 이 도구는 문법이 파싱되는지를 확인합니다. 문서에 API가 요구하는 필드가 있는지, 값이 범위 안에 있는지, 날짜가 정말 날짜인지는 JSON의 문제가 아닙니다. 그것은 스키마 검증이며 스키마가 필요합니다. 여기서 완벽한 문서도 보내려는 서비스에서는 바로 거부될 수 있습니다.

다른 작업이 필요할 때

문법이 아니라 스키마에 맞는지 문서를 검사하려면 JSON Schema가 표준이고 ajv가 가장 빠른 구현체입니다. 필수 필드가 빠졌거나 값이 범위를 벗어났다고 알려 주며, 대개 실제로 궁금한 것이 바로 그것입니다. check-jsonschema는 같은 검사를 명령줄과 CI에서 실행합니다.

명령줄 작업이라면 jq를 갖춰 두세요. jq empty file.json은 유효성을 검사하고 성공하면 아무것도 출력하지 않아 스크립트에 딱 맞으며, jq .는 정렬합니다. 메모리에 담기에 너무 큰 파일은 jq --stream과 Python의 ijson이 점진적으로 파싱하며, 문서 전체를 불러오는 페이지로는 할 수 없는 일입니다.