誰もがjQueryにXML経由でJSONを選択するのはなぜですか？
XMLは移植性が高く、ミニデータベースとして使用できると思いました。 XMLはどこでも使用されています。大企業も [〜＃〜] json [〜＃〜] に移行しているのを見ています。 MicrosoftでさえJSONのサポートを統合しています。 JSONに対する誇大広告とは何ですか？
基本的にJSONはJavaScriptによってネイティブに認識されるため、次の2つの基本構造のみに依存しているため、非常に軽量でミニマルで移植性に優れています。
- 名前/値のペアのコレクション。さまざまな言語では、これはオブジェクト、レコード、構造体、辞書、ハッシュテーブル、キー付きリスト、または連想配列として実現されます。
- 値の順序付きリスト。ほとんどの言語では、これは配列、ベクトル、リスト、またはシーケンスとして実現されます。
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
_（Pythonの 'simplejson'のようなライブラリを使用して）JSONを介して変換すると、結果のJSON構造はほぼ同一に見えます（JSONを除き、ブール値は小文字です）。
その構造のデコードには、JSONパーサーのみが必要です。Javascript用か、ネイティブiPhoneアプリ用のObjective-Cか、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 Schema/Relax NGなどの苦痛を追加せずに、XMLドキュメントを受け取り、すぐに「オブジェクトとデータ構造になります」と言うことはできませんでした。
簡単に言えば、データを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倍高速になりました（すべてのデータを表示する1200-1300ミリ秒に対して350-400ミリ秒）。また、他の人が指摘しているように、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による簡単な消費が理由の1つになります。
JSONは、サイズと使いやすさの点で、WebサービスからのWebアプリケーションでのデータの消費に最適です。特に、 JavaScript の組み込みサポートによります。 JSONでのインスタントルックアップと比較して、xmlフラグメントを解析するための計算オーバーヘッドを想像してください。
非常に良い例はJSON-Pです。動的に生成された<script>タグ内のmy_callback({"color": "blue", "shape":"square"});のようなコールバック関数呼び出しにラップされたWebサービスからデータを取得して、関数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にはJavaScriptプログラミングとのインピーダンスの不一致はありません。 JSONには、整数、文字列、リスト、配列を含めることができます。 XMLは、消費する前に整数などに解析する必要がある要素とノードにすぎません。
正直なところ、JSONとXMLは、すべてのタイプのデータを表すことができるという点で、それほど大きな違いはありません。ただし、XMLはJSONよりも構文的に大きく、JSONよりも重くなります。
どちらも素晴らしく、非常にポータブルです。ただし、JSONはほとんどの場合、より少ない文字にシリアル化され（配信時間の短縮につながる）、JavaScriptオブジェクトの構文と一致するため、インメモリオブジェクトに直接変換して Ajax 実装がはるかに簡単です。
XMLはまだ素晴らしいです。 JSONは、XMLと比較して「最新かつ最高」です。
JavaScriptで簡単に解析され、軽量です（JSONのドキュメントは、同じデータを含むXMLドキュメントよりも小さくなります）。
JSONは、JavaScriptオブジェクトに直接eval（aJsonString）できるという点で、JavaScriptを効果的にシリアル化しています。ブラウザの内部では、JSONはJavaScriptに最適です。同時に、JavaScriptは非常に緩やかに型付けされた動的言語であり、Xml/Xsdドキュメントに含まれる特定の型情報をすべてネイティブに活用することはできません。この追加のメタデータ（相互運用性に優れています）は、JavaScriptの障害であり、作業が面倒で面倒です。
サイズとパフォーマンス
ブラウザを使用している場合、JSONはよりシンプルでコンパクトであり、重要な点でネイティブにサポートされているため、シリアル化/逆シリアル化が高速になります。 northwindデータベースベンチマークが利用可能 利用可能な異なるシリアライザー間でサイズと速度を比較しています。基本クラスライブラリでは、MicrosoftのXML DataContractシリアライザーは、JSONのものよりも速く30％です。これは、MicrosoftがXMLシリアライザーに費やした労力に関係していますが、私は JsonSerializer が2.6xXMLよりも高速です。ベンチマークに基づいたペイロードに関しては、XMLはJSONのサイズ2xよりもおおよそ大きいように見えます。ただし、XMLペイロードが同じドキュメント内で多くの異なる名前空間を使用している場合、これはすぐに吹き飛ばされる可能性があります。
XMLは、ほとんどの状況で肥大化したヘビ油です。 JSONは、肥大化することなくほとんどの利点を提供します。
ここで述べたもの以外の大きな利点の1つ。同じデータに対して、XMLファイルとして表現する方法は複数ありますが、JSONを使用する方法は1つだけであるため、曖昧さがなくなります:)
私は決して専門家ではありませんが、私が働いてきたさまざまな企業の小さなデータ環境や構成値でXMLを使用しています（web.configは素晴らしい例です）。
大量のデータがある場合、通常、そのデータについてレポートする必要があります。また、XMLはレポートの優れたソースではありません。物事の壮大なスキームでは、トランザクションデータベースはXMLよりもレポート/検索が簡単であるように見えます。
これは理にかなっていますか？上で言ったように、私は専門家ではありませんが、私の経験からこれは事実のようです。また、UIのビジュアルを強化するためにクライアント側のアクションまたはスクリプトアクションに移行する開発者の波（ Ajax ）とMicrosoftのAjaxはそれほど使用されていないため、MicrosoftはJSONサポートを統合したと考えていますjQueryや MooTools （Yahooの [〜＃〜] yui [〜＃〜] などの他のライブラリは、JSONを使用したシリアライズ可能なオブジェクトの美しい統合のためです。
私は自分のVBコードでJSONシリアライザーを実装しているコードを書いていることに気付きます。それは非常に簡単で、アップグレード/変更の観点からは、あなたはそれを打ち負かすことはできません。私は最近、エンタープライズアプリケーションをAjax（jQuery経由）とJSON形式を使用するように変換しました。そうするのに約2週間かかりました。かなりの余分なコード。