24 converter 단위 · 통화 · 파일

JSON를 XML로 변환 JavaScript Object Notation ↔ Extensible Markup Language 무료 온라인 안전

JSON 파일을 놓고 XML를 가져가십시오. 읽기도 쓰기도 여기, 여러분의 브라우저 안에서 이루어지므로 파일은 기기를 떠나지 않습니다 — 그리고 건너가며 남는 것과 남지 못하는 것은 아래에 적어 두었습니다, 여러분이 겪어서 알게 되는 대신에.

파일 변환하기

여기에 JSON 파일을 놓거나 하나 고르십시오.

파일은 이 기기를 벗어나지 않습니다. 모든 처리가 브라우저 안에서 이뤄집니다.

이 변환기에 대하여
유지되는 것 나무 전체. 키가 하나뿐인 객체는 그 키로 문서를 이름 짓기에, XML을 JSON으로 갔다 돌아온 것은 제 모습을 닮습니다. 배열은 제 요소를 되풀이하고, @로 시작하는 키는 속성이 됩니다.
할 수 없는 것 JSON 키는 어떤 낱말이라도 될 수 있지만 XML 요소 이름은 그렇지 않습니다. 쓸 수 없는 이름의 키는 억지로 비틀리지 않고 <item name="…">이 됩니다. 원래 것이 여전히 파일 안에 있고 여전히 찾아집니다. 이름공간도 스키마도 붙이지 않습니다. 결과는 형식이 바른 것이지 검증된 것이 아닙니다.
어디에서 도는가 브라우저 안에서요. 아무것도 올리지 않으니 나중에 지울 것도 남지 않습니다.

업로드 없음

이 형식들은 어디에서 왔는가

CSV는 가장 오래되었고 가장 덜 표준화된 것입니다. 표를 글줄로 적은 것으로, 1970년대부터 쓰였으나 글로 서술된 것은 2005년이었습니다. 그때쯤에는 이미 프로그램마다 구분자가 무엇인지, 따옴표를 언제 두는지 스스로 정해 버린 뒤였습니다. XML은 1998년 SGML에서 자라났습니다. 엄한 구조를 지녀야 하고 스키마에 비추어 검사받아야 하는 문서를 위해서였습니다. JSON은 2001년 무렵 더글러스 크록퍼드가 자바스크립트에서 끄집어낸 것으로, 일부러 객체와 배열과 수와 문자열만 남기고 깎아 냈습니다. 그 덜어냄이야말로 그것이 웹을 차지한 까닭입니다. YAML은 그 읽기 좋은 사촌으로, 다른 데서 괄호가 하는 일을 들여쓰기가 맡습니다. 서로 바꿀 때 중요한 것은 오직 하나입니다. CSV는 납작한 줄과 칸의 격자이고, JSON과 XML과 YAML은 나무라는 것입니다.

어디에서 마주치는가

CSV는 표 계산이 내보내는 것이고, 회계 담당자나 상점 플랫폼이나 은행 거래 명세서가 건네주는 것입니다. JSON은 웹 서비스들이 주고받는 말이고, 설정 파일도 점점 그것으로 적힙니다. XML은 오래된 기업 체계에, 청구 표준에, 그리고 사무 형식들의 안쪽에 살아남아 있습니다. YAML은 사람이 손으로 설정을 적는 자리입니다. 이들 사이를 바꾸는 일은 자료를 만들어진 자리에서 필요한 자리로 옮기는 나날의 일입니다.

자주 묻는 질문

제 CSV가 엑셀에서 한 칸으로 열렸습니다. 왜인가요?

표 계산이 다른 구분자를 기다리고 있었기 때문입니다. 엑셀은 컴퓨터 지역 설정의 목록 구분자를 따릅니다. 쉼표가 이미 소수점 노릇을 하는 곳에서는 그것이 쌍반점입니다. 곧 유럽 대륙의 많은 곳입니다. 그러면 쉼표로 나뉜 파일이 한 칸의 글줄처럼 보입니다. 파일을 두 번 눌러 여는 대신, 가져오기 창을 쓰고 구분자를 분명히 말해 주십시오. 3.5가 때때로 날짜로 도착하는 것도 같은 지역 설정 탓입니다.

중첩된 제 JSON은 왜 말끔한 표 계산이 되지 않나요?

표 계산은 납작하고 JSON은 나무이기 때문입니다. 한 줄은 칸마다 값 하나를 담습니다. JSON 객체는 어떤 밭 안의 목록 안에 또 목록을 담을 수 있습니다. 바꾼다는 것은 그것을 어떻게 납작하게 두드릴지 고르는 일입니다. 중첩된 이름들을 한 줄의 긴 칸 머리글로 잇거나, 어버이 줄을 자식 수만큼 되풀이하거나. 둘 다 양보이고, 어느 쪽도 저절로는 되돌릴 수 없습니다. 표 계산에서 본디 모습으로 돌아가는 데 대개 사람의 결정이 필요한 까닭이 그것입니다.

파일의 질이 떨어지나요?

두 형식이 무엇을 담을 수 있느냐에 달렸습니다. 같은 것을 담는 형식 사이의 변환 — PNG에서 BMP로, WAV에서 FLAC으로 — 은 아무것도 잃지 않습니다. 자리를 아끼려고 정보를 버리는 형식, 이를테면 JPEG이나 MP3으로 바꾸면 할 때마다 조금씩 잃고, 되돌려도 돌아오지 않습니다. 고를 수 있는 자리에서 이 쪽은 가장 작은 파일을 만들기보다 본디의 질을 지키는 쪽으로 기웁니다.

제 파일이 어딘가로 올라가나요?

아니요. 변환은 여러분의 기계 위, 여러분의 브라우저 안에서 이루어집니다. 파일은 그곳을 떠나지 않으며, 여기에는 그것을 받을 서버도 없습니다. 큰 파일을 가로막는 것이 업로드가 아니라 여러분 자신의 기억 장치인 까닭, 여러분이 변환한 어떤 것도 누구의 기록에도 — 우리의 기록에도 — 나타날 수 없는 까닭이 그것입니다. 다만 소리와 영상 도구는 처음 쓸 때 변환 기관을 이곳에서 받아 옵니다. 삼십 메가바이트쯤, 한 번뿐입니다. 그 뒤로도 일은 모두 여러분의 기계 위에서 이루어집니다.

사람들이 JSON을 XML로 변환하는 이유

JSON은 현대 웹 코드의 언어입니다. 가볍고, 읽기 쉽고, 모든 프로그래밍 언어가 이해합니다. XML은 더 오래되고 더 형식적인 형제로, 열고 닫는 태그로 쓰이며 놀랄 만큼 많은 곳에서 아직도 필수 형식입니다. 회계 프로그램, 세금과 관세 시스템, 공공 조달 플랫폼, 상품 피드, 출판 작업 흐름, 기업용 소프트웨어, 그리고 긴 목록의 오래된 웹 서비스가 모두 XML을 기대합니다. 데이터가 JSON인데 그것을 받아야 하는 시스템이 XML을 쓴다면 변환이 필요합니다. 그래서 사람들이 JSON을 XML로 변환합니다. 정보는 한 형태로 있는데 목적지가 다른 형태를 요구하는 것입니다.

상황은 흔합니다. 현대적인 애플리케이션에서 몇 해 전에 만든 서비스로 데이터를 보내야 하는 개발자. 상품을 JSON으로 내보내는데 XML을 원하는 마켓플레이스에 피드를 넘겨야 하는 상점. 도구가 선호하는 마크업 형태의 설정이 필요한 팀. 같은 데이터가 두 표기법에서 어떻게 보이는지 보고 싶은 학생. 어느 경우든 내용은 준비되어 있고 표기법만 다릅니다.

이 페이지는 브라우저에서 JSON을 XML로 변환합니다. 파일은 여기서 읽고 쓰이므로 기기를 떠나지 않아 주문, 청구서, 그 밖의 사적인 것에 중요한 점입니다. 그리고 페이지는 이 변환이 무엇을 유지하고 무엇을 유지하지 못하는지를 직접 알아내게 두는 대신 미리 알려 줍니다. 아래에서 변환이 어떻게 작동하는지, 이름, 목록, 속성이 어떻게 다루어지는지, XML이 받아들이지 못하는 키는 어떻게 해야 하는지 보실 수 있습니다.

변환이 작동하는 방식

트리 전체가 옮겨집니다

JSON 파일은 브라우저 안에서 읽고 트리 전체가 XML로 쓰입니다. 객체는 요소가 되고, 키는 자식 요소의 이름이 되며, 값은 안의 텍스트가 됩니다. JSON의 중첩은 XML의 중첩이므로 중괄호로 보이는 모양이 그대로 태그로 얻는 모양입니다.

문서는 하나뿐인 키의 이름을 따릅니다

XML 문서에는 정확히 하나의 루트 요소가 필요합니다. JSON 객체에 키가 하나뿐이라면 그 키가 문서의 이름이 됩니다. 이것이 편리한 경우입니다. JSON으로 갔다가 돌아온 XML 파일은 자기 자신처럼 보이는데, 루트 요소가 하나뿐인 키가 되었다가 루트 요소로 돌아오기 때문입니다. JSON의 최상위에 키가 여러 개라면 변환기는 결과가 올바른 형식이 되도록 그것들을 루트 요소로 감쌉니다.

목록은 요소를 반복합니다

배열은 요소를 반복합니다. 레코드 세 개의 목록을 담은 키 products는 product 요소 세 개를 차례로 주며, 이것이 XML이 목록을 표현하는 방식입니다. 순서는 유지됩니다.

유지되는 것

트리 전체

모든 객체, 모든 목록, 모든 값이 옮겨집니다. 버려지는 것은 없으며 중첩은 원본의 중첩입니다.

@를 통한 속성

@로 시작하는 키는 속성이 됩니다. 키 @id와 키 name이 있는 레코드는 속성 id와 자식 요소 name이 있는 요소를 줍니다. 이는 반대 변환이 쓰는 것과 같은 규칙이므로 JSON으로 갔다가 돌아온 XML은 속성을 유지합니다.

순서

키는 JSON에 나타난 순서를 유지하므로 XML의 요소는 원본의 순서를 따릅니다.

JSON을 XML로 변환하기 전에 알아야 할 것

JSON 키는 무엇이든 단어가 될 수 있지만 XML 이름은 그렇지 않습니다

JSON 키는 단어, 숫자, 공백이 든 구절이 될 수 있습니다. XML 요소 이름은 그럴 수 없습니다. 글자나 밑줄로 시작해야 하고 글자, 숫자, 하이픈, 밑줄, 점을 포함할 수 있지만 공백은 안 됩니다. 올바른 이름이 아닌 키는 억지로 이름으로 바뀌지 않습니다. name 속성이 있는 item 요소가 되며, item name="원래의 키"로 쓰이므로 원본이 여전히 파일에 있고 여전히 찾을 수 있습니다. 소리 없이 이름이 바뀌는 일은 없습니다.

네임스페이스도 스키마도 없습니다

네임스페이스를 붙이지도, 스키마를 주지도 않습니다. 결과는 올바른 형식이지만 검증된 것은 아닙니다. 어떤 XML 판독기에서든 읽히겠지만 세금 시스템이나 마켓플레이스가 요구하는 특정 구조를 충족하는지는 별개의 문제이며 받는 쪽만 답할 수 있습니다. 스키마가 특정한 요소 이름을 요구한다면 미리 JSON 키를 그에 맞춰야 합니다.

값은 텍스트입니다

XML에는 형식이 없습니다. 태그 안의 모든 값은 텍스트입니다. 숫자, true, false, null은 그 텍스트로 쓰입니다. XML을 읽는 프로그램이 알아서 해석해야 합니다.

여기서 JSON을 XML로 변환하는 방법

파일을 추가하세요

JSON 파일을 페이지에 놓거나 기기에서 고르십시오. 브라우저 안에서 읽으며 업로드되지 않습니다.

변환하세요

버튼을 누르십시오. 보통 크기의 파일은 잠깐이면 됩니다. 끝날 때까지 페이지를 열어 두십시오.

내려받아 확인하세요

XML을 내려받아 텍스트 편집기나 브라우저에서 여십시오. 시작과 끝을 보고 요소 이름이 기대한 대로인지, 속성이 의도한 곳에 나타나는지 확인하십시오.

JSON과 XML을 자세히 보기

트리를 쓰는 두 가지 방법

JSON과 XML은 모두 값의 트리를 설명합니다. JSON은 중괄호와 대괄호로 쓰며 객체, 목록, 문자열, 숫자, 불리언, null만 압니다. XML은 열고 닫는 태그로 쓰며 속성, 네임스페이스, 혼합 내용을 더합니다. 레코드와 설정 같은 데이터에서는 잘 겹치고, 글과 마크업이 섞이는 문서에서는 잘 겹치지 않습니다.

규칙이 중요한 이유

JSON에는 속성도, 루트 요소도, 요소를 반복한다는 개념도 없습니다. 그래서 어떤 변환이든 규칙이 필요합니다. 속성에는 @, 루트에는 하나뿐인 키, 목록에는 요소의 반복입니다. 여기서 쓰는 규칙은 단순하고 일관되며, XML에서 JSON으로 갈 때 쓰는 것과 일치하므로 흔한 경우에 왕복이 작동합니다.

빈 값

빈 문자열과 null은 모두 빈 요소가 됩니다. 받는 시스템에서 그 차이가 중요하다면 JSON을 XML로 변환하기 전에, 예를 들어 별도의 플래그로 데이터에 표시하십시오.

자세히 보는 흔한 상황

마켓플레이스와 비교 사이트용 피드

많은 플랫폼이 상품 피드를 XML로 요구합니다. 상점 소프트웨어가 JSON으로 내보낸다면 JSON을 XML로 변환하고, 요소 이름을 플랫폼의 명세와 대조한 뒤 올리십시오.

오래된 서비스와 기업 시스템

SOAP와 초기 API의 시대에 만든 시스템은 XML을 기대합니다. 현대적인 애플리케이션은 JSON을 만들고 그들을 위해 변환할 수 있습니다.

XML을 선호하는 도구의 설정

일부 빌드 도구, 콘텐츠 시스템, 데스크톱 프로그램은 XML에서 설정을 읽습니다. JSON으로 쓴 설정을 그들이 필요로 하는 형태로 바꿀 수 있습니다.

배우고 비교하기

같은 데이터를 두 표기법으로 보는 것은 둘이 어떻게 다른지 이해하는 좋은 방법입니다. 작은 JSON을 붙여 넣어 변환하고 둘을 나란히 비교해 보십시오.

JSON을 XML로 변환하기 전의 실용적인 조언

JSON이 유효한지 확인하세요

떠돌이 쉼표나 빠진 따옴표가 변환을 멈추게 합니다. 페이지가 오류를 알리면 JSON 문제를 강조 표시하는 편집기에서 파일을 열어 가리키는 줄을 고치십시오.

키를 올바른 요소 이름으로 만드세요

XML을 스키마와 대조해 검사할 것을 안다면 올바른 이름이면서 스키마와 맞는 키를 쓰십시오. 그렇지 않으면 변환기가 그것들을 item 요소로 안전하게 보존하는데, 이는 옳지만 받는 쪽이 기대하는 것은 아닐 수 있습니다.

최상위 키를 하나만 고르세요

XML의 루트 요소가 특정한 이름을 갖기를 원한다면 JSON을 XML로 변환하기 전에 데이터를 그 키 하나만 있는 객체로 감싸십시오.

큰 파일

모든 것이 당신의 기기에서 실행되므로 아주 큰 파일에는 메모리가 필요합니다. 수 메가바이트의 파일이라면 컴퓨터를 쓰고, 페이지가 버거워하면 데이터를 나누십시오.

변환하기 전에 사람들이 묻는 질문

무엇이 루트 요소의 이름을 정하나요?

키가 하나뿐인 객체는 그 키를 따라 문서의 이름을 정합니다.

속성은 어떻게 얻나요?

키를 @로 시작하십시오. 요소의 속성이 됩니다.

공백이 있는 키는 어떻게 되나요?

올바른 요소 이름이 아니므로 원래의 키를 담은 name 속성이 있는 item 요소가 됩니다. 잃는 것은 없습니다.

XML이 스키마 검사를 통과하나요?

결과는 올바른 형식이지만 검증된 것은 아닙니다. 주어진 스키마를 충족하는지는 요소 이름과 구조에 달려 있습니다.

파일이 업로드되나요?

아니요. 변환은 브라우저에서 실행되며 파일은 기기를 떠나지 않습니다.

JSON으로 되돌아갈 수 있나요?

네. XML을 JSON으로가 속성에 같은 규칙을 적용해 XML 트리를 다시 읽습니다.

JSON을 XML로 변환할 때의 현명한 선택

정말 XML이 필요한가?

받는 시스템이 JSON을 받아 준다면 JSON을 쓰십시오. XML이 요구될 때만 변환하십시오.

다른 목적지

사람이 편집하는 설정에는 JSON을 YAML로가 더 편하게 읽힙니다. 표에는 JSON을 CSV로와 JSON을 XLSX로가 스프레드시트에 쓰입니다.

JSON을 보관하세요

JSON이 마스터입니다. 형식을 담고 있습니다. 그것을 보관하고 XML은 특정한 받는 쪽을 위해 만든 사본으로 다루십시오.

변환 뒤에 좋은 결과를 얻기

브라우저에서 여세요

브라우저는 XML을 접을 수 있는 트리로 보여 줍니다. 파일을 열어 요소를 펼치십시오. 구조가 기대한 대로 보인다면 건전합니다.

몇 레코드를 원본과 비교하세요

중간의 레코드 몇 개를 JSON과 대조하십시오. 일 분이면 되고 변환이 충실하다는 것을 알려 줍니다.

받는 쪽이 필요로 하는 것을 더하세요

받는 쪽이 선언 줄, 네임스페이스, 스타일시트 참조를 요구한다면 텍스트 편집기에서 더하십시오. 이들은 데이터의 일부가 아니므로 대신 써 주지 않습니다.

잘 변환되도록 JSON 준비하기

규칙적인 구조를 쓰세요

JSON을 XML로 변환할 때는 규칙적인 데이터가 가장 잘 변환됩니다. 같은 키를 공유하고 키마다 올바른 이름인 레코드 목록입니다. 불규칙한 데이터는 올바르지만 지저분한 결과를 냅니다.

무엇이 속성인지 정하세요

식별자, 코드, 플래그는 XML에서 속성인 경우가 많습니다. JSON에서 @로 표시하면 결과는 사람이 쓰는 XML처럼 보입니다.

먼저 작은 조각으로 시험하세요

파일이 크다면 처음 몇 레코드를 시험 파일에 가져와 변환하십시오. 결과를 잠깐 보면 모양이 기대한 대로인지 알 수 있습니다.

XML을 받는 쪽에 맞추기

먼저 명세를 보세요

마켓플레이스, 세금 포털, 파트너를 위해 JSON을 XML로 변환하기 전에 그들이 요구하는 것을 읽으십시오. 대부분은 기대하는 요소, 순서, 필수 여부에 대한 설명을 공개합니다. 키 이름을 그에 맞추는 데는 JSON에서 몇 분이 들지만 나중의 업로드 실패를 막아 줍니다.

순서가 중요할 수 있습니다

일부 XML 스키마는 요소가 정해진 순서이기를 요구합니다. 변환기는 키의 순서를 유지하므로 받는 쪽이 순서를 고집한다면 JSON 키를 그 순서로 쓰십시오. 결과는 쓴 그대로를 따릅니다.

필요하면 선언을 더하세요

맨 위에 버전과 인코딩을 밝히는 한 줄은 관례이고 일부 받는 쪽은 고집합니다. 데이터의 일부가 아니므로 대신 써 주지 않습니다. 첫 요소 앞에 텍스트 편집기에서 직접 더하십시오.

특수 문자에 유의하세요

값 안의 앰퍼샌드, 꺾쇠괄호, 따옴표는 이스케이프된 형태로 쓰이므로 텍스트에 무엇이 들어 있든 XML은 유효하게 유지됩니다. JSON에서 미리 준비할 필요가 없습니다.

받아들여진 견본을 보관하세요

받는 쪽이 파일을 받아들이면 바로 그 파일과 그것을 만든 JSON의 사본을 보관하십시오. 나중의 업로드가 실패하면 작동했던 것과 비교해 차이를 곧바로 찾을 수 있습니다.

직접 고치지 말고 변환을 되풀이하세요

데이터가 바뀌면 JSON을 바꾸고 JSON을 XML로 다시 변환하십시오. XML을 직접 고치면 서로 어긋나는 두 버전이 남습니다.

개인정보와 처리

데이터에 로컬 변환이 중요한 이유

데이터 파일은 흔히 사적인 것을 담고 있습니다. 고객, 주문, 청구서, 설정입니다. 많은 온라인 변환기는 파일을 서버에 올려 처리한 뒤 결과를 돌려보내며, 한동안 사본이 당신이 통제하지 못하는 기계에 남습니다. 여기서는 당신의 브라우저가 일을 하므로 데이터가 기기에 남습니다.

떠날 때 일어나는 일

페이지를 닫으면 변환된 파일이 브라우저에서 사라지므로 먼저 내려받으십시오. 데이터에 대한 어떤 것도 보관되지 않습니다.

문제가 생겼을 때

페이지가 JSON이 유효하지 않다고 말합니다

떠돌이 쉼표, 빠진 따옴표, 닫히지 않는 괄호가 있을 수 있습니다. JSON 오류를 강조 표시하는 편집기에서 파일을 열어 가리키는 줄을 고치십시오.

받는 쪽이 XML을 거부합니다

결과는 올바른 형식이지만 검증된 것은 아닙니다. 받는 쪽의 명세와 비교해서 JSON의 키 이름과 구조를 조정하십시오.

큰 파일에서 페이지가 멈춥니다

모든 것이 기기에서 실행되며 큰 파일에는 메모리가 필요합니다. 컴퓨터에서 다시 시도하거나 데이터를 나누십시오.

관련 도구

같은 계열의 도구가 이웃한 일들을 다룹니다. 되돌아가려면 XML을 JSON으로를 쓰십시오. 설정 파일에는 JSON을 YAML로와 YAML을 JSON으로가 둘 사이를 변환합니다. 표에는 JSON을 CSV로, CSV를 JSON으로, JSON을 XLSX로, XLSX를 JSON으로가 있습니다.

풀이한 예시

상점 소프트웨어가 상품 300개를 JSON으로 내보내고, 마켓플레이스가 catalogue라는 루트 요소가 있는 XML 피드를 요구한다고 해 봅시다. 목록을 catalogue라는 키 하나만 있는 객체로 감싸고, 여기에 파일을 놓고 버튼을 누릅니다. 잠시 뒤 루트가 catalogue이고 product 요소 300개를 담은 XML을 내려받는데, 키를 @id로 썼기 때문에 각 요소의 id가 속성으로 들어 있습니다. 피드를 올리면 마켓플레이스가 받아들입니다. JSON은 원본으로 폴더에 남습니다.

짧은 점검표

변환하기 전에

JSON이 유효한지 확인하십시오. 루트 이름을 고르십시오. 속성은 @로 표시하십시오. JSON을 보관하십시오.

변환하는 동안

파일이 준비될 때까지 페이지에 머무르십시오.

변환한 뒤에

XML을 열고, 요소 이름, 속성, 목록을 확인하고, 받는 쪽과 시험해 보십시오.

흔한 실수

결과가 검증되었다고 가정하는 것

XML은 올바른 형식이지만 어떤 스키마와도 대조되지 않았습니다. 받는 쪽의 규칙에 맞춰 검증하십시오.

공백이나 기호가 든 키를 쓰는 것

name 속성이 있는 item 요소가 됩니다. 받는 쪽이 기대한다면 올바른 이름을 쓰십시오.

JSON을 지우는 것

보관하십시오. XML이 담을 수 없는 형식을 담고 있습니다.

데이터는 기기에 남습니다

변환은 로컬에서 이루어집니다. 파일은 당신의 브라우저가 읽어 그 안에서 다시 쓰고 XML로 돌려줍니다. 아무것도 업로드되지 않으므로 서버에 사본이 남지 않고 다른 누구도 읽을 수 없습니다. 사적인 내용이 든 데이터에는 그것이 JSON을 XML로 변환하는 안전한 방법입니다.

요약

여기서 JSON을 XML로 변환하려면 파일을 놓고 버튼을 누르십시오. 브라우저에서 읽고 쓰이므로 파일은 기기를 떠나지 않습니다. 트리 전체가 유지됩니다. 키가 하나뿐인 객체는 그 키를 따라 문서의 이름을 정하므로 JSON으로 갔다가 돌아온 XML 파일은 자기 자신처럼 보이고, 배열은 요소를 반복하고, @로 시작하는 키는 속성이 됩니다. JSON 키는 무엇이든 단어가 될 수 있지만 XML 요소 이름은 그렇지 않습니다. 올바른 이름이 아닌 키는 억지로 이름으로 바뀌지 않고 name 속성이 있는 item 요소가 되므로 원본이 여전히 파일에 있고 여전히 찾을 수 있습니다. 네임스페이스도 스키마도 없습니다. 결과는 올바른 형식이지만 검증된 것은 아닙니다.

길이와 넓이 질량과 부피 온도 통화