XML에서 JSON로의 매핑: 속성, 텍스트 노드 및 일대다 문제

하나의 <item>이 객체가 되고 두 개가 배열이 된 이유 - JSON 모양이 항목 수에 따라 변경되는 XML 피드

`<item>one</item>`이 있는 피드는 `"item": "one"`을 생성합니다. 두 번째 형제를 추가하면 해당 속성이 `"item": ["one", "two"]`로 변경됩니다. 두 의미 모두 동일한 XML 구문을 갖기 때문에 파서는 하나의 항목이 개념적으로 하나의 목록이었다고 추론할 수 없습니다. 따라서 첫 번째 샘플에 대해서만 작성된 코드는 프로덕션에서 두 번째 샘플을 보낼 때 실패할 수 있습니다.

ToolAcre는 항상 배열 옵션 뒤에 이러한 불안정성을 숨기지 않습니다. 한 번 이름을 하나의 값으로 기록하고 반복된 형제를 배열로 기록합니다. 이러한 직접 매핑은 검사하기 쉽지만 안정적인 컬렉션 형태가 필요한 소비자는 스키마 지식을 사용하거나 변환 후 결과를 직접 정규화해야 합니다.

XML에는 있지만 JSON에는 없는 것 — 속성, 요소와 혼합된 텍스트, 순서가 지정된 형제 항목, 네임스페이스, 주석 및 처리 지침

XML는 하위 요소에서 특성을 분리하고, 형제 순서를 유지하고, 요소 사이에 텍스트를 허용하고, 네임스페이스 접두사를 전달하고, 주석 및 처리 지침을 포함할 수 있습니다. JSON은 개체와 배열을 제공하지만 해당 노드 범주에 해당하는 항목이 내장되어 있지 않습니다. 결과적으로 모든 XML-to-JSON 결과는 보편적인 번역이 아닌 선택된 투영입니다.

이 판독기는 선언, 주석 및 처리 지침을 삭제합니다. 네임스페이스 접두사는 확인되지 않고 그대로 유지됩니다. `<ns:item>`은 `ns:item` 키가 되고 `xmlns:ns`는 `@xmlns:ns`이 됩니다. 혼합 텍스트는 하나의 키 아래 결합되므로 하위 요소 주변의 원래 위치가 손실되고 변환이 왕복될 수 없다는 경고가 표시됩니다.

속성 규칙 — @ 또는 $와 같은 접두사, 존재 이유, 이름이 같은 속성과 하위 요소가 충돌하는 방식

속성은 `@` 접두사를 사용합니다. `<user id="7"><id>other</id></user>`은(는) `@id`이(가) `"7"`이고 하위 `id`(이)가 `"other"`인 개체가 됩니다. 접두사는 두 개의 서로 다른 XML 구문이 단일 개체 속성에서 충돌하는 것을 방지합니다. 또한 JSON이 XML에 다시 기록될 때 변환기 계약의 일부가 됩니다.

다른 라이브러리는 `$`, 속성 개체 또는 다른 규칙을 사용할 수 있습니다. ToolAcre는 눈에 보이는 `@` 매핑만 지원합니다. 작성기를 변경하지 않고 애플리케이션 코드에서 해당 접두사를 변경하면 속성이 요소로 전환되므로 변환된 값을 중간 검사 양식으로 사용할 때 이를 유지하세요.

텍스트 노드 규칙 — 요소 콘텐츠의 경우 #text 또는 _, 요소에 텍스트와 자식이 모두 있는 경우 발생하는 현상

텍스트만 포함하는 요소는 해당 문자열로 축소됩니다. 속성이나 하위 항목도 있는 경우 텍스트는 `#text` 아래에 있습니다. CDATA는 `#cdata`에 별도로 보관됩니다. 자체 닫는 태그는 빈 문자열이 됩니다. 이러한 예약된 키를 사용하면 작성자는 JSON 자체에서 정의하지 않는 콘텐츠 범주와 일반 하위 이름을 구별할 수 있습니다.

혼합 콘텐츠는 여전히 손실이 있습니다. `<p>before<b>bold</b>after</p>`에서는 하위 항목을 기준으로 한 "이전" 및 "이후"의 위치를 ​​결합된 `#text` 속성에서 재구성할 수 없습니다. 이 도구는 해당 구조적 패턴을 감지하고 경고합니다. 문서 순서가 의미의 일부인 경우 노드 보존 XML API를 사용하세요.

일대다 문제 — 반복되는 요소는 반복될 때만 배열이 되며, 소비자가 방어적으로 코딩해야 하는 이유

반복된 형제 항목은 반복이 관찰된 후에만 배열로 변합니다. 단일 `<book>`은 하나의 개체입니다. 두 권의 책은 객체의 배열입니다. 이를 일대다 문제라고도 부르지만 파서 결함은 아닙니다. 소스 문서에는 발생 항목과 관계없이 목록 선언이 포함되어 있지 않습니다.

방어적인 소비자는 스키마 지식을 사용하여 알려진 경로를 정규화할 수 있습니다. 아직 배열이 아닌 경우 `catalogue.book`을 래핑합니다. 일반 스칼라는 단지 대칭을 위한 목록이 되어서는 안 되기 때문에 모든 속성에 해당 규칙을 적용하지 마세요. 변환기는 의도적으로 그러한 도메인 정보를 만들어내는 것을 피합니다.

작업 예: 작은 RSS 스타일 문서 변환(속성, 반복 요소 및 네임스페이스, 결과 JSON 주석 포함)

`<feed xmlns:m="https://example.invalid/meta"><item id="1"><m:title>One</m:title></item><item id="2"><m:title><![CDATA[Two & More]]></m:title></item></feed>`을(를) 변환합니다. 루트는 `feed`입니다. `@xmlns:m`는 네임스페이스 선언을 유지합니다. `item`은 배열입니다. 각 `@id`는 텍스트입니다. 두 번째 제목에는 `#cdata`가 포함되어 있습니다.

유형 추론은 기본적으로 꺼져 있으므로 `id="2"`도 `"2"` 문자열을 유지합니다. 추론을 활성화하면 파서가 숫자 및 부울 텍스트를 해당 JavaScript 유형으로 읽을 수 있지만 XML는 해당 의도를 선언하지 않았습니다. 옵션은 문서에서 제공하는 증거가 아니라 사용자가 제어하는 ​​추측입니다.

여기서 다루지 않는 내용 — 요소가 항상 목록임을 아는 스키마 기반 변환에는 XSD 또는 수동 매핑이 필요합니다.

XSD가 로드되지 않으며 스키마 기반 목록 정보를 사용할 수 없습니다. 변환기는 요소가 하나만 나타날 때 요소가 반복 가능하다는 것을 알 수 없고, 필수 하위 항목의 유효성을 검사하고, 네임스페이스 URI를 애플리케이션 유형으로 확인하거나, 형식화된 클라이언트를 생성할 수 없습니다. 성공적인 구문 분석은 구성된 판독기에서 허용하는 올바른 형식의 XML만 설정합니다.

DOCTYPE 선언은 무해한 선언을 포함하여 구문 분석 전에 거부됩니다. 해당 경계는 외부 엔터티 요청, 로컬 파일 읽기 및 엔터티 확장을 방지합니다. DOCTYPE을 제거하면 문서가 의존하는 선언도 제거될 수 있으므로 데이터를 소유하고 결과를 이해할 때만 그렇게 하십시오.

요점: XML에서 JSON은 번역이 아닌 매핑입니다. 구문 변환기 패널을 사용하면 브라우저에서 해당 매핑을 검사할 수 있습니다.

결과를 ToolAcre의 문서화된 매핑으로 처리합니다: 속성의 경우 `@`, 혼합 요소 텍스트의 경우 `#text`, CDATA의 경우 `#cdata`, 반복되는 형제 및 리터럴 네임스페이스 접두사 뒤의 배열. 이러한 규칙은 XML 및 JSON가 하나의 데이터 모델을 공유하는 것처럼 가장하지 않고도 출력을 예측 가능하게 만듭니다.

검사를 위해 이 투영은 빠르고 읽기 쉽습니다. 지속적인 통합을 위해 하나 이상의 발생, 하위 항목과 이름을 공유하는 속성, 빈 요소, 혼합 콘텐츠 및 네임스페이스를 테스트하세요. 요소 순서 또는 스키마 제약 조건이 중요한 경우 일반적으로 변환된 모양에 의존하기보다는 해당 계약에 대해 XML을 구문 분석하세요.

정규화된 기대치 옆에 원시 XML 고정 장치를 유지합니다. 종속성 업그레이드로 인해 배열 처리, 공백 트리밍 또는 엔터티 디코딩이 변경되는 경우 이러한 쌍은 증거를 보존합니다. 또한 검토자에게 JSON 뷰가 전달할 수 없는 차이점을 확인할 수 있는 장소를 제공합니다. 변환된 객체만으로는 빈 문자열이 자체 닫는 요소, 쌍을 이루는 태그 또는 소스의 다른 규칙에서 왔는지 여부를 증명할 수 없습니다.