JSON의 문법과 형식에서 시작해 쿼리, 검증, 실무 적용까지 이어지는 학습 경로로, 각 문서에는 바로 사용할 수 있는 온라인 도구가 함께 있습니다.
RFC 8259와 ECMA-404에서 출발해 JSON의 문법, 타입, 인코딩, 파싱 경계를 정리합니다. 모든 JSON 작업이 딛고 서는 토대입니다.
6개 문서
JSON5, JSONC, JSON Lines, NDJSON은 주석, 후행 쉼표, 스트리밍 같은 실제 요구를 해결하지만, 그 대가로 호환성과 선택의 문제를 함께 가져옵니다.
6개 문서
JSON에서 값 하나를 꺼내거나 필드 하나를 바꾸는 것은 간단해 보이지만, 표준화되면 네 가지 명세가 됩니다. JSONPath, JSON Pointer, JSON Patch, Merge Patch.
5개 문서
JSON Schema로 데이터 모양을 설명하고, 말로 된 합의를 실행 가능한 검증으로 바꾸며, 이를 다시 TypeScript 타입과 폼 생성으로 이어 갑니다.
7개 문서
JSON과 YAML, XML, CSV, TypeScript, Java, Go, SQL 사이의 변환은 결코 무손실이 아닙니다. 중요한 것은 손실이 어디서 일어나는지 명시하는 것입니다.
8개 문서
수십 MB의 JSON 파일은 메인 스레드를 멈출 수 있고, 정교하게 만든 JSON은 서비스를 뚫을 수 있습니다. 이 카테고리는 처리량과 방어를 모두 다룹니다.
6개 문서
파싱 라이브러리, 명령행 도구, 에디터 플러그인이 일상적인 JSON 도구 체인을 이루며, 이들을 고르는 열쇠는 오류 위치 품질과 생태계 유지 관리 상태입니다.
6개 문서
JSON을 실제 시스템에 넣기: API 계약을 정의하는 방법, 설정과 픽스처를 관리하는 방법, 버전 호환성을 처리하는 방법, 테스트 데이터를 유지하는 방법.
5개 문서
이 사이트의 도구와 JSON 명세에 관해 가장 자주 묻는 질문을 시나리오별로 묶고, 모호한 결론 대신 바로 행동할 수 있는 답을 제공합니다.
25개 문서수십 MB짜리 JSON 내보내기는 텍스트 편집기와 온라인 도구에서 자주 멈추지만, 파싱 자체는 수백 밀리초면 끝납니다. 45MB·50만 레코드 샘플로 각 단계의 시간과 메모리를 실측해 진짜 비용이 줄 수와 노드 수임을 보이고, 파일 크기별 도구 선택표를 제시합니다. 온라인 보기, 명령줄 추출, 스트리밍 처리, 데스크톱 앱의 역할 구분까지 정리했습니다.
.jsonl 파일 전체를 JSON.parse에 넣고 에러가 난다면 파일이 깨진 게 아니라 읽는 방식이 틀렸을 가능성이 높습니다. 이 글은 확인과 한 줄씩 읽기의 표준 패턴, JSON 배열과의 상호 변환 명령, 여섯 가지 깨진 줄의 진단 표, 스트리밍 API에서 NDJSON을 소비하는 올바른 방법을 다룹니다.
스키마는 작성으로 끝이 아니라 거기서부터 망가지기 시작합니다. 오타 하나가 검증을 조용히 느슨하게 만들고, 리팩터링 하나가 픽스처 전체를 오작동시킵니다. 이 글은 정례·부례·스냅샷 3종 세트, 스키마 자체의 린트, 컴파일 한 번 재사용, CI에 설치하는 네 개의 게이트로 이루어진 실행 가능한 계약 테스트 구성을 다룹니다.
실제 컨버터로 아홉 가지 실험을 수행했습니다. 첫 행 키 방식은 필드를 조용히 유실하고, null·누락·빈 문자열은 모두 빈 셀이 되며, 20자리 정수는 JSON.parse 단계에서 이미 정밀도를 잃고, 점이 포함된 키는 서로 다른 경로를 한 열로 충돌시킵니다. 헤더 생성 방법, 값의 변형, 다운스트림 용도별 전략 선택을 설명합니다.
