XML에서 JSON으로: 보이는 것보다 어려워
XML과 JSON 간 변환이 왜 놀라운 결과를 만들고 엣지 케이스를 다루는 법.
XML 데이터가 있어. JavaScript 앱이 JSON이 필요해. 변환하고 넘어가, 맞지?
근데 변환이 예상치 못한 결과를 만들어. 있어야 하는 배열이 없어. 속성이 이상한 곳에 들어가. 단일 항목이 무작위로 배열이 돼.
XML과 JSON은 데이터를 다르게 모델링해. 그 사이 변환은 결정이 필요해.
근본 불일치
JSON은 가져: 객체, 배열, 문자열, 숫자, 불린, null.
XML은 가져: 요소, 속성, 텍스트 콘텐츠, 네임스페이스, 주석, CDATA.
1:1 매핑이 없어.
배열 문제
XML은 배열이 없어. 반복되는 요소가 있어.
<users>
<user>Alice</user>
<user>Bob</user>
</users>
이건 아마 이렇게 돼야 해:
{"users": {"user": ["Alice", "Bob"]}}
하지만 이건 어때:
<users>
<user>Alice</user>
</users>
하나의 요소. 한 항목의 배열이야, 아니면 그냥 문자열? 다른 변환기가 다르게 결정해.
일관성이 중요해. user가 때때로 배열이고 때때로 문자열이면 코드가 깨져.
속성 문제
XML은 속성이 있어. JSON은 없어.
<product id="123">Widget</product>
흔한 변환 전략:
{"product": {"_id": "123", "_text": "Widget"}}
{"product": {"@id": "123", "#text": "Widget"}}
{"product": {"$": {"id": "123"}, "_": "Widget"}}
모든 관례가 달라. 변환기가 뭘 만드는지 알아.
네임스페이스 문제
XML 네임스페이스는 soap:Envelope 같은 정규화된 이름을 만들어. JSON은 네임스페이스 개념이 없어.
변환기는:
- 프로퍼티 이름에 접두사 포함:
"soap:Envelope" - 접두사 제거:
"Envelope" - 네임스페이스 처리를 위한 중첩 구조 만들기
각 접근은 트레이드오프가 있어.
실전 팁
일관되게. 변환 라이브러리 골라서 고수해. 변환기 섞으면 일관되지 않은 구조를 만들어.
배열 강제. 요소가 여러 인스턴스를 가질 수 있으면 단일 요소라도 항상 배열을 만들도록 변환기 설정.
엣지 케이스 테스트. 샘플이 아니라 실제 데이터 변환. 프로덕션 데이터의 엣지 케이스가 널 놀라게 할 거야.
대안 고려. 양쪽을 제어하면 처음부터 JSON 쓰는 걸 고려해. 앞뒤로 변환하면 정보를 잃어.
JSON을 XML로 도전
반대도 문제가 있어.
배열 표현 없음. JSON 배열은 반복되는 요소가 돼. 그 요소들의 이름을 지어야 해.
{"items": [1, 2, 3]}
뭐가 돼? <items><item>1</item>...</items>? "item"은 어디서 와?
숫자 타입. JSON은 숫자를 문자열과 구분해. XML은 안 해. 123이 <value>123</value>가 될 수 있어—숫자야 문자열이야?
언제 변환할까
레거시 시스템과 통합. SOAP API랑 오래된 엔터프라이즈 시스템이 XML을 써. 경계에서 변환.
XML 데이터 처리. JavaScript는 XML보다 JSON을 훨씬 잘 다뤄. 변환하고, 처리하고, 필요하면 다시 변환.
일회성 마이그레이션. XML 기반 시스템에서 JSON 기반으로 이동.
언제 변환하지 말까
왕복 요구사항. XML → JSON → XML은 종종 정보를 잃어. 속성, 네임스페이스, 순서.
스키마 검증. XML은 강력한 스키마 언어 (XSD)가 있어. JSON Schema는 덜 성숙해.
문서 처리. XML의 혼합 콘텐츠 모델 (임베디드 요소가 있는 텍스트)은 JSON에 깔끔하게 매핑 안 돼.
XML과 JSON은 데이터를 다르게 표현해. 변환은 배열, 속성, 네임스페이스에 대한 선택이 필요해. 변환기 행동을 이해하고 현실적인 데이터로 테스트해.