JSON 포맷터

JSON 포맷팅에 대하여

JSON(JavaScript Object Notation)은 구조화된 데이터를 위한 텍스트 형식입니다. 압축은 전송을 위해 공백을 제거하여 크기를 줄이고, 정렬은 다시 들여쓰기하여 중첩된 객체와 배열을 사람이 읽을 수 있게 만듭니다.

JSON은 보기보다 엄격합니다. 끝에 붙은 쉼표, 작은따옴표로 감싼 문자열, 따옴표 없는 키, 주석은 모두 JavaScript 객체 리터럴에서는 유효하지만 JSON에서는 구문 오류입니다. 소스 코드에서 객체 리터럴을 복사했을 때 "왜 파싱이 안 되지"라는 혼란의 흔한 원인입니다. 숫자는 JavaScript 자체의 숫자 타입과 같은 IEEE-754 배정밀도 부동소수점이므로, 2^53(약 9천조)을 넘는 정수는 파싱 시 조용히 정밀도를 잃을 수 있습니다. 64비트 데이터베이스 ID나 Discord 스타일의 스노플레이크 ID 같은 값에서는 실제로 문제가 됩니다.

사용되는 곳

• 배포 전 API 응답이나 설정 파일 축소
• 압축된 응답을 디버깅하기 위해 정렬하여 출력
• 로그나 브라우저 개발자 도구에서 붙여넣은 JSON 정리
• 디코딩된 JWT의 페이로드와 함께 내용 검토

자주 묻는 질문

압축해도 데이터가 바뀌지 않는 이유는 무엇인가요?
압축은 토큰 사이의 의미 없는 공백만 제거합니다. 키, 값, 구조는 그대로 유지되므로 파싱된 결과는 동일합니다.

잘못된 JSON을 수정해 주나요?
아닙니다. 유효한 JSON을 검증하고 다시 포맷할 뿐입니다. 쉼표가 잘못 들어간 것 같은 구문 오류가 있으면 추측 대신 오류가 표시됩니다.

키 순서가 유지되나요?
예. 객체의 키는 입력에 나타난 순서대로 유지됩니다.

큰 ID 숫자가 살짝 바뀐 이유는 무엇인가요?
JSON 숫자는 IEEE-754 배정밀도 부동소수점으로 파싱되며, 이는 2^53(9,007,199,254,740,991)까지만 정수를 정확히 표현할 수 있습니다. 이 범위를 넘는 64비트 ID는 숫자로 파싱되는 순간 정밀도를 잃습니다. 흔한 해결책은 원본 시스템이 그런 ID를 순수 숫자가 아니라 JSON 문자열로 보내는 것입니다. 이 도구는 주어진 숫자의 정밀도를 다시 표현할 뿐, 이미 그 이전 단계에서 사라진 자릿수를 되살릴 수는 없습니다.