4 つの XML パーサーの原理とパフォーマンス比較の詳細な説明

1: DOM

DOM は、プラットフォームや言語に依存しない方法で XML ドキュメントを表現するための公式の W3C 標準です。 DOM は、階層構造で編成されたノードまたは情報の集合です。この階層により、開発者はツリーで特定の情報を検索できます。この構造を分析するには、通常、作業を行う前にドキュメント全体をロードし、階層を構築する必要があります。 DOM は情報階層に基づいているため、ツリーベースまたはオブジェクトベースとみなされます。 DOM、および一般にツリーベースの処理には、いくつかの利点があります。
まず、ツリーはメモリ内に永続的であるため、アプリケーションがデータと構造を変更できるように変更できます。また、SAX のような 1 回限りのプロセスではなく、いつでもツリーを上下に移動できます。 DOM の使用も非常に簡単です。
一方、特に大きなドキュメントの場合、ドキュメント全体の解析と読み込みは時間がかかり、リソースを大量に消費する可能性があるため、そのようなデータを処理するには他の手段を使用することをお勧めします。これらは SAX のようなイベントベースのモデルです。

2:SAX

この処理の利点は、ストリーミング メディアの利点と非常に似ています。すべてのデータが処理されるのを待つことなく、すぐに分析を開始できます。また、アプリケーションはデータの読み取り時にデータをチェックするだけなので、データをメモリに保存する必要はありません。これは、大きなドキュメントにとって大きな利点です。実際、アプリケーションはドキュメント全体を解析する必要さえなく、特定の条件が満たされた場合に解析を停止できます。一般に、SAX は、それに代わる DOM よりもはるかに高速です。
3: DOM か SAX を選択しますか?
XML ドキュメントを処理するために独自のコードを記述する必要がある開発者にとって、DOM または SAX 解析モデルの選択は非常に重要な設計上の決定です。
DOMはツリー構造を使用してXML文書にアクセスしますが、SAXはイベントモデルを使用します。
DOM パーサーは、XML ドキュメントをそのコンテンツを含むツリーに変換し、ツリーをトラバースできます。 DOM を使用してモデルを解析する利点は、開発者がツリー構築命令を呼び出して、ナビゲーション API を使用して必要なツリー ノードにアクセスするだけで、タスクを完了するだけでプログラミングが簡単になることです。ツリー内の要素は簡単に追加および変更できます。ただし、DOM パーサーを使用する場合は XML ドキュメント全体を処理する必要があるため、特に大きな XML ファイルを処理する場合には、パフォーマンスとメモリの要件が比較的高くなります。 DOM パーサーは、そのトラバーサル機能により、XML ドキュメントを頻繁に変更する必要があるサービスでよく使用されます。
SAX パーサーはイベントベースのモデルを採用しており、XML ドキュメントを解析するときに一連のイベントをトリガーして、指定されたタグが見つかったことをメソッドに伝えることができます。 SAX では、開発者がどのタグを処理するかを決定できるため、一般にメモリ要件が低くなります。特に開発者がドキュメントに含まれるデータの一部のみを処理する必要がある場合、SAX のスケーラビリティがよりよく反映されます。ただし、SAX パーサーを使用する場合はコーディングがより難しくなり、同じドキュメント内の複数の異なるデータに同時にアクセスすることが困難になります。

4: JDOM

JDOM は、XML との対話を簡素化し、DOM 実装を使用するよりも高速な Java 固有のドキュメント モデルであることを目的としています。 JDOM は、最初の Java 固有のモデルになって以来、盛んに推進されてきました。最終的には、「Java 仕様要求 JSR-102」を通じて「Java 標準拡張」として使用することが検討されています。 JDOM の開発は 2000 年代初頭から行われてきました。
JDOMとDOMには主に2つの違いがあります。まず、JDOM は具象クラスのみを使用し、インターフェイスは使用しません。これにより、API がいくつかの点で簡素化されますが、柔軟性も制限されます。第 2 に、API は Collection クラスを多用しており、これらのクラスにすでに慣れている Java 開発者にとっては使用が簡素化されています。
JDOMのドキュメントには、その目的は「Java/XMLの問題の80％（以上）を20％（以下）の労力で解決する」ことであると記載されています（学習曲線に基づいて20％と仮定）。 JDOM は確かにほとんどの Java/XML アプリケーションにとって便利であり、ほとんどの開発者は API の方が DOM よりもはるかに理解しやすいと感じています。 JDOM には、ユーザーが XML で意味をなさないことを行うことを防ぐために、プログラムの動作に関するかなり広範なチェックも含まれています。ただし、基本以上のことを行うには (場合によってはエラーを理解することも)、XML を十分に理解している必要があります。これは、DOM や JDOM インターフェイスを学ぶよりも有意義な作業かもしれません。
JDOM自体にはパーサーは含まれていません。通常、SAX2 パーサーを使用して入力 XML ドキュメントを解析および検証します (ただし、以前に構築された DOM 表現を入力として受け取ることもできます)。これには、JDOM 表現を SAX2 イベント ストリーム、DOM モデル、または XML テキスト ドキュメントに出力するコンバータが含まれています。 JDOM は、Apache ライセンスのバリアントに基づいてリリースされたオープン ソースです。

5: DOM4J

DOM4Jは完全に独立した開発成果を表していますが、元々はJDOMのインテリジェントフォークでした。これには、統合された XPath サポート、XML スキーマ サポート、大規模ドキュメントまたはストリーミング ドキュメントのイベントベースの処理など、基本的な XML ドキュメント表現を超える多くの機能が組み込まれています。また、DOM4J API および標準 DOM インターフェイスを介した並列アクセス機能を備えたドキュメント表現を構築するためのオプションも提供します。 2000 年後半から開発が進められてきました。
これらすべての機能をサポートするために、DOM4J はインターフェイスと抽象基本クラス メソッドを使用します。 DOM4J は API で Collections クラスを多用しますが、多くの場合、パフォーマンスの向上やより単純なコーディング アプローチを可能にする代替手段も提供します。直接的な利点は、DOM4J はより複雑な API の代償を払っていますが、JDOM よりもはるかに優れた柔軟性を提供することです。
柔軟性、XPath 統合、大規模ドキュメントの処理を追加しながら、DOM4J の目標は JDOM と同じであり、Java 開発者にとっての使いやすさと直感的な操作です。また、JDOM よりも完全なソリューションとなることも目指しており、本質的にすべての Java/XML 問題を処理するという目標を達成します。 JDOM ほどアプリケーションの不正動作の防止に重点を置かずに、この目標を達成します。
DOM4J は、優れたパフォーマンス、強力な機能、そして非常に使いやすい非常に優れた Java XML API であり、オープンソース ソフトウェアでもあります。最近では、XML の読み書きに DOM4J を使用する Java ソフトウェアが増えています。特に、Sun の JAXM も DOM4J を使用していることは注目に値します。
6: 概要
パフォーマンステスト中にJDOMとDOMのパフォーマンスが悪く、10Mドキュメントをテストするとメモリオーバーフローが発生しました。小さなドキュメントの場合は、DOM と JDOM の使用を検討する価値があります。 JDOM の開発者は、正式リリース前にパフォーマンスの問題に重点を置く予定であると述べていますが、実際にはパフォーマンスの観点から JDOM を推奨するものは何もありません。さらに、DOM は依然として非常に優れた選択肢です。 DOM 実装は、多くの プログラミング言語 で広く使用されています。これは、他の多くの XML 関連標準の基礎でもあり、(非標準ベースの Java モデルとは対照的に) W3C によって公式に推奨されているため、特定の種類のプロジェクト (たとえば、 javascript の DOM )。
SAX のパフォーマンスが向上するかどうかは、その特定の解析方法に依存します。 SAX は受信 XML ストリームを検出しますが、それをメモリにロードしません (もちろん、XML ストリームが読み取られるとき、一部のドキュメントはメモリ内に一時的に隠蔽されます)。
現在、DOM4J は多くのオープンソース プロジェクトで広く使用されており、たとえば、有名な Hibernate も XML 設定ファイルを読み取るために DOM4J を使用しています。移植性を気にしない場合は、DOM4J を使用してください。

以上が4 つの XML パーサーの原理とパフォーマンス比較の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。