숏컷 코드
{
"path": "C:\\temp\\data.json",
"quote": "\"json\"",
"count": 42,
"ratio": 3.14,
"exp": 1e6
}문법
string은 반드시 큰따옴표여야 한다 — 작은따옴표는 JSON 문법이 아니다
JSON string은 큰따옴표(")로 시작하고 끝납니다. 작은따옴표(')를 사용하는 것은 JavaScript나 Python에서는 허용되지만 JSON spec은 이를 정의하지 않습니다. 파서는 작은따옴표를 만나는 순간 SyntaxError를 냅니다. 프런트엔드 코드에서 object literal을 복사해 JSON 파일이나 API mock에 붙여넣을 때 이 차이를 놓치는 경우가 많습니다. JSON validator나 JSON.parse() 호출로 미리 확인하는 습관이 이런 실수를 방지합니다.
JSON.parse("{'foo': 1}"); // SyntaxError
JSON.parse('{"foo": 1}'); // OKescape 규칙 — 큰따옴표와 역슬래시는 반드시 이스케이프해야 한다
JSON string 안에서 일부 문자는 반드시 backslash escape가 필요합니다. 큰따옴표(\"), 역슬래시(\\), 그리고 줄바꿈(\n), 탭(\t), 캐리지 리턴(\r) 같은 제어 문자가 대표적입니다. Unicode 문자는 직접 쓰거나 \uXXXX 형태로 표현할 수 있습니다. Windows 경로(C:\temp\file.json)를 JSON에 담을 때는 역슬래시를 이중으로 써야 하며(C:\\temp\\file.json), 이를 빠뜨리면 파싱 오류나 의도치 않은 escape 해석이 발생합니다.
{
"newline": "line1\nline2",
"tab": "col1\tcol2",
"unicode": "\u0041"
}숫자는 10진수이며 선행 0이 금지된다 — NaN과 Infinity는 JSON number가 아니다
JSON number는 정수, 소수점, 지수 표기를 지원하지만 8진수 접두어(0으로 시작)는 허용하지 않습니다. 01은 유효하지 않은 JSON 숫자입니다. 더 중요한 제한은 NaN, Infinity, -Infinity가 JSON number에 포함되지 않는다는 점입니다. JavaScript에서 부동소수점 연산 결과로 이 값들이 나올 수 있는데, JSON.stringify()는 이 값들을 null로 변환합니다. 금융 계산이나 센서 데이터에서 무한값이나 비정상값이 발생할 수 있다면, 미리 string("NaN", "Infinity")으로 인코딩 규칙을 정의해야 합니다.
정밀도 손실 — 큰 정수는 number로 안전하게 전달할 수 없다
JSON number는 타입을 명시하지 않습니다. 파서가 double로 읽으면 53비트 정수 범위를 넘는 값은 정밀도를 잃습니다. JavaScript의 Number.MAX_SAFE_INTEGER(9007199254740991)보다 큰 정수 ID나 타임스탬프는 JSON에서 number로 전달하면 파싱 후 값이 달라질 수 있습니다. 이런 경우 string으로 전달하는 것이 안전하며, Twitter/X API가 트윗 ID를 string과 number 두 필드로 동시에 제공했던 것이 대표적인 사례입니다.
{
"path": "C:\\temp\\data.json",
"quote": "\"json\"",
"count": 42,
"ratio": 3.14,
"exp": 1e6
}체크포인트
| 상황 | 적합한 선택 |
|---|---|
| 문자열 구분자 | 큰따옴표만 허용 (작은따옴표 불가) |
| 큰따옴표·역슬래시 포함 문자열 | \", \\ escape 필수 |
NaN / Infinity 값 전달 | string으로 인코딩 후 수신 측 파싱 |
| 53비트 초과 정수 ID | string으로 전달 (정밀도 손실 방지) |
| 줄바꿈이 있는 긴 텍스트 | 실제 개행 대신 \n escape 또는 상위 형식 검토 |
주의할 점
JSON 파싱 오류의 상당수는 문자열 구분자(작은따옴표)와 escape 누락에서 발생합니다. 또한
NaN과 Infinity는 JSON.stringify()에서 조용히 null로 바뀌고, 큰 정수는 파싱 후
정밀도를 잃을 수 있습니다. 이 두 경우 모두 오류가 아닌 잘못된 데이터가 조용히 통과되므로
특히 주의해야 합니다.
{
"id": 9007199254740993
}이 값은 JSON 문법상 유효해도, JavaScript 같은 런타임에서 파싱하면 정밀도가 깨질 수 있습니다. 큰 정수 식별자는 처음부터 string으로 주는 편이 안전합니다.
같은 이유로 주문 번호, 결제 번호처럼 계산하지 않는 식별자는 number보다 string이 더 안전한 선택인 경우가 많습니다.
참고 링크
2 sources