JSON 포맷터

이 JSON 포맷터가 하는 일

JSON(JavaScript Object Notation)은 프로그램 사이에 구조화된 데이터를 주고받는 가장 흔한 형식입니다 — API 응답, 설정 파일, 로그 줄 등입니다. 간결하게 설계되어, 그 탓에 객체가 몇 단계 중첩되거나 한 줄로 도착하면 읽기 어려워집니다. 이 도구는 붙여넣은 JSON을 두 가지로 다시 씁니다: 일관된 들여쓰기로 구조가 한눈에 보이는 정리본, 또는 선택적 공백을 모두 없애 회선으로 보내기에 가장 작은 압축본입니다.

정리하면서 검증도 합니다. 다시 직렬화하기 전에 텍스트를 파싱하므로 잘못된 JSON이 오해를 부르는 출력을 내는 일이 없습니다 — 대신 알아낼 수 있는 한 파싱이 실패한 줄과 열이 나와 문제 지점으로 바로 갈 수 있습니다.

정리와 압축 — 각각 언제 쓰나

두 모드는 정반대의 목적을 지니며, 대부분의 작업은 단계에 따라 둘 다 씁니다:

• 읽거나 디버깅할 때는 정리 — API 응답을 살피거나, 두 페이로드를 비교하거나, 풀 리퀘스트에서 설정 파일을 검토하는 경우입니다. 들여쓰기가 글자의 벽을 훑어볼 수 있는 트리로 바꿉니다.
• 내보낼 때는 압축 — JSON을 HTML에 심거나, 쿠키나 캐시에 저장하거나, 1바이트가 아쉬운 요청 본문에 싣는 경우입니다. 압축된 JSON은 공백만 뺀 바이트 단위로 동등한 데이터입니다.

들여쓰기 선택(공백 2칸, 4칸, 탭)은 정리 출력에만 영향을 줍니다. 공백 2칸이 JavaScript와 웹 도구에서 가장 흔한 관례이고, 공백 4칸이나 탭은 그것을 선호하는 팀에 맞습니다. 무엇을 고르든 결과는 여전히 유효한 JSON입니다 — 들여쓰기는 순전히 겉모습일 뿐입니다.

검증 오류 읽기

JSON이 잘못됐을 때 이 도구는 맨숭맨숭한 "잘못됨" 대신 첫 문제의 줄과 열을 알립니다 — 줄과 열이 어디를 가리키는지에 관한 절이 말하는 단 하나의 경우만 빼고요. 엔진의 오류 메시지는 브라우저마다 다르고 위치를 빼는 경우가 많아, 위치는 따로 계산되어 살펴보기 시작하기 알맞은 지점을 가리킵니다. 첫 오류를 고치고 다시 확인하세요 — 떠도는 문자 하나가 여러 겉보기 문제로 번지는 경우가 흔합니다.

흔한 JSON 실수

JSON은 닮은 JavaScript 객체 리터럴보다 엄격합니다. 사람이 가장 자주 걸리는 실수는 다음과 같습니다:

• 끝의 쉼표: 객체나 배열의 마지막 항목 뒤의 쉼표는 JavaScript에서는 유효하지만 JSON에서는 무효입니다.
• 작은따옴표: JSON의 문자열과 키는 큰따옴표를 써야 합니다. 'value'는 무효이고 "value"가 옳습니다.
• 따옴표 없는 키: 모든 객체 키는 따옴표 붙은 문자열이어야 하므로 { name: "x" }는 { "name": "x" }가 되어야 합니다.
• 주석: JSON에는 주석 구문이 없습니다. //와 /* */는 파싱 오류를 냅니다.
• 특별한 숫자: NaN, Infinity, -Infinity는 유효한 JSON 숫자가 아닙니다.
• 잘못된 따옴표: 워드프로세서에서 붙여넣은 "스마트 따옴표"는 따옴표처럼 보이지만 다른 문자라 파싱되지 않습니다.

알려 주는 줄과 열이 가리키는 곳

위치는 무언가를 빠뜨린 자리가 아닙니다. 파서가 거기 있을 수 없는 것을 처음 만난 자리이고, 이 둘은 보통 서로 다른 자리입니다. 아래 객체에서는 3행을 닫아야 할 쉼표가 빠져 있고, 이 도구는 4행 3열 — 다음 키를 여는 따옴표 — 를 알립니다. 그 따옴표가 오기까지는 잘못된 것이 없었습니다. 문서가 3행 뒤에서 올바르게 끝날 수도 있었기 때문이고, 그래서 파서는 쉼표도 닫는 중괄호도 아닌 것을 만났을 때에야 빠진 것을 알게 됩니다.

{
  "id": 42,
  "name": "widget"
  "price": 9.99
}

• 빠진 쉼표는 그 뒤에 오는 것의 첫 글자 자리에 알려지고, 위처럼 들여쓴 JSON에서는 그것이 다음 줄입니다. 그러니 지목된 줄을 그 위의 줄과 함께 읽으세요.
• 남는 쉼표는 닫는 괄호 자리에 알려집니다. 마지막 쌍이 2행에 있는 객체라면 3행 1열입니다. 쉼표는 쌍이 하나 더 온다고 약속하고, 괄호는 그 약속을 깨뜨리는 것이기 때문입니다.
• 닫히지 않은 문자열은 대개 여는 따옴표가 아니라 그 문자열이 시작된 줄의 끝에 알려집니다. 뒤쪽 줄에 있는 다음 따옴표가 그것을 다른 곳에서 닫아 버릴 수 있기 때문입니다. 줄바꿈은 JSON 문자열 안에 들어갈 수 없으니, 줄바꿈이 거기 있을 수 없는 첫 글자입니다.
• 완벽해 보이는 문서에서 1행 1열이 나오면 대개 바이트 순서 표시입니다. 어떤 편집기는 UTF-8로 저장할 때 이것을 씁니다. 눈에 보이지 않고, 여는 중괄호 앞에 앉으며, JSON에는 그것을 둘 자리가 없습니다.

그리고 위치를 전혀 알아낼 수 없을 때에는, 짐작한 좌표를 대는 대신 위치 없이 실패만 알립니다. 자신 있게 제시된 줄과 열이 완전히 옳은 구문을 가리키면 엉뚱한 자리를 찾게 되고, 그것은 문서가 파싱되지 않는다는 사실만 아는 것보다 나쁩니다.

정리가 바꾸는 것과 지키는 것

거의 모든 문서에서 답은 공백이고 그 밖에는 없습니다. 하지만 이 도구는 여러분의 텍스트를 고치는 것이 아니라, 실제 값으로 파싱해 그 값을 다시 써 냅니다. 그리고 그 왕복을 견디지 못하는 것이 다섯 가지 있습니다. 어느 것도 도구의 결함이 아니고 — 각각은 숫자와 객체가 무엇인지에 대해 JSON 사양이 말하는 바입니다 — 각각은 출력을 원본 위에 붙여넣기 전에 알아 둘 값이 있습니다.

• 같은 키를 두 번 쓴 경우: 둘 중 마지막 것만 남습니다. 객체는 하나의 키를 두 번 지닐 수 없기 때문입니다. RFC 8259는 이름이 중복된 객체를 받는 소프트웨어의 동작을 예측할 수 없다고 말하고, 다른 파서는 앞의 것을 남길 수도 있으니, 둘 중 무엇이 남는지도 믿고 기댈 일은 아닙니다.
• 열다섯 자리보다 긴 정수: JSON의 숫자는 배정밀도 부동소수점으로 읽히고, 이 형식은 2의 53제곱까지의 모든 정수를 정확히 담습니다 — 열여섯 자리 수입니다 — 그래서 열다섯 자리 정수는 언제나 살아남고 그보다 긴 것은 살아남지 못할 수 있습니다. 12345678901234567890을 붙여넣으면 12345678901234567000이 나옵니다. 긴 데이터베이스 식별자가 흔한 희생자입니다. 가능하면 문자열로 두세요.
• 지수 형태와 끝의 0은 정규화됩니다: 1e3은 1000으로, 1.50은 1.5로 돌아옵니다. 표준 방식으로 쓰인 같은 수입니다.
• 그 형식이 담을 수 있는 범위 밖의 크기는 아예 다른 것으로 돌아옵니다. 1e400에는 배정밀도 값이 없어 null로 돌아오고, 1e-400은 0으로 돌아옵니다. 긴 소수는 긴 정수와 마찬가지로 그 형식이 지닌 정밀도로 반올림됩니다.
• 이스케이프는 그것이 가리키는 문자가 됩니다: \u00e9는 é로 돌아오고, 이스케이프된 서러게이트 쌍은 그것이 철자하는 이모지로 돌아옵니다. 어떤 파서에게도 같은 문자열이며, 두 표기 가운데 하나가 그저 더 짧을 뿐입니다.

키 순서는 여러분이 쓴 그대로 지켜지지만, 알아 둘 예외가 하나 있습니다. 숫자만으로 이루어져 평범한 음이 아닌 정수로 읽히고 사십억쯤보다 작은 키는 배열 첨자로 다뤄져, 어디에 두었든 숫자 순서로 그 객체의 앞으로 돌아옵니다. 그 밖에는 아무것도 움직이지 않습니다. 다른 어떤 키도 다시 정렬되지 않고, 어떤 키도 더해지거나 이름이 바뀌지 않습니다. 이 가운데 무엇이라도 중요하다면, 정리하지 말고 압축한 뒤 결과를 원본과 한 글자씩 견주어 보세요. 왕복이 무엇을 했는지 보는 가장 짧은 길입니다.

찾는 JSON이 문자열 안에 있을 때

웹훅 로그, 메시지 큐, 데이터베이스 열은 JSON 문서 하나를 통째로 단일 문자열 값으로 나르는 일이 매우 흔하고, 그 안의 따옴표는 모두 이스케이프되어 있습니다. 바깥 문서는 완벽히 유효하므로 도구는 그것을 정리하고 유효하다고 알립니다 — 그리고 여러분이 읽으러 온 부분은 긴 한 줄의 백슬래시로 남습니다. 잘못된 것은 없습니다. 이것은 두 문서이고, 하나가 다른 하나의 문자열 안에 싸여 있는 것입니다.

{
  "event": "order.created",
  "payload": "{\"id\":42,\"total\":19.99}"
}

그래서 읽으려면 두 번의 과정이 필요합니다. 바깥 문서를 여기서 정리하고, 원하는 문자열의 따옴표 사이에 있는 것을 복사하고, 이스케이프를 되돌린 뒤 그 결과를 다시 붙여넣으세요. JSON 문자열 이스케이프 도구가 그 중간 단계를 합니다. 그 되돌리기 방향은 백슬래시와 그 뒤의 따옴표를 큰따옴표 자체로 되돌리고, 그 줄을 이 페이지가 정리할 수 있는 문서로 되돌립니다. 파일을 만든 쪽을 여러분이 통제할 수 있다면 더 나은 해결은 위쪽에 있습니다. 페이로드를 문자열이 아니라 중첩된 객체로 보내면 두 과정 모두 필요 없습니다.

한 줄에 객체 하나는 한 문서가 아니다

로그 파일, API 내보내기, 스트리밍 엔드포인트는 흔히 한 줄에 완전한 JSON 객체 하나를 담습니다. 이 형식은 JSON Lines, 또는 NDJSON이라고 불립니다. 각 줄은 그 자체로 유효한 JSON이지만 파일은 JSON 문서가 아닙니다. JSON 문서는 최상위 값을 정확히 하나 담는데, 이 파일은 여러 개를 하나씩 잇달아, 그것들을 잇는 무엇도 없이 담고 있기 때문입니다.

{"level":"info","msg":"started"}
{"level":"warn","msg":"retrying"}
{"level":"error","msg":"gave up"}

그것을 여기 붙여넣으면 도구는 2행 1열을 알립니다. 첫 객체가 깔끔하게 끝났고, 그다음 문서가 끝나 있어야 할 자리에서 두 번째가 시작되었기 때문입니다. 거기서 길은 둘입니다. 한 번에 한 줄씩 정리하기 — 로그 한 건을 읽고 있을 때 원하는 것이 이것입니다. 또는 파일을 한 문서로 만들기 — 줄들을 대괄호로 싸고 마지막 줄만 빼고 모든 줄 끝에 쉼표를 넣기 — 배열을 기대하는 무언가에 전부 실어 넣으려 할 때 원하는 것이 이것입니다.