2

私の要件は、xmlファイルをバイナリ形式に圧縮し、送信して、解析を開始する前に（非常に高速に）解凍することです。

かなりの数のバイナリ xml プロトコルとツールが利用可能です。EXI (効率的な xml 交換) は他のものよりも優れていることがわかりました。オープン ソース バージョンの Exificient を試してみたところ、優れていることがわかりました。

Google プロトコル バッファと facebook の倹約について聞いたことがあります。

または、EXI よりも良いものがあれば教えてください。

また、DOM、SAX、および Stax と比較して優れた解析パフォーマンスを実現する優れた XML パーサー VTD-XML があります (自分で試したことはありません。Google で調べていくつかの記事を読んだだけです)。

両方の長所、最高の圧縮 + 最高の解析パフォーマンスが必要ですが、何か提案はありますか?

EXI に関してもう 1 つ、デコードされた XML ファイルの解析が高速であるとなぜ EXI が主張できるのでしょうか。DOM、SAX、または Stax によって解析されているためですか? デコードされたバージョンを読み取るための別のバイナリ パーサーがあれば、私はこれが正しいと信じていたでしょう。私が間違っている場合は修正してください。

また、EXI 形式の適切な C++ オープン ソース実装はありますか? Java のバージョンは EXIficient から入手できますが、C++ オープン ソースの実装を見つけることができませんか?

アジャイルデルタによるものもありますが、それは商用です。

4

3 に答える 3

3

あなたはプロトコルバッファ（protobuf）について言及します。これはバイナリ形式ですが、XMLとは直接の関係はありません。特に、メンバー名（要素名/属性名/名前空間）はエンコードされません-それは単なるデータです（識別子の数値マーカーを使用）。

そのため、「フィールド3」などをマップする方法をすでに理解していない限り、protobufストリームから任意のXMLを再構築することはできません。

でも！XMLとprotobufの両方で機能するオブジェクトモデルがある場合、変換は簡単です。どちらかで逆シリアル化-どちらかでシリアル化します。これがどの程度うまく機能するかは、実装によって異なります。たとえば、protobuf-netでは簡単で、実際にはcodegenを実行する方法です（バイナリをロードし、XMLとして書き込み、xsltレイヤーを介してXMLを実行してコードを出力します）。

実際にオブジェクトデータを転送したいだけの場合（そしてXMLは実装の詳細として提案されているだけです）、protobufを徹底的にお勧めします。プラットフォームに依存せず、幅広い実装、バージョントレラント、非常に小さな出力、および読み取りと書き込みの両方での非常に高速な処理。

于 2011-05-04T18:08:48.743 に答える
3

ナディーム、

これらは非常に良い質問です。あなたはそのドメインに不慣れかもしれませんが、同じ質問がXMLのベテランによって頻繁に尋ねられます。それぞれに対処してみます。

グーグルのプロトコルバッファとフェイスブックの倹約について聞いたが、これら2つが私が探している仕事をすることができるかどうか誰かに教えてもらえますか？

Marcが述べたように、Protocol BuffersとThriftはバイナリデータ形式ですが、XMLデータを転送するために設計されたXML形式ではありません。たとえば、名前空間や属性などのXMLの概念はサポートされていないため、XMLとこれらのバイナリ形式の間のマッピングには、かなりの作業が必要になります。

または、EXIよりも優れたものがあれば教えてください。

EXIはおそらくあなたの最善の策です。W3Cは、XML形式の実装のかなり徹底的な分析を完了し、EXI実装（Efficient XML）が一貫して最高のコンパクトさを達成し、最速の1つであることを発見しました。また、GZIP圧縮や、ASN.1 PERのようなパックされたバイナリ形式よりも一貫して優れたコンパクト性を実現していることもわかりました（W3C EXI評価を参照）。他のXML形式はどれもそれを行うことができませんでした。EXIとProtocolBuffersを比較したテストでは、EXIは少なくとも2〜4倍小さかった。

両方の長所、最高の圧縮+最高の解析パフォーマンス、何か提案が欲しいですか？

オプションの場合は、市販の製品を検討することをお勧めします。上記のW3CEXIテストでは、EXIficientよりもはるかに高速なEfficient XMLを使用しました（解析が10倍以上、シリアル化が20倍以上速い場合もあります）。マイレージは異なる場合があるため、オプションである場合は自分でテストする必要があります。

EXIに関するもう1つのことは、デコードされたXMLファイルの解析がEXIで高速であるとどのように主張できるかということです。

EXIがXMLよりも小さく、解析が高速である理由は、EXIが、中間のXML形式でデータを生成することなく、標準のXMLAPIを介してメモリとの間で直接ストリーミングできるためです。したがって、標準APIを介してデータをXMLとしてシリアル化する代わりに、XMLを圧縮し、圧縮されたXMLを送信し、もう一方の端でXMLを解凍してから、XMLAPIの1つを介してデータを解析します...データを直接シリアル化できます標準のXMLAPIを介してEXIとして、EXIを送信してから、反対側のXMLAPIの1つを介してEXIを直接解析します。これは、圧縮とEXIの根本的な違いです。EXIは、それ自体が圧縮ではありません。アプリケーションとの間で直接ストリーミングできる、より効率的なXML形式です。

お役に立てれば！

于 2011-05-14T22:19:14.953 に答える
0

圧縮は EXI 形式の文法体系に統一されています。通常、デコーダー API は、デコーダーに EXI ストリームを処理させると、SAX イベントなどの一連のイベントを提供します。代わりに、デコーダーは複雑な解凍/スキャン プロセスをすべて実行して、SAX などの API イベント シーケンスを生成します。EXI と XML はイベント レベルで互換性があるため、イベント シーケンスを指定して XML テキストを書き出すのはかなり簡単です。

于 2011-05-05T04:26:31.327 に答える