JSON을 정렬하고 검증하고 구조를 살펴봅니다. 파싱이 안 될 때 "unexpected token"만 던지는 대신 정확히 몇 번째 줄, 몇 번째 칸인지 짚어 줍니다.
JSON 파싱 오류는 몇 번째 바이트에서 났는지를 알려 주는데, 4,000줄짜리 응답에서는 별 도움이 되지 않습니다. 문제를 찾는 방법은 문서를 정렬해 보는 것입니다. 들여쓰기가 잡히고 나면 빠진 쉼표나 닫히지 않은 괄호가 숫자가 아니라 눈에 보이는 구조의 어긋남으로 드러납니다.
해석에는 브라우저에 내장된 JSON 파서를 그대로 씁니다. 그래서 이 페이지가 받아 주는 것이 곧 여러분 코드가 받아 주는 것입니다. 될 것 같지만 표준이 허용하지 않는 것들 — 마지막 쉼표, 작은따옴표 문자열, 주석, 따옴표 없는 키 — 은 전부 오류이고, 그 사실은 배포된 뒤보다 여기서 아는 편이 낫습니다. 압축은 공백만 제거하며 키 순서나 값은 건드리지 않습니다.
서식을 잡는 것은 이 페이지 용도의 절반이고, 나머지 절반은 문서에 실제로 무엇이 들어 있는지 파악하는 것입니다. 통계 줄은 객체, 배열, 키의 개수와 최대 중첩 깊이를 세어 줍니다. 처음 보는 API 응답을 상대로 코드를 쓰기 전에 그 모양을 가장 빠르게 파악하는 방법입니다. 특히 깊이는 한 번 볼 만합니다. 여덟 단계로 중첩된 응답은 접근 표현식이 길고 부러지기 쉬운 응답이라는 뜻이고, 대개는 설계된 것이 아니라 여러 조인 결과를 이어 붙인 응답이라는 신호입니다.
키 정렬은 문서 자체를 바꾸지는 않지만 두 문서를 비교하는 일은 크게 바꿉니다. JSON 객체에는 정해진 키 순서가 없으므로, 의미가 완전히 같은 두 응답이 필드를 다른 순서로 직렬화할 수 있습니다. 서버 버전이 다르거나, 직렬화 라이브러리가 다르거나, 그냥 삽입 순서가 달라서입니다. 그대로 비교하면 잡음만 잔뜩 나옵니다. 양쪽을 먼저 정렬하면 실제로 다른 필드만 남습니다. 이 스위치가 별도 도구가 아니라 여기에 있는 이유입니다.
이스케이프와 언이스케이프는 로그와 웹훅 페이로드에서 자주 만나는 형태를 다룹니다. JSON 문서를 문자열로 직렬화해 다른 JSON 문서 안에 집어넣어, 모든 따옴표에 역슬래시가 붙은 모양입니다. 그런 것을 눈으로 읽는 일은 괴롭고 손으로 고치면 거의 반드시 깨집니다. 먼저 언이스케이프하고, 서식을 잡고, 결과를 다시 이스케이프하는 왕복이 따옴표를 온전하게 유지하는 방법입니다. 이스케이프된 상태 그대로 고치려 들기보다 이 순서를 지키는 편이 낫습니다.
JSON을 한 번 왕복시킬 때 조용히 사라지는 것이 두 가지 있습니다. 하나는 중복 키입니다. 문법상 쓸 수 있고 표준은 파서가 어떻게 처리해야 하는지 정해 두지 않았는데, 널리 쓰이는 구현은 모두 마지막 것만 남기고 앞의 것을 말없이 버립니다. 같은 필드가 두 번 들어 있는 응답은 어디에서도 오류 없이 데이터를 잃습니다. 다른 하나는 큰 정수입니다. 자바스크립트는 JSON의 모든 숫자를 배정밀도로 파싱하는데 정확한 범위가 2의 53제곱까지라, 19자리 식별자는 미묘하게 바뀐 채로 도착하고 이 페이지도 원래 값이 아니라 바뀐 값을 보여 줍니다. 숫자 id가 맞지 않는다면 가장 먼저 확인할 지점입니다.
아니요. 파싱과 정렬 모두 브라우저 안에서만 이루어집니다.
브라우저 메모리만이 제한입니다. 수 메가바이트 문서도 처리되지만 아주 큰 것은 텍스트 영역에서 다소 느리게 느껴집니다.
아니요. 브라우저의 엄격한 JSON 파서를 쓰기 때문에 주석이나 후행 쉼표는 오류로 처리됩니다. 데이터를 검증하는 목적에서는 그게 맞는 동작입니다.