4

この質問は、開発者の Michael Rys が、CDATA セクションの解析を FOR XML PATH に含めることをかなり好戦的に拒否したことによって引き起こされました。

HTML のナゲットを CDATA ノードに保存したり、特殊文字や扱いにくい文字を使用する必要があるその他のコンテンツを保存したりしました。しかし、Rys の論争の的となっている主張に異議を唱える資格はないと思います。なぜなら、私が便宜上 CDATA を使用したシナリオでは技術的には Rys が正しいと思うからです。

開発者がインターネットで FOR XML PATH を使用して CDATA セグメントをレンダリングする方法についてアドバイスを求めているとき、回答者は常に FOR XML EXPLICIT を使用するように指示しています。Rysが「クエリ地獄の"。

誰もが提案できるすべてのユースケースで本当にCDATAなしでできるのであれば、今後はうめき声をやめてCDATAの使用を拒否すべきだと思います。しかし、CDATA が必須である明確に定義されたケースがある場合、Rys は、この質問の一番上のリンクで、それを FOR XML PATH に組み込むことをすでに約束しています。

それで、それはどれですか？CDATA セクションは本当に過去の遺物ですか? それとも、Rys は指を抜いて、FOR XML PATH で CDATA を解析できるようにする必要がありますか? それまでの間、FOR XML PATH を取得して CDATA セクションを返すためのハックはありますか?

4

4 に答える 4

3

CDATA セクションは不要です。それらは常に不必要だったので、「過去の遺物」ではありません。

これは、それらが役に立たないという意味ではありません。ほぼすべてのプログラミング言語やライブラリを見てみると、他のものと意味的に同等であるため、なくてもできることがたくさんありますが、人間がそこに座って何かを書かなければならない場合に役立ちます。

さらに言えば、プログラムによる生成であっても、反対のアプローチを取り、c-data のすべての部分に CDATA セクションを使用できるのも便利です (肥大化しますが、他の場所で効率が向上する可能性があります)。

FOR XML PATH には、人間がそこに座って何かを書く必要はありません。これは、SQL クエリの結果から有効な XML を生成する手段です。(これは、CDATA セクションを解析することではなく、それらを生成することでもあります - 別の問題です)。

そして、本当に細かい制御が必要な場合に、FOR XML EXPLICIT が代替手段であることに文句を言うことはできません。実際、彼らが最初に CDATA セクションのサポートを追加し、次に他のすべての微調整と構成オプションのサポートを追加したかどうかを検討してください。FOR XML EXPLICIT は FOR XML PATH よりも単純であるため、自動的に選択されるまでにどれくらいの時間がかかりますか?</p>

CDATA が役立つ 4 つのケースがあります。

  1. あなたはキーボードの前に座って、このようなことを自分でタイプしています。
  2. さまざまな技術を、さまざまな時期に設計され、さまざまなパーサーによってさまざまな方法で解釈されるさまざまな技術の混合に取り組んでいます (たとえば、XHTML に埋め込まれた JavaScript - ここでは 100% 必要というわけではありませんが、それ以外の場合は悪夢です)。
  3. XML を理解できないもので XML を解析しようとしています。
  4. CDATA セクションと他の文字データを区別する低レベル アクセスを許可するパーサー上に構築されたものを使用しようとしており、その低レベル アクセスを不適切に使用しています。

面白いことに、これらの 4 つのケースは、CDATA セクションの受け入れを禁止することが理にかなっている 4 つのケースでもあります。

ケース 1 はここでは当てはまりません。人間が生成したコードではありません。ケース 2 は、本当にクレイジーなことをしている場合に適用できます。率直に言って、CDATA セクションがないことは、ここで最も心配することではありません。クエリでより単純な XML を生成し、他の場所で変換するように切り替えます。ここではケース 3 が適用される可能性がありますが、そうである場合、SQL の人々に不平を言うのは公平ではありませ&lt;example&gt;ん<![CDATA[<example>]]>。ここではケース 4 が適用されますが、これもまた、SQL 担当者ではなく、バグのあるコードを書いた人に文句を言うことです。

于 2010-12-01T12:30:01.963 に答える
2

CDATAセクションは、セクション内のデータのセマンティクスを気にせず (つまり、解析する必要がない - 単なる文字の連続である)、セクション内の XML をエスケープしたくない場合に便利です。 .

w3による定義:

CDATA セクションは、文字データが発生する場所であればどこでも発生する可能性があります。それらは、そうでなければマークアップとして認識される文字を含むテキストのブロックをエスケープするために使用されます。

ウィキペディアから：

XML ドキュメントの新しい作成者は、CDATA セクションの目的を誤解していることが多く、その目的は処理中にデータが通常の文字データとして扱われないように「保護」することであると誤って信じています。XML ドキュメントを操作するための一部の API は、CDATA セクションへの独立したアクセスのオプションを提供しますが、そのようなオプションは XML 処理システムの通常の要件を超えて存在し、データの暗黙の意味を変更しません。文字データは、CDATA セクションまたは通常のマークアップを介して表現されているかどうかに関係なく、文字データです。

CDATA セクションは、XML ドキュメント内のテキスト データとして XML コードを記述する場合に役立ちます。たとえば、XML アプリケーションの使用法を XSL で説明する書籍をタイプセットしたい場合、書籍自体に表示される XML マークアップは、ソース ファイルの CDATA セクションに記述されます。ただし、CDATA セクションに文字列 "]]>" を含めることはできないため、ネストされた CDATA セクションを CDATA セクションに含めることはできません。トライアド "]]>" を含むテキストをエンコードするために CDATA セクションを使用するための推奨される方法は、">" の直前でトライアドの出現ごとに分割することにより、複数の CDATA セクションを使用することです。たとえば、"]]>" をエンコードするには、次のように記述します。

于 2010-12-01T11:44:46.070 に答える
1

誰かがそのような気まぐれなアプローチでスタンダードの非常に貴重な部分をどのように投げることができるかを見るのは興味深い. 数百文字の HTML やドロップダウンの項目リストに XML を使用している人が全員いるわけではありません。

CCD や CDA CDR のような非常に複雑なデータを交換するために実際に XML を使用している人もいます。これらはすべて医療分野の標準的なドキュメント形式であり、ObamaCare でますます注目を集めています。これらのドキュメント構造の一部には、CDATA 定義が存在するという理由でパーサーが読み取ってはならない DiCOM 画像、PDF、およびその他のバイナリ データなどの添付ファイルが含まれています。

CCD ドキュメントに埋め込まれた 3 メガバイトの DiCom 画像を読み取るパーサーのオーバーヘッドを支払う必要があるのはなぜですか? ドキュメントが元のデータに含まれていて、XML 標準の一部であるのに、ドキュメントを分離しなければならないのはなぜですか。そして、XML を含むコンテンツであるドキュメントを見つけて回復できるようにしたいと考えています。

これは、エンジンによって解析されないことを意図したデータの解析を皆さんがサポートする理由を当惑させます。CDATA がそれを無視することをエンジンが認識した場合、それは非常に単純です。そして、それを必要としない人もいるという継続的な議論は無関係です. これは標準の一部であり、標準を維持する必要があります。呼び出された「機能」を追加したい場合は、オプションでデフォルトの動作をサポートします。

CDATA の解析を停止し、無視してください。

于 2013-02-22T22:50:48.597 に答える
0

あなたは絶対に正しいです、CDATAは多くのシナリオで不可欠です、それらはXML標準の一部であり、すべてのXML操作ツール/メソッドによってサポートされるべきです。しかし、MSは通常気にしないということです..ご存知のように、「640kBはすべての人にとって十分なはずです」という種類のアプローチです。

編集：FOR XML EXPLICITについて-これは、正確にフォーマットされたXMLデータを生成するための最良の方法です。はい、構文は見るのが少し面倒で混乱しますが、数回使用すると、その美しさとパワーに感心するでしょう。

于 2010-12-01T12:11:49.203 に答える