jQuery에 XML이 아닌 JSON을 선택하는 이유는 무엇입니까?
XML은 휴대성이 뛰어나고 미니 데이터베이스로도 사용할 수 있다고 생각했습니다.나는 XML이 어디에서나 사용되는 것을 보았다.대기업이 JSON으로 전환하는 것도 볼 수 있습니다.마이크로소프트도 JSON에 대한 지원을 통합했습니다.JSON에 대한 모든 광고는 무엇입니까?
기본적으로 JSON은 JavaScript에서 기본적으로 인식되기 때문에 매우 가볍고 최소적이며 휴대성이 뛰어납니다. 왜냐하면 JSON은 다음 두 가지 기본 구조에만 의존하기 때문입니다.
- 이름/값 쌍의 집합입니다.다양한 언어에서 이는 객체, 레코드, 구조, 사전, 해시 테이블, 키 목록 또는 연관 배열로 실현됩니다.
- 값의 순서부 리스트.대부분의 언어에서 이것은 배열, 벡터, 목록 또는 시퀀스로 실현됩니다.
XML은 서로 다른 이름으로 구성된 스키마를 혼합하기 시작할 때까지 빛을 발하지 않습니다.JSON이 다운되기 시작하는 것을 알 수 있지만 데이터에 대한 직렬화 형식만 필요한 경우 JSON은 XML보다 작고 가볍고 읽기 쉬우며 일반적으로 속도가 빠릅니다.
XML에 비해 JSON의 큰 장점은 데이터 포맷 방법을 결정할 필요가 없다는 것입니다.일부에서 알 수 있듯이 XML의 단순한 데이터 구조조차 요소, 속성값 등으로 수행할 수 있는 방법은 많습니다.그런 다음 문서화하고 XML 스키마나 릴랙스 NG 등을 작성해야 합니다.지저분하군요.
XML에는 장점이 있을 수 있지만 기본적인 데이터 교환을 위해 JSON은 훨씬 더 작고 직접적입니다.Python 개발자로서 JSON과 Python의 단순 데이터 유형 사이에 임피던스 불일치가 없습니다.따라서 특정 스키장의 눈 상태를 묻는 AJAX 쿼리용 서버 측 핸들러를 작성하면 다음과 같은 사전을 구축할 수 있습니다.
conditions = {
'new_snow_24': 5.0,
'new_snow_48': 8.5,
'base_depth': 88.0,
'comments': 'Deep and steep!',
'chains_required': True,
}
return simplejson.dumps(conditions) # Encode and dump `conditions` as a JSON string
('simplejson' for Python'과 같은 라이브러리를 사용하여) JSON을 통해 번역할 때 결과 JSON 구조는 거의 동일합니다(JSON을 제외하고, 부란은 소문자로 표시됩니다).
이 구조를 디코딩하려면 JSON 파서(Javascript용이든 Objective-C용이든 네이티브 iPhone 앱용이든 C#용이든 Python 클라이언트용이든)만 필요합니다.수레는 부유물, 현은 현, 부울란은 부울란으로 해석될 것이다.하여 Python의 'simplejson'을 합니다.simplejson.loads(some_json_string)스테이트먼트를 사용하면 위의 예에서 설명한 것처럼 완전한 데이터 구조를 얻을 수 있습니다.
XML을 작성하면 요소를 할지 속성을 할지 결정해야 합니다.다음 두 가지가 모두 유효합니다.
<conditions>
<new-snow-24>5</new-snow-24>
<new-snow-48>8.5</new-snow-48>
<chains-required>yes</chains-required>
<comments>deep and steep!</comments>
</conditions>
<conditions newSnow24="5" newSnow48="8.5" chainsRequired="yes">
<comments>deep and steep!</comments>
</conditions>
따라서 클라이언트에 송신하고 싶은 데이터뿐만 아니라 포맷 방법도 생각해야 합니다.XML은 일반 SGML보다 규칙이 엄격하기 때문에 단순하지만 그 데이터에 대해 생각할 수 있는 방법이 너무 많습니다.그리고 나서 나는 그것을 생성해야 할 것이다.Python 사전(또는 다른 간단한 데이터 구조)을 가져와 "내 XML에 직접 들어가라"고 말할 수 없습니다. XML 문서를 받고 바로 "오브젝트와 데이터 구조로 들어가라"고 말할 수 없습니다. 커스텀 파서를 작성하거나 XML 스키마/릴랙스 NG의 추가 오버헤드가 필요하지 않습니다.
즉, 데이터를 JSON으로 인코딩 및 디코딩하는 것이 훨씬 쉽고, 특히 빠른 교환을 위해 훨씬 더 직접적이라는 것입니다.이는 자바스크립트/JSON에 내장된 기본 데이터 유형(리스트, 사전 등)이 Python, Perl, Ruby 등의 동일하거나 유사한 데이터 유형에 직접 매핑되기 때문에 동적 언어 배경에서 온 사람들에게 더 적용될 수 있습니다.
JSON의 성능은 대부분의 사용 사례에서 XML과 크게 다르지 않습니다. JSON은 깊이 중첩된 구조에 적합하지 않고 읽을 수 없습니다.] } ） which which 。이 때문에 디버깅이 어려워집니다.
XML에 비해 가볍습니다.확장이 필요한 경우 대역폭 요건을 줄이십시오.
JSON 비교
[
{
color: "red",
value: "#f00"
},
{
color: "green",
value: "#0f0"
},
{
color: "blue",
value: "#00f"
},
{
color: "cyan",
value: "#0ff"
},
{
color: "magenta",
value: "#f0f"
},
{
color: "yellow",
value: "#ff0"
},
{
color: "black",
value: "#000"
}
]
XML로:
<colors>
<color >
<name>red</name>
<value>#f00</value>
</color>
<color >
<name>green</name>
<value>#0f0</value>
</color>
<color >
<name>blue</name>
<value>#00f</value>
</color>
<color >
<name>cyan</name>
<value>#0ff</value>
</color>
<color >
<name>magenta</name>
<value>#f0f</value>
</color>
<color >
<name>yellow</name>
<value>#ff0</value>
</color>
<color >
<name>black</name>
<value>#000</value>
</color>
</colors>
제 개인적인 경험에서 나온 일화입니다.
처음에는 XML의 데이터로 작은 Javascript 디렉토리를 작성한 후 JSON을 사용하도록 수정하여 나란히 실행하고 Firebug와 속도를 비교했습니다.JSON의 속도는 약 3배 빨라졌습니다(350~400ms 대 1200~1300ms).또, 다른 유저도 지적했듯이, JSON은 보기 쉽고, 파일 사이즈는 얇아지기 때문에 25%나 작아졌습니다.
<colors>
<color name='red' value='#f00'/>
<color name='green' value='#0f0'/>
<color name='blue' value='#00f'/>
<color name='cyan' value='#0ff'/>
<color name='magenta' value='#f0f'/>
<color name='yellow' value='#ff0'/>
<color name='black' value='#000'/>
</colors>
속성을 사용하면 XML이 좋습니다.그러나 어떤 이유에서인지 집에서 만든 XML은 일반적으로 100% 요소로 구성되어 있으며 추합니다.
JavaScript에 의한 간단한 소비도 그 이유 중 하나입니다.
JSON은 특히 JavaScript에 내장된 지원으로 인해 크기와 사용 편의성으로 인해 웹 서비스에서 웹 응용 프로그램의 데이터를 사용하는 데 가장 적합합니다.xml fragment를 해석할 때의 계산 오버헤드를 JSON에서의 인스턴트 룩업과 비교합니다.
JSON-P로 하다 웹 할 수 .를 들어, 함수 호출로 랩된 웹 서비스입니다.my_callback({"color": "blue", "shape":"square"});하게 생성된 " " " "<script>할 수 합니다.my_callback() 하여 이 할 수 있는
XML은 XSLT를 사용하여 여러 형식으로 데이터 페이지를 렌더링하는 프레임워크가 있는 큰 문서에서 선택하는 형식입니다.또한 XML을 응용 프로그램컨피규레이션파일과 함께 사용하면 다른 많은 용도를 읽을 수 있습니다.
XML의 주요 장점인 검증 규칙(DTD, XSD)에 대해서는 아무도 언급하지 않았습니다.두 가지를 모두 사용해 본 결론은 다음과 같습니다.
- JSON은 특히 서버와 클라이언트 양쪽을 직접 개발하는 경우 Ajax에 적합합니다.기본적으로 js 오브젝트는 서버 스크립트로 작성됩니다.
- XML은 대규모 관료 조직 간의 데이터 교환 표준을 설정해야 하는 기업 환경에서 빛을 발합니다.한 당사자가 다른 당사자보다 몇 개월 먼저 부품을 개발하는 경우가 많기 때문에 합의된 XSD에 대해 요청을 검증하는 것이 큰 도움이 됩니다.또한 대기업에서는 데이터 전송이 다른 시스템 간에 변환되는 경우가 많습니다.이것은 XML의 강점이기도 합니다.XSLT라고 생각합니다.예: 코드프리 JSON으로의 변환:p
물론, json-schema는 개발되고 있지만, 기본 제공 지원은 어디에서도 찾을 수 없습니다.
나는 두 사람의 팬이다. 그들은 단지 다른 강점을 가지고 있다.
대부분의 언어에는 JSON 인코더와 디코더가 있기 때문에 JSON을 적절한 용도로 사용하지 않을 이유가 없습니다(XML 사용 사례의 90%에 해당).
스키마 변경을 용이하게 하기 위해 대규모 SQL 데이터베이스에서 JSON 문자열이 사용되고 있다는 이야기도 들었습니다.
솔직히 JSON과 XML은 모든 유형의 데이터를 나타낼 수 있다는 점에서 크게 다르지 않습니다.그러나 XML은 구문적으로 JSON보다 크기 때문에 JSON보다 무겁습니다.
JSON에는 JavaScript 프로그래밍과의 임피던스 불일치가 없습니다.JSON에는 정수, 문자열, 목록, 배열을 포함할 수 있습니다.XML은 정수로 해석해야 사용할 수 있는 요소 및 노드입니다.
둘 다 훌륭하고 휴대성이 뛰어납니다.그러나 JSON은 대부분의 경우 문자 수가 적기 때문에 인기를 끌고 있습니다(즉, 전달 시간이 빨라집니다).또, JavaScript 오브젝트 구문에 일치하기 때문에, 인메모리 오브젝트로 직접 번역할 수 있기 때문에, Ajax를 실장하기 훨씬 쉬워집니다.
XML은 여전히 훌륭합니다.JSON은 XML에 비해 "최신이고 훌륭한" 제품입니다.
JavaScript에 의해 쉽게 구문 분석되고 가볍습니다(JSON의 문서는 동일한 데이터를 포함하는 XML 문서보다 작습니다).
JSON은 JavaScript 오브젝트에 직접 (aJsonString)을 평가할 수 있는 점에서 효과적으로 시리얼화 되어 있습니다.브라우저 내에서는 간단한 JSON이 JavaScript에 매우 적합합니다.동시에 JavaScript는 매우 느슨한 유형의 동적 언어이며 XML/Xsd 문서에 포함된 사용 가능한 모든 특정 유형 정보를 기본적으로 활용할 수 없습니다.이 추가 메타데이터(상호운용성에 매우 도움이 됨)는 JavaScript의 장애물이 되어 작업이 더 지루하고 복잡해집니다.
사이즈와 퍼포먼스
브라우저를 사용하는 경우 JSON은 보다 단순하고 콤팩트하며 특히 네이티브하게 지원되므로 시리얼화/디시리얼라이즈가 더 빠릅니다.사용 가능한 여러 직렬화기 간의 크기와 속도를 비교하는 몇 가지 노스윈드 데이터베이스 벤치마크가 있습니다.베이스 클래스 라이브러리에서 Microsoft의 XML DataContract 시리얼라이저는 JSON보다 30% 이상 빠릅니다.이것은 Microsoft가 XML 시리얼라이저에 쏟은 노력과 더 관련이 있지만, 저는 XML 시리얼라이저보다 2.6배 이상 빠른 JsonSerializer를 개발할 수 있었습니다.벤치마크에 근거한 payload의 경우 XML은 JSON의 약 2배가 넘는 크기인 것으로 보입니다.그러나 XML 페이로드가 동일한 문서 내에서 여러 네임스페이스를 사용하는 경우 이 작업은 빠르게 중단될 수 있습니다.
XML은 대부분의 경우 비대합니다.JSON은 대부분의 장점을 제공합니다.
여기에 언급된 것 외에 한 가지 주요 장점이 있습니다.같은 데이터에 대해 XML 파일로 표시하는 방법은 여러 가지가 있지만 JSON을 사용하는 방법은 한 가지뿐이므로 모호성이 해소됩니다.
저는 아직 전문가는 아니지만, 지금까지 근무해 온 여러 회사의 XML은 소규모 데이터 환경이나 구성 값에서 일반적으로 사용되고 있습니다(web.config가 좋은 예입니다.
일반적으로 대량의 데이터가 있는 경우 해당 데이터에 대해 보고해야 합니다.XML은 보고서 작성에 적합한 소스가 아닙니다.대체적으로 보면 트랜잭션 데이터베이스는 XML보다 보고/검색하기가 더 쉬운 것 같습니다.
이게 말이 되나요?위에서 말씀드린 것처럼 저는 전문가는 아니지만 제 경험상으로는 그런 것 같습니다.또한 개발자들이 UI(Ajax)의 비주얼을 향상시키기 위해 클라이언트 측 또는 스크립트 처리로 이동하는 바람에 Microsoft가 JSON을 통합했으며, Microsoft의 Ajax는 jQuery나 MoTools와 같은 다른 라이브러리(Yahoo의 YUI도 시리얼 오브젝트의 아름다운 통합으로 인해 혼재)만큼 사용되지 않았다고 생각합니다.JSON을 사용합니다.
현재 제 VB 코드에 JSON 시리얼라이저를 실장하고 있는 코드를 쓰고 있습니다.WAY는 너무 쉬워서 업그레이드/수정하는 관점에서는 이 제품을 능가할 수 없습니다.마이크로소프트가 우리를 VS에 중독되게 하는 방법인 것 같아.최근 엔터프라이즈 애플리케이션을 Ajax(jQuery 경유)와 JSON 포맷으로 변환했습니다.그렇게 하는데 약 2주가 걸렸다.Microsoft가 통합해 준 것에 대해 감사를 표합니다.그것이 없었다면, 꽤 많은 코드를 작성할 필요가 있었을 것이기 때문입니다.
언급URL : https://stackoverflow.com/questions/1743532/why-is-everyone-choosing-json-over-xml-for-jquery
'it-source' 카테고리의 다른 글
| AngularJ: ngInclude vs 디렉티브 (0) | 2023.02.08 |
|---|---|
| WooCommerce 카트에 카트 아이템의 제품 ID를 가져옵니다. (0) | 2023.02.08 |
| React에서 중첩된 데이터 렌더링 (0) | 2023.02.08 |
| Wordpress 사이트를 해킹한 후 캐시 제거 (0) | 2023.02.08 |
| 콘텐츠 로드 후 호출할 AngularJs 이벤트 (0) | 2023.02.08 |