JSON 및 XML 비교 [닫기]

XML과 JSON 중 어느 것이 더 빠른지 알고 싶습니다. 어느 것을 사용할 때?

어느 것을 사용 해야하는지 대답하기 전에 약간의 배경 지식 :

편집 :이 비교는 실제로 JavaScript가있는 브라우저에서 사용하는 관점에서 비롯된 것입니다. 이 중 데이터 형식이 방식이 아니다 가 사용하는, 내가 꽤 유효한 무슨 말인지 확인하기 위해 세부 사항을 변경합니다 좋은 파서 많이 있습니다.

JSON은 더 작고 읽기 편합니다. 전송시 더 적은 데이터가 전송되기 때문에 전송 속도가 더 빠릅니다.

파싱에서는 파서에 따라 다릅니다. 코드 (JSON 또는 XML)를 데이터 구조 (예 : 맵)로 바꾸는 파서는 XML의 엄격한 특성 ( XML 스키마 는 데이터 구조를 명확하게 명확하게 함) 에서 이점을 얻을 수 있지만 JSON에서는 항목 유형 (문자열 / Number / Nested JSON Object)는 구문 적으로 유추 될 수 있습니다. 예 :

myJSON = {"age" : 12,
          "name" : "Danielle"}

파서는 12숫자 를 나타내는 (그리고 Danielle다른 문자열과 같은) 것을 인식하기에 충분히 지능적 일 필요는 없습니다 . 그래서 자바 스크립트에서 우리는 할 수 있습니다 :

anObject = JSON.parse(myJSON);
anObject.age === 12 // True
anObject.name == "Danielle" // True
anObject.age === "12" // False

XML에서는 다음과 같은 작업을 수행해야합니다.

<person>
    <age>12</age>
    <name>Danielle</name>
</person>

(제외 적으로 이것은 XML이 좀 더 장황하다는 점을 보여줍니다. 데이터 전송에 대한 관심). 이 데이터를 사용하려면 파서를 통해 데이터를 실행 한 후 다음과 같이 호출해야합니다.

myObject = parseThatXMLPlease();
thePeople = myObject.getChildren("person");
thePerson = thePeople[0];
thePerson.getChildren("name")[0].value() == "Danielle" // True
thePerson.getChildren("age")[0].value() == "12" // True

실제로, 좋은 파서는 age당신을 위해 잘 입력 할 수 있습니다 (반면, 당신은 그것을 원하지 않을 수도 있습니다). 이 데이터에 액세스 할 때 진행되는 작업은 위의 JSON 예제에서와 같이 속성 조회를 수행하는 대신 키에서 맵 조회를 수행하는 것 name입니다. 다음과 같이 XML을 작성하는 것이 더 직관적 일 수 있습니다.

<person name="Danielle" age="12" />

그러나 데이터에 액세스하려면 여전히 맵 조회를 수행해야합니다.

myObject = parseThatXMLPlease();
age = myObject.getChildren("person")[0].getAttr("age");

편집 : 원본 :

대부분의 프로그래밍 언어에서 (일부는 아니더라도) 이와 같은 맵 조회는 속성 조회보다 비용이 많이 듭니다 (JSON을 구문 분석 할 때보 다 높음).

이것은 오해의 소지가 있습니다. JavaScript (및 기타 동적 언어)에서는 지도 조회와 필드 조회간에 차이 가 없습니다 . 실제로 필드 조회 는 지도 조회 일뿐입니다.

정말 가치있는 비교를 원한다면 벤치마킹하는 것이 가장 좋습니다. 데이터를 사용하려는 맥락에서 벤치 마크를 수행하십시오.

필자가 입력 한대로 Felix Kling은 이미 각 항목을 언제 사용해야하는지 비교하여 상당히 간결한 답변을 작성 했으므로 더 이상 진행하지 않겠습니다.

빠름 은 JSON 또는 XML의 속성이 아니거나 그 결과를 비교하면 결과가 아닙니다. 있는 경우 파서의 속성 또는 데이터를 전송하는 대역폭입니다.

다음은 JSON과 XML의 장단점 목록입니다.

JSON

찬성:

• XML에 비해 "마크 업"오버 헤드가 적은 간단한 구문.
• 마크 업은 JS 객체 리터럴 표기법의 하위 세트이며 JavaScript와 기본 데이터 유형이 동일하므로 JavaScript와 함께 사용하기 쉽습니다.
• 설명 및 데이터 유형 및 구조 유효성 검사를위한 JSON 스키마
• 깊이 중첩 된 구조에서 정보를 추출하기위한 JsonPath

범죄자:

• 간단한 구문으로 소수의 다른 데이터 유형 만 지원됩니다.

• 의견에 대한 지원이 없습니다.

XML

찬성:

• 일반화 된 마크 업; 어떤 종류의 목적 으로든 "방언"을 만들 수 있습니다
• 데이터 유형, 구조 유효성 검사를위한 XML 스키마 새로운 데이터 유형을 만들 수도 있습니다
• 다른 출력 형식으로 변환하기위한 XSLT
• 깊이 중첩 된 구조에서 정보를 추출하기위한 XPath / XQuery
• 네임 스페이스 지원 내장

범죄자:

• JSON에 비해 상대적으로 경박합니다 (동일한 양의 정보에 대해 더 많은 데이터가 생성됨).

결국 당신은 당신이 원하는 것을 결정 해야합니다 . 두 형식 모두 합법적 인 사용 사례가 있습니다. 대부분 JavaScript를 사용하려는 경우 JSON을 사용해야합니다.

장단점을 자유롭게 추가하십시오. 저는 XML 전문가가 아닙니다.)

그러나 처리 속도가 유일한 관련 문제는 아니지만 문제는 벤치 마크에 몇 가지 숫자가 있습니다 .JSON vs. XML : verbosity에 대한 몇 가지 어려운 숫자 입니다. 빠른 벤치 마크에서 XML은 JSON보다 21 %의 오버 헤드를 나타냅니다.

자세한 내용은 기사에서 알 수 있듯이 가장 일반적인 불만입니다. 실제로는 그다지 관련성이 없습니다 (XML 또는 JSON 데이터는 일반적으로 사람이 아니라 기계에 의해 처리되지 않습니다). 속도를 높이려면 압축하는 데 약간의 시간이 더 걸립니다.

또한이 벤치 마크에서 많은 양의 데이터가 처리되었으며 일반적인 웹 응용 프로그램은 90MB와 같은 크기의 데이터 청크를 전송하지 않으며 압축이 유리하지 않을 수 있습니다 (충분한 데이터 청크의 경우 압축 청크) 압축되지 않은 청크보다 큽니다).

그럼에도 불구하고 압축이 관련되지 않은 경우 JSON은 특히 WebSocket 연결을 통해 전송되는 경우 전송 채널에 비해 가중치가 적습니다. 일반적인 HTTP 오버 헤드가 없으면 JSON의 이점에 차이가 생길 수 있습니다. 중요한.

전송 후 데이터가 소비되며 전체 처리 시간이 계산됩니다. 충분히 크거나 복잡한 데이터를 전송하는 경우 유효성 검사 XML 파서가 자동으로 검사하는 스키마가 없으면 JSON 데이터를 추가로 확인해야합니다. 이러한 검사는 특히 빠르지 않은 JavaScript로 실행되어야하므로 이러한 경우 XML보다 추가 오버 헤드가 발생할 수 있습니다.

어쨌든 테스트만으로 특정 사용 사례에 대한 답변을 제공 할 수 있습니다 (속도가 실제로 유일한 문제이며 표준도 안전도 무결성도 아닙니다).

업데이트 1 : Gzip을 사용하는 것보다 적은 비용으로 압축을 제공하고 압축 된 XML을 압축 해제하는 데 필요한 처리를 저장하는 이진 XML 형식 인 EXI입니다. EXI는 XML, BSON은 JSON입니다. 공간과 시간의 효율성에 대한 몇 가지 참조와 함께 여기에 간단한 개요가 있습니다. EXI : 마지막 이진 표준? .

업데이트 2 : 효율성과 낮은 메모리 및 CPU 공간도 W3C에서 수행 한 이진 XML 성능 보고서도 XML 영역의 문제이기도합니다. 효율적인 XML 교환 평가 .

2015-03-01 업데이트

HTTP 오버 헤드가 문제로 제기되면서 이러한 맥락에서 주목할 가치가 있습니다 .IANA는 EXI 인코딩 (위에서 언급 한 효율적인 이진 XML)을 a HTTP 프로토콜의 컨텐츠 코딩 ( 압축 , 수축 및 gzip 과 함께 )으로 등록했습니다. . 이것은 EXI가 다른 HTTP 클라이언트들 사이에서 브라우저에 의해 이해 될 수있는 옵션임을 의미합니다. 하이퍼 텍스트 전송 프로토콜 매개 변수 (iana.org)를 참조하십시오 .

나는 디지털 바자에서이 기사가 정말 흥미로웠다 는 것을 알았다 . Norm에서 인용문 인용 :

JSON 전문가 정보 :

전달하려는 모든 것이 원자 가치 또는 원자 가치의 목록 또는 해시 인 경우 JSON은 XML의 많은 장점을 제공합니다. 인터넷에서 직접 사용할 수 있고 다양한 응용 프로그램을 지원하며 JSON을 처리하는 프로그램을 작성하기가 쉽습니다. 선택적 기능이 거의 없으며 사람이 읽을 수 있고 합리적이며 디자인이 형식적이고 간결하며 JSON 문서를 쉽게 만들 수 있으며 유니 코드를 사용합니다. ...

XML 전문가 정보 :

XML은 비정형 데이터의 풍부한 기능을 현저하게 처리합니다. 많은 웹 API 디자이너들이 죽음을 기쁘시게 축하하더라도 XML의 미래에 대해 전혀 걱정하지 않습니다.

그리고 나는 "너에게 그렇게 말했어!" 내 책상에 치워 더 풍부한 API를 개발하라는 요청을받을 때 JSON 사람들이하는 일을 기대합니다. 덜 잘 구조화 된 데이터를 교환하려고 할 때 JSON으로 데이터를 분산시킬 것인가? JSON 용 스키마 언어에 대한 언급이 가끔 있는데 다른 언어가 뒤따를까요? ...

나는 개인적으로 Norm에 동의합니다. XML에 대한 대부분의 공격은 일반적인 개발자가 아니라 일반적인 응용 프로그램에 대한 웹 개발자의 공격이라고 생각합니다. 그러나 그것은 나의 의견이다! ;)

XML (Extensible Markup Language)은 표준 방송 언어이므로 모든 프로그래밍 언어에서 사용할 수 있고 서버 및 클라이언트 측 모두에서 지원되므로 가장 유연한 솔루션이므로 XHR이 자주 사용됩니다. 더 많은 부분에 대해 XML을 분리하여 지정된 그룹이 다른 부분에 영향을주지 않고 프로그램의 부분을 개발할 수 있습니다. XML 형식은 XML DTD 또는 XML 스키마 (XSL)에 의해 결정될 수도 있고 테스트 될 수 있습니다.

JSON은 데이터 교환 형식으로 JavaScript 응용 프로그램 형식으로 널리 사용되고 있습니다. 기본적으로 이것은 객체 표기법 배열입니다. JSON은 매우 간단한 구문이므로 쉽게 배울 수 있습니다. 또한 JavaScript는 eval함수로 JSON 구문 분석을 지원 합니다. 반면에, eval함수는 부정적입니다. 예를 들어, 프로그램의 JSON 구문 분석 속도가 매우 느릴 eval수 있으며 보안 상 매우 위험 할 수 있습니다. 이것은 JSON이 좋지 않다는 것을 의미하는 것이 아니라 더 조심해야합니다.

게임과 같이 가벼운 데이터 교환이 가능한 응용 프로그램에는 JSON을 사용해야한다고 제안합니다. 실제로 데이터 처리에 신경 쓸 필요가 없으므로 매우 간단하고 빠릅니다.

XML은 쇼핑 사이트 나 이와 같은 더 큰 웹 사이트에 가장 적합합니다. XML은보다 안전하고 명확 할 수 있습니다. 기본 데이터 구조 및 스키마를 작성하여 수정을 쉽게 테스트하고이를 부분으로 쉽게 분리 할 수 ​​있습니다.

속도와 보안 때문에 XML을 사용하는 것이 좋지만 가벼운 작업에는 JSON을 사용하는 것이 좋습니다.

JSON의 중요한 점은 보안상의 이유로 데이터 전송을 암호화 된 상태로 유지하는 것입니다. JSON이 XML보다 훨씬 빠르다는 것은 의심의 여지가 없습니다. JSON이 60ms 밖에 걸리지 않는 XML은 100ms가 걸립니다. JSON 데이터는 조작하기 쉽습니다.