모두가 jQuery를 위해 JSON보다 XML을 선택하는 이유는 무엇입니까? [닫은]

XML이 이식성이 뛰어나고 미니 데이터베이스로 사용될 수 있다고 생각했습니다. 나는 모든 곳에서 XML이 사용되는 것을 보았다. 심지어 대기업이 JSON으로 전환하는 것을 보았습니다 . Microsoft조차도 JSON에 대한 지원을 통합했습니다. JSON에 대한 과대 광고는 무엇입니까?

기본적으로 JSON은 JavaScript에 의해 기본적으로 인식되므로 두 가지 기본 구조에만 의존하기 때문에 실제로 가볍고, 최소이며, 이식성이 뛰어납니다.

• 이름 / 값 쌍의 모음입니다. 다양한 언어에서 이것은 객체, 레코드, 구조체, 사전, 해시 테이블, 키 목록 또는 연관 배열로 실현됩니다.
• 정렬 된 값 목록. 대부분의 언어에서 이는 배열, 벡터, 목록 또는 시퀀스로 실현됩니다.

다른 네임 스페이스 스키마를 혼합하기 시작할 때까지 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

JSON을 통해 번역 할 때 (Python의 경우 'simplejson'과 같은 라이브러리 사용) 결과 JSON 구조는 거의 동일하게 보입니다 (JSON을 제외하면 부울은 소문자 임).

이 구조를 디코딩하려면 기본 iPhone 앱 또는 C # 또는 Python 클라이언트의 경우 Javascript 또는 Objective-C에 관계없이 JSON 파서 만 필요합니다. float는 float, string은 string, boolean은 boolean으로 해석됩니다. 파이썬에서 '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보다 단순하지만 해당 데이터에 대해 생각하기에는 너무 많은 방법을 제공합니다. 그런 다음 그것을 생성해야합니다. 파이썬 사전 (또는 다른 간단한 데이터 구조)을 가져다가 "내 자신을 내 XML로 만들어라"고 말할 수는 없습니다. 나는 XML 문서를받을 수 없었고, 커스텀 파서를 작성하지 않거나 XML Schema / Relax NG의 추가 오버 헤드와 다른 고통없이 즉시 "객체와 데이터 구조로 들어 가라"고 말할 수 없었다.

단점은 특히 빠른 상호 교환을 위해 JSON으로 데이터를 인코딩하고 디코딩하는 것이 훨씬 쉽고 직접적이라는 것입니다. JavaScript / JSON에 내장 된 기본 데이터 유형 (목록, 사전 등)이 Python, Perl, Ruby 등에서 동일하거나 유사한 데이터 유형에 직접 매핑되므로 동적 언어 배경에서 온 사람들에게 더 적용될 수 있습니다.

JSON의 성능은 대부분의 사용 사례에서 XML과 크게 다르지 않으며 JSON은 깊게 중첩 된 구조에 적합하지 않으며 읽을 수 없습니다 ...]]]}]]

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 에서 기본 제공되는 지원으로 인해 웹 서비스에서 웹 응용 프로그램의 데이터를 사용하기에 적합 합니다 . JSON의 인스턴트 조회와 비교하여 xml 조각을 구문 분석하기위한 계산 오버 헤드를 상상해보십시오.

아주 좋은 예는 JSON-P입니다. my_callback({"color": "blue", "shape":"square"});동적으로 생성 된 <script>태그 내부 와 같이 콜백 함수 호출로 래핑 된 웹 서비스에서 데이터를 가져 와서 함수 에서 데이터를 직접 사용할 수 있습니다.my_callback() . XML을 사용하여 이러한 편의에 더 가까이 다가 갈 방법은 없습니다.

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 객체로 직접 eval (aJsonString) 할 수 있다는 점에서 JavaScript를 효과적으로 직렬화합니다. 브라우저 내에서 JSON은 JavaScript에 완벽하게 적합합니다. 동시에 JavaScript는 매우 느슨하게 형식화 된 동적 언어이며 Xml / Xsd 문서에 포함 된 사용 가능한 모든 특정 형식 정보를 기본적으로 활용할 수는 없습니다. 이 추가 메타 데이터 (상호 운용성에 도움이 됨)는 JavaScript에서 방해가되어 작업하기가 더 번거롭고 번거 롭습니다.

크기 대 성능

브라우저를 사용하는 경우 JSON이 더 단순하고 간결하며 기본적으로 기본적으로 지원되므로 직렬화 / 직렬화가 더 빠릅니다. 사용 가능한 다른 시리얼 라이저 사이의 크기와 속도를 비교할 수 있는 노스 윈드 데이터베이스 벤치 마크가 있습니다. 기본 클래스 라이브러리에서 Microsoft의 XML DataContract 직렬 변환기는 JSON보다 30 % 이상 빠릅니다. 이것은 XML 보다 2.6 배 빠른 JsonSerializer 를 개발할 수 있었기 때문에 Microsoft가 XML 시리얼 라이저에 투입 한 노력과 더 관련이 있습니다 . 벤치 마크를 기반으로 한 페이로드는 XML이 약 2 배 이상인 것처럼 보입니다.JSON의 크기 그러나 XML 페이로드가 동일한 문서 내에서 많은 다른 네임 스페이스를 사용하는 경우 빠르게 작동 할 수 있습니다.

XML은 대부분의 상황에서 부풀어 오른 뱀 기름입니다. JSON은 부 풀리지 않고 대부분의 이점을 제공합니다.

여기에 언급 된 것 이외의 하나의 주요 장점. 동일한 데이터의 경우 XML 파일로 표현하는 여러 가지 방법이 있지만 JSON을 사용하는 한 가지 방법만으로 모호성을 제거합니다. :)

나는 지금까지 전문가가 아니지만 내가 일한 여러 회사에서 일반적으로 소규모 데이터 환경 또는 구성 값에서 XML을 사용합니다 (web.config가 좋은 예입니다).

많은 양의 데이터가있는 경우 일반적으로 해당 데이터에 대해보고하려고합니다. 그리고 XML은보고를위한 훌륭한 소스가 아닙니다. 대단한 계획에서는 트랜잭션 데이터베이스가 XML보다보고 / 검색이 더 쉬운 것처럼 보입니다.

이게 말이 돼? 위에서 말했듯이 나는 전문가가 아니지만 내 경험으로는 이것이 사실 인 것 같습니다. 또한 UI ( Ajax ) 의 시각을 향상시키기 위해 클라이언트 측 또는 스크립트 작업으로 이동하는 개발자의 물결로 인해 Microsoft 통합 JSON 지원이 있다고 생각 하며 Microsoft의 Ajax는 jQuery 및 MooTools 와 같은 다른 라이브러리만큼 사용되지 않았습니다 ( 야후의 YUI 는 JSON을 사용하여 직렬화 가능한 객체를 아름답게 통합했기 때문에 혼합되어 있습니다.

VB 코드에서 JSON 직렬 변환기를 구현하는 코드를 작성하고 있습니다. 너무 쉬운 방법이며 업그레이드 / 수정 관점에서 이길 수 없습니다. 우리가 VS에 중독되게하는 것은 Microsoft의 방법입니다. 최근에 엔터프라이즈 애플리케이션을 Ajax (jQuery를 통해)를 사용하고 JSON 형식을 사용하도록 변환했습니다. 그렇게하는 데 약 2 주가 걸렸습니다. 실제로 마이크로 소프트가 통합하지 않은 것에 대해 감사한다. 왜냐하면 그것 없이는 약간의 추가 코드를 작성해야했기 때문이다.