답변:
다음 중 하나에 해당하면 JSON보다 XML을 선호하십시오.
다음과 같은 경우 JSON보다 XML을 선호하십시오.
XML을 사용해야하는 경우가 아니면 JSON을 사용합니다. 이해하기가 더 쉽고 (구성 오버 헤드가 덜 필요하기 때문에) 라이브러리가 사용자의 컨텍스트에서 사용 가능한 경우 읽기 및 쓰기를 위해 프로그래밍하기가 더 쉬우 며 현재는 어디에나 있습니다.
아마존이 카탈로그를 웹 서비스로 처음 공개했을 때 JSON과 XML을 모두 제공했습니다. 구현 자의 90 %가 JSON을 선택했습니다.
클라이언트 측에서 이미 자바 스크립트를 수행하는 특정 사례를 고려할 때 다음과 같은 이유로 JSON을 사용합니다.
JSON은 자바 스크립트에 고유하므로 클라이언트 쪽에서 더 적은 코드를 작성해야합니다. eval()JSON.parse() 즉 JSON 문자열 만 사용하고 더 나은 방법으로 사용할 수있는 객체를 가져와야합니다.
동시에 클라이언트 측에서 JSON을 평가하는 것이 더 효율적이므로 더 빠릅니다.
JSON 직렬화는 XML보다 짧은 문자열을 생성합니다. JSON을 사용하면 유선으로 전송되는 데이터 양이 줄어들고 그 점에서 성능이 향상됩니다.
더 읽을 거리가 있습니다 : http://www.subbu.org/blog/2006/08/json-vs-xml
eval()아니 노 JSON에게 큰를 보내고하지?
XML 대 JSON relm에서 내가 본 다른 것들 :
JSON은 매우 좋습니다
즉, 배열이나 중첩 배열을 좋아하는 경향이 있습니다. 그러나 JSON에는 둘 다 없습니다.
따라서 둘 이상의 JSON 서비스를 결합하려는 경우 네임 스페이스 충돌이 발생할 수 있습니다. 즉, JSON은 내 경험에서 데이터를 교환 할 때 XML을 사용할 수있는 것과 같은 것의 약 90 %에 사용할 수 있습니다.
일반적으로 JSON은 더 작고 구문 분석하기가 더 빠릅니다.
다음과 같은 경우 XML을 선호하십시오.
(거의) XML의 한 가지 중요한 경우 : HTML 스 니펫을 보낼 때 감지하는 것이 원시 데이터를 보내는 것보다 유리합니다. AHAH 는 간단한 응용 프로그램에서 놀라운 일을 할 수 있지만 간과되는 경우가 많습니다. 일반적으로이 스타일은 서버가 처리하지 않고 웹 페이지에 인라인 될 HTML 스 니펫을 전송한다고 가정합니다.
일반적으로 AHAH의 경우 CSS는 최대한 스 니펫을 시각적으로 마사지하고 사용자 별 또는 애플리케이션 별 설정을 사용하여 스 니펫의 관련 부분을 숨기거나 표시하는 것과 같은 간단한 조건을 구현하기 위해 최대한 활용됩니다.
JSON은 쉽고 빠르게 구문 분석 할 수 있습니다. XML은 구문 분석하기가 조금 더 어렵고 구문 분석 및 전송 속도가 느립니다 (대부분의 경우).
jQuery를 사용하고 있으므로 JSON을 사용하는 것이 좋습니다. jQuery는 JSON 데이터를 검색하여 자동으로 Javascript 객체로 변환 할 수 있습니다. 실제로 eval을 사용하여 JSON 데이터를 Javascript 객체로 변환 할 수 있습니다 . XML은 수동으로 전달해야합니다 (Javascript에서 어떻게 작동하는지 모르겠지만 XML 라이브러리를 사용하는 대부분의 언어에서는 어렵거나 더 성가시다).
웹 프로토콜 (예 : SOAP, XML, JSON, REST, POX 등)의 역사를 자세히 설명하는 주제에 대한 블로그 게시물이 있으며 각각의 장단점과 요약을 제공합니다. http://www.servicestack.net / mythz_blog /? p = 154
실제로 동적 (JSON) 언어와 정적 (XML) 언어의 차이점을 비교하여 XML과 JSON 사이에 많은 유사점을 그릴 수 있다고 생각합니다.
기본적으로 XML은 더 엄격하고 더 엄격한 직렬화 형식으로, 동반 스키마 (XSD 또는 DTD)로 선택적으로 확인할 수 있습니다. XSD는 매우 정교하며 날짜, 시간, 열거, 사용자 정의 유형 및 유형 상속 등 다양한 유형을 설명 할 수 있습니다. SOAP는 XML 기능 세트 위에 효과적으로 구축되어 웹 서비스를 설명하는 표준화 된 방법을 제공합니다 ( WSDL을 통한 유형 및 작업) WSDL 스펙의 상세 성과 복잡성은 개발하기가 더 지루할 수 있지만 동시에 더 많은 툴링을 사용할 수 있으며 대부분의 현대 언어는 클라이언트 프록시를 생성하는 자동화 된 툴을 제공하여 일부 부담을지고 있습니다. 외부 서비스와 상호 운용하려고 할 때 꺼집니다.
자주 변경되지 않는 잘 정의 된 '엔터프라이즈 서비스'가 있거나 다른 언어로 웹 서비스에 액세스해야하는 경우에도 웹 서비스에 XML을 사용하는 것이 좋습니다.
모든 이점을 위해 XML에는 단점도 있습니다. 형식화 된 확장 가능한 형식을 제공하기 위해 네임 스페이스를 사용하며 동일한 문서 내에서 속성과 요소를 지정할 수 있습니다. 하나의 문서 내에 다른 네임 스페이스가 있다는 것은 Xml 파서를 사용하여 데이터를 추출 할 때 많은 시간을 의미한다는 것입니다. 또한 검색 / 탐색하려는 각 요소의 네임 스페이스를 제공해야합니다. 또한 페이로드를 외삽하여 필요한 것보다 더 장황하게 만듭니다. 요소뿐만 아니라 속성을 출력하는 옵션이 있으면 클래스가 XML 문서에 잘 매핑되지 않습니다. 이러한 기능만으로도 대부분의 언어에서 프로그래밍 방식에 적합하지 않으므로 작업이 더 번거롭고 번거로워집니다.
반면 JSON은 XML의 형식이 매우 느슨하고 숫자, 부울, 문자열, 객체 및 배열과 같은 기본 유형 만 지원하므로 XML과 완전히 반대입니다. 다른 모든 것은 본질적으로 문자열에 맞아야합니다. 보다 구체적인 유형을 지원하려면 대역 외 비표준 사양을 준수해야하므로 언어 경계를 넘어 통신하려고 할 때 좋지 않습니다. 거꾸로 그 제한된 기능 세트는 대부분의 언어에 적합한 프로그래밍 방식으로 적합하며 JSON 문자열 을 JavaScript 객체로 직접 평가할 수 있으므로 JavaScript에 완벽하게 적합 합니다.
크기와 성능
Microsoft XML과 JSON 구현 사이의 크기와 속도를 비교할 수 있는 노스 윈드 데이터베이스 벤치 마크가 있습니다 . 기본적으로 XML은 JSON 크기의 2 배 이상이지만 동시에 Microsoft가 JSON보다 30 % 이상 빠르기 때문에 XML DataContractSerializer를 최적화하는 데 많은 노력을 기울인 것처럼 보입니다. 크기와 성능간에 균형을 맞춰야합니다. 이 사실에 만족하지 않아서 , 나는 내 자신의 빠른 JsonSerializer 를 작성하기로 결정했다. 현재 JsSerializer 는 MS의 XML보다 2.6 배 빠르다.
JSON 경로를 내려 가면 10 년 전에 XML이 겪었던 것과 같은 문제가 발생합니다.
서로 다른 두 소스의 데이터를 하나의 JSON 패킷으로 혼합하면 요소 레이블이 서로 충돌 할 수 있습니다. 포장 명세서와 송장을 섞으면 갑자기 보낸 사람 주소가 상당히 다를 수 있습니다. XML에 네임 스페이스 가있는 이유 입니다.
다른 JSON 구조를 변환하려면 평범한 코드를 작성해야합니다. 데이터를 매핑하는보다 선언적인 방법으로 작업이 쉬워집니다. XML에 XSLT 가있는 이유 입니다.
사람들이 서비스에 연결하려면 JSON 패킷의 구조 (필드, 데이터 유형 등)를 설명해야합니다. 이를 위해 메타 데이터 언어가 있어야합니다. 이것이 XML에 Schemas 가있는 이유 입니다.
두 개의 클라이언트-서버 대화를 동시에 수행하면주의를 기울입니다. 서버에 두 가지 질문을하고 한 가지 답변을 얻으면 어떤 질문에 대답하는지 어떻게 알 수 있습니까? 이것이 XML에 WS-Correlation 이있는 이유 입니다.
http://json.org/xml.html 의 첫 번째 줄에서
XML (Extensible Markup Language)은 SGML (Standard Generalized Markup Language)에서 파생 된 텍스트 형식입니다. SGML에 비해 XML은 간단합니다. 비교하면 HTML (HyperText Markup Language)이 훨씬 더 간단합니다. 그럼에도 불구하고 HTML에 대한 좋은 참고서는 1 인치 두께입니다. 문서의 형식과 구조가 복잡한 사업이기 때문입니다. . . .
분명히 JSON이 더 빠르지 만 읽기 어렵다는 것이 더 분명합니다. 속도에 JSON을 사용하고, 사람과의 상호 작용이 있고 속도를 희생 할 수 있으면 XML을 사용하십시오.
JSON 사용
XML 사용
나는 디지털 바자에서이 기사가 정말 흥미로웠다 는 것을 알았다 .
기사의 일부는 아래에 인용되어 있습니다.
JSON 전문가 정보 :
전달하려는 모든 것이 원자 가치 또는 원자 가치의 목록 또는 해시 인 경우 JSON은 XML의 많은 장점을 제공합니다. 인터넷에서 간단하게 사용할 수 있고 다양한 응용 프로그램을 지원하며 JSON을 처리하는 프로그램을 쉽게 작성할 수 있습니다. 선택적 기능이 거의 없으며 사람이 읽을 수 있고 합리적이며 디자인이 형식적이고 간결하며 JSON 문서를 쉽게 만들 수 있으며 유니 코드를 사용합니다. ...
XML 전문가 정보 :
XML은 비정형 데이터의 풍부한 기능을 현저하게 처리합니다. 많은 웹 API 디자이너가 죽음을 기쁘게 축하하더라도 XML의 미래에 대해 전혀 걱정하지 않습니다.
그리고 나는 "너에게 그렇게 말했어!" 내 책상에 토큰을 치워 더 풍부한 API를 개발하라는 요청을받을 때 JSON 사람들이하는 일을 기대합니다. 덜 잘 구조화 된 데이터를 교환하려고 할 때 JSON으로 데이터를 분산시킬 것인가? JSON에 대한 스키마 언어에 대한 언급이 가끔 있는데 다른 언어가 뒤따를까요? ...
빠른 규칙 :
설명:
JSON의 유일한 역할은 대부분의 프로그래밍 언어에 공통적 인 데이터 유형 ( list , hashes 및 scalars )을 사용하여 객체 지향 데이터를 직렬화하는 것이며 ,이를 위해 실제로 달성하거나 개선 할 수 없습니다. "JSON에는 버전 번호가 없습니다. [JSON]에는 JSON 문법에 대한 개정이 예상되지 않습니다." - 더글러스 크록 포드는 (당신이 완벽하게 일을 할 수 있다는 신호로 이길 수 없습니다)
XML 번 데이터 간 변경 형식으로 판매하지만, 가장 일반적인 두 가지 사용 사례를 고려했다 : 비동기 클라이언트 - 서버 통신 (AJAX) - JSON 꽤 많이합니다 (X는 정말 J이어야 함) 전체 XML을 대체하고있다 웹 서비스 : JSON은 XML을 중복 대안으로 만들었습니다.
XML이 널리 사용 된 또 다른 것은 프로그램 용 인간 쓰기 가능 / 판독 가능 (?) 데이터 파일이지만, 여기에도 JSON 수퍼 셋 인 YAML의보다 간결하고 프로그램 친화적이며 인간 친화적 인 형식이 있습니다.
따라서 데이터 표현의 경우 JSON이 전반적으로 XML을 능가합니다. XML에 남은 것은 무엇입니까? 혼합 컨텐츠 문서 표현 입니다 .