多くの開発者が [〜#〜] xml [〜#〜] および [〜#〜] json [〜#〜] に精通していると確信しています。それらの両方を使用しました。したがって、簡単に説明しても、それらが何であり、その目的は何であるかを説明しても意味がありません。
それらの概念をマッピングしようとすると、次のように言うことができます(間違っている場合は訂正してください)。
{}
[]
に相当しますJSONには存在しない、私が考えられる唯一のことは XML Namespaces です。
問題は、このマッピングを考慮し、JSONがこのマッピングで非常に軽いことを考えると、XMLのない世界(または少なくとも理論的には世界を考える)を見ることができますが、JSONではXMLが行うすべてのことを実行できますか? XMLが使用されているすべての場所でJSONを使用できますか?
PS: this の質問を見たことがあることに注意してください。それは私がここで尋ねているものとはまったく違うものです。したがって、duplicateは言及しないでください。
XMLにそのパワーと多くの複雑さを与えるものは、混合コンテンツです。このようなもの:
<p>A <b>fine</b> mess we're in!</p>
それをJSONで実行したり、従来のプログラミング言語で操作したりしないでください。彼らは仕事のために設計されていません。
この種の質問は通常、XMLのMがマークアップを表すことを忘れている人から寄せられます。これは、プレーンテキストを受け取り、マークアップを追加して構造化テキストを作成する方法です。昔ながらのデータにも非常に便利ですが、それはそれがそのために設計されたものでも、その主な長所があるところでもありません。単純なデータを処理する方法はたくさんありますが、JSONはその1つです。
XMLの主な違いは、XMLは、DTDとすべてを説明するように設計されているということです。
JSONでは、受信するデータについて多くのことを想定する必要があります。
JSONへの文字どおりの変換は、多くの場合、簡潔さと明確さが劣ります。考慮してください:
<foo>
<x:bar x:prop1="g">
<quuz />
</bar>
</foo>
私がこれで見た最も効果的なJSON表現:
{"localName":"foo",
"children": // you need to have a special array to hold all children
[
{"localName": "bar",
"namespace": "x"
// once again, to ensure that there are no collisions,
// attributes should be brought out into their own JSON structure
"attributes":[
{"localName":"prop1",
"namespace":"x",
"value":"g"}
],
"children":[
{"name":"quux"}
]
}
]}
XMLファイル全体について考えてみましょう。 JSONがその場所を持たないと言っているわけではありませんが、XMLが除外されるべきではありません。
JSONとXMLはどちらもデータをフォーマットする方法です。どちらもそれを完全にうまく行うことができるので、JSONはXMLが行うすべてのことを行うことができますか?はい。
しかし.....より適切な質問は、XML/JSONができることではなく、何ができるかwith XML/JSONかもしれません。
XLSTでの変換、XPathでの検索、スキーマでの検証など、JSONでは実現できないと思ういくつかのことwith XMLがあります。すべて非常に便利です。
[〜#〜] xslt [〜#〜] を使用する多くの機能があり、JSONでは使用できない場合があります。したがって、機能的に同等でない場合、相互に置き換えることはできません。
実際には、私たちは両方に長く住む必要があり、JSONのビゴットであることは「有害だと考えられています」。
JSONはかなり新しいものであり、レガシーシステムではサポートされません。レガシーシステムのアップグレードにはコストがかかり、バグが発生します。 JSONが近い将来XMLを置き換えることはありません。
ドメインによって異なります。 Webサービスに関しては?もちろんです。ベンダーがまだ顧客にSOAPをプッシュしていることはまったく恥ずかしいことです。REST + JSONはずっとあります。
さて、Docbookや他の実装のようなスタイル情報を持つ複雑で構造化されたデータについて話しているとしたら、これはXMLの適切なドメインです。
私はcwallenpooleが優れたポイントを作ると思います。ほとんどのXML canはJSONに変換されますが、そうする方が良いかどうかは別のポイントです。
JSONは、少なくともXMLだけでなく、おそらくより優れたデータ構造にも適していますが、XMLはテキストドキュメントをマークアップするときにJSONよりもはるかに自然に読み取られます。この場合、タグは単に階層を区切る方法としてではなく、より大きなテキストフロー内で使用されます。フィールドの。
HTML 5には独自のパーサーがあるかもしれませんが、それでもDocBookのようなアプリケーションが残っています。
YAMLがスーパーセットであり、XMLやJSONよりもはるかに表現力があり、したがって強力なのに、なぜJSONに制限するのですか?.
とは言っても、正しいシリアル化フレームワークを使用すれば、上記のすべての形式を数行の単純なコードでシリアル化および逆シリアル化できるはずです。
これら2つのオブジェクトをJSONでモデル化しようとすると、醜くなります。
<customer><name>John Doe</name></customer>
<employee><name>John Doe</name</employee>
99%の場合に慣れているJSONを使用すると、次のように失われます。
{ name: "John Doe" }
そして今、あなたはいくつかのメタ構造を追加する必要があり、JSONのすべての美しさは、マイナス面を残している間は消えてしまいます。
JSONにそのような機能が存在するかどうかはわかりませんが、.NETでは少なくとも、特定のスキーマに対してXMLを検証できます。それは私の目にはXMLの貴重な利点です。