XML JSON 변환기
XML을 JSON으로, JSON을 XML로 — 속성·반복 규칙 명시
속성은 @키, 텍스트는 #text, 같은 이름 자식 여럿은 배열이 됩니다
XML을 JSON으로 바꾸는 ‘정답’은 없습니다
이 도구를 이해하는 열쇠는 하나입니다 — XML을 JSON으로 바꾸는 표준 규칙이 존재하지 않는다는 것. XML은 한 요소가 속성·텍스트·자식 요소를 동시에 가질 수 있는데, JSON 객체에는 그 셋을 구분할 장치가 없습니다. 그래서 도구마다 “속성을 어디에 담을지”를 다르게 정하고, 같은 XML이라도 결과 JSON이 달라집니다.
그래서 이 도구는 규칙을 하나 정하고, 그 규칙을 숨기지 않고 명시합니다.
<user id="1">
<name>홍길동</name>
<role>admin</role>
<role>user</role>
</user>
↓ (규칙: 속성 → @키, 텍스트 → #text, 반복 → 배열)
{
"user": {
"@id": "1",
"name": "홍길동",
"role": ["admin", "user"]
}
}- 요소 → 객체
- 속성
attr→@attr키 - 텍스트 →
#text키 (단, 속성·자식 없는 순수 텍스트 요소는 문자열 그대로) - 같은 이름 자식 여럿 → 배열
이 관례를 알아야 결과 JSON을 코드에서 제대로 다룰 수 있습니다. 되돌릴 때(JSON → XML)도 같은 규칙을 반대로 적용하므로, @로 시작하는 키는 속성으로, #text는 내용으로, 배열은 반복 요소로 복원됩니다.
지원 범위와 ‘정직한 실패’
이 도구는 실무에서 흔히 만나는 XML을 지원합니다 — 요소·속성·텍스트·self-closing 태그 (<br/>)·CDATA·주석·<?xml?> 선언·기본 엔티티 (<·&·0).
반대로, 그 범위를 벗어나거나 형식이 어긋난 XML은 조용히 대충 읽지 않고 무엇이 문제인지 알려 줍니다 — 닫는 태그가 안 맞거나, 태그가 안 닫혔거나, 루트 요소가 둘이거나. 잘못 파싱한 결과를 그럴듯하게 내놓는 것이 훨씬 위험하기 때문입니다. 이건 CSV·YAML 변환기가 “못 읽으면 행 번호와 함께 실패를 알린다”는 것과 같은 원칙입니다.
언제 쓰나
오래된 시스템·SOAP·RSS·설정 파일이 XML로 오는데 코드에서는 JSON이 편할 때, 또는 그 반대일 때 씁니다. 표 형태 데이터라면 CSV ↔ JSON, 설정 파일이라면 JSON ↔ YAML이 더 자연스러울 수 있고, 결과 JSON을 보기 좋게 정렬하려면 JSON 포맷터를 이어서 쓰면 됩니다. 되돌린 XML은 데이터는 같지만 공백·속성 순서 같은 겉모습은 정규화된다는 점만 기억하세요.
자주 묻는 질문
- 이 도구의 변환 규칙(관례)은 무엇인가요?
- XML을 JSON으로 바꿀 때 정해진 표준이 없어서, 이 도구는 다음 관례를 씁니다. 요소는 객체가 되고, 속성은 앞에 @를 붙인 키(@href), 텍스트 내용은 #text 키가 됩니다. 단, 속성도 자식도 없는 순수 텍스트 요소는 번거롭지 않게 문자열 그대로 둡니다. 같은 이름의 자식 요소가 여럿이면 배열로 묶습니다. 이 규칙을 명시하는 이유는, 같은 XML이라도 도구마다 결과 JSON이 다를 수 있기 때문입니다 — 어떤 규칙인지 알아야 결과를 신뢰할 수 있습니다.
- 왜 속성에 @, 텍스트에 #text를 붙이나요?
- XML은 한 요소가 속성과 자식 요소와 텍스트를 동시에 가질 수 있는데, JSON 객체에는 그 구분이 없기 때문입니다. <a href='x'>링크</a>를 그냥 {a:'링크'}로 만들면 href 속성이 사라집니다. 그래서 속성은 @href, 텍스트는 #text로 이름을 달리해 한 객체 안에 충돌 없이 담습니다. 이 접두어 덕분에 JSON을 다시 XML로 되돌릴 때도 무엇이 속성이고 무엇이 자식이었는지 알 수 있습니다.
- 어떤 XML은 왜 변환이 안 되고 에러가 나나요?
- 이 도구는 흔히 쓰는 XML(요소·속성·텍스트·self-closing·CDATA·주석·XML 선언·기본 엔티티)을 지원합니다. 그 범위를 벗어나거나 형식이 어긋난 XML(닫는 태그 불일치, 안 닫힌 태그, 루트 요소가 둘 등)은 조용히 대충 읽지 않고 무엇이 문제인지 알려 줍니다. 잘못 파싱한 결과를 그럴듯하게 내놓는 것이 훨씬 위험하기 때문입니다 — 네임스페이스 접두어(ns:tag)는 이름의 일부로 그대로 두고, DTD·처리 명령은 건너뜁니다.
- JSON을 XML로 되돌리면 원래 XML과 똑같나요?
- 구조는 보존되지만 공백·들여쓰기·속성 순서 같은 '겉모습'은 원본과 다를 수 있습니다. XML은 요소 사이의 공백이나 속성 순서가 의미를 바꾸지 않으므로, 이 도구는 보기 좋게 다시 정렬해 냅니다. @로 시작하는 키는 속성으로, #text는 내용으로, 배열은 반복 요소로 되돌립니다. 데이터(값·구조)는 같지만 포맷은 정규화된다고 보면 됩니다.
- 설정 파일이나 API 응답을 옮길 때 쓰면 되나요?
- 네. 오래된 시스템이나 SOAP·RSS·설정 파일이 XML로 오는데 코드에서는 JSON이 편할 때, 또는 그 반대일 때 씁니다. 다만 위 관례(@·#text·배열)를 코드에서 그대로 다뤄야 하므로, 변환 결과의 모양을 먼저 확인하세요. 표 형태 데이터라면 CSV, 설정이라면 YAML이 더 맞을 수 있으니 형제 도구도 함께 고려해 보세요.