Loading article…
SGMLとXMLというマークアップ言語では、 「文字データ」を意味する「CDATA」という用語が、それぞれ異なるものの関連性のある目的で使用されます。この用語は、文書のある部分が、非文字データや、より具体的で限定的な構造を持つ文字データではなく、一般的な文字データであることを示します。
XML 文書または外部エンティティでは、CDATA セクションは、マークアップされたコンテンツとしてではなく、テキスト データとして文字通り解釈されるようにマークアップされた要素コンテンツです。[ 1 ]< CDATA セクションは、文字データを表現するための代替構文にすぎません。CDATA セクションの文字データと、たとえば「 」と「 」がそれぞれ「 」と「 」&で表される標準構文の文字データとの間に意味的な違いはありません。<&
CDATAセクションは、以下のシーケンスで始まります。
< ![CDATA[ そして、次のシーケンスの出現で終了します。
]]> これら2つのシーケンスで囲まれたすべての文字は、マークアップやエンティティ参照ではなく、文字として解釈されます。すべての文字は文字通りに解釈されますが、文字のシーケンスだけは例外です]]>。例:
<送信者>ジョン・スミス</送信者>開始タグと終了タグの「sender」はマークアップとして解釈されます。ただし、コードは次のとおりです。
<![CDATA[<sender>ジョン・スミス</sender>]]>は以下と同等です。
<送信者>ジョン・スミス< /送信者>したがって、「タグ」は「ジョン・スミス」と全く同じ地位を持ち、テキストとして扱われます。
同様に、数値文字参照がð要素コンテンツに現れる場合、それは単一のUnicode文字00F0（小文字のeth）として解釈されます。しかし、同じものがCDATAセクションに現れる場合、それはアンパサンド、ハッシュマーク、数字の2、数字の4、数字の0、セミコロンの6文字として解析されます。
XML 文書を初めて作成する人は、CDATA セクションの目的を誤解することがよくあります。処理中にデータが通常の文字データとして扱われないように「保護」することが目的だと誤解しているのです。XML 文書を扱うための API の中には、CDATA セクションに独立してアクセスできるオプションを提供するものもありますが、そのようなオプションは XML 処理システムの通常の要件を超えたものであり、データの暗黙的な意味を変えるものではありません。文字データは、CDATA セクションで表現されているか、通常のマークアップで表現されているかに関わらず、文字データです。CDATA セクションは、XML コードを XML 文書内のテキスト データとして記述する場合に役立ちます。たとえば、 XML アプリケーションの使用方法を説明するXSLで書籍を組版する場合、書籍自体に表示される XML マークアップは、ソース ファイルの CDATA セクションに記述されます。
CDATA セクションに]]>は文字列 " " を含めることはできません。したがって、CDATA セクション内にネストされた CDATA セクションを含めることはできません。3 つの文字列 " ]]>" を含むテキストをエンコードするために CDATA セクションを使用する推奨方法は、3 つの文字列が出現するたびに " " の直前で分割して、複数の CDATA セクションを使用することです>。たとえば、 " ]]>" をエンコードするには、次のように記述します。
<![CDATA[]]]]><![CDATA[>]]>つまり]]>、CDATAセクションの途中に「 」をエンコードするには、「]]>」のすべての出現箇所を次のように置き換えます。
]]]]> <![CDATA[>これは実質的にCDATAセクションを停止し、再開することを意味します。
テキストデータでは、ヘッダーで宣言されたエンコーディングに含まれていないUnicode文字は、数値文字参照<?xml ...?>を使用して表現できます。ただし、CDATAセクション内のテキストは、エンコーディングで使用可能な文字に厳密に制限されます。&#nnn;
このため、プログラムで CDATA セクションを使用して、' &' または ' <' 文字を含む可能性のあるデータを引用すると、データにエンコードで表現できない文字が含まれている場合に問題が発生する可能性があります。エンコーダの実装によっては、これらの文字が失われたり、&#nnn;文字参照の文字に変換されたり、エンコードが失敗したりする可能性があります。ただし、これらの文字は保持されません。
もう一つの問題は、XMLドキュメントが転送中にエンコーディング間で変換される可能性があることです。XMLドキュメントがASCIIなどのより限定された文字セットに変換される場合、表現できなくなった文字は&#nnn;文字参照に変換され、ロスレス変換が行われます。しかし、CDATAセクション内では、これらの文字は全く表現できないため、削除するか、同等の文字に変換する必要があり、CDATAセクションの内容が変更されてしまいます。
XHTMLドキュメント内のCDATAセクションは、WebブラウザがドキュメントをHTMLとしてレンダリングする場合、異なる方法で解析される可能性があります。これは、HTMLパーサーがCDATAの開始マーカーと終了マーカーを認識せず、タグ<内の<script>タグなどのHTMLエンティティ参照も認識しないためです。このため、Webブラウザでレンダリングの問題が発生する可能性があり、信頼できないソースからのデータを表示するために使用すると、2種類のパーサー間でCDATAセクションの終了位置に関する認識が異なるため、クロスサイトスクリプティングの脆弱性につながる可能性があります。<script>
ウェブページのスクリプトやスタイルシートで、小なり記号（< <）やアンパサンド（& &）をエスケープ処理を気にせずに使用できると便利なため、XHTML ドキュメントではインライン要素や要素のテキストを CDATA マーカーで囲むのが一般的です。しかし、CDATA マーカーを認識しない HTML パーサーでもドキュメントを解析できるように、通常は CDATA マーカーをコメントアウトします。JavaScriptの例を以下に示します。<script><style>
< script type = "text/javascript" > // <![CDATA[ document.write ( " < " ); //]] > </script>または、このCSSの例：
< style type = "text/css" > /*<![CDATA[*/ body { background-image : url ( "marble.png ? width=300&height=300" ) } /*]]>* / </style>この手法は、インラインスクリプトやスタイルシートを使用する場合にのみ必要であり、言語固有のものです。たとえば、CSS スタイルシートは、2 番目のコメントアウト形式 ( ) のみをサポートしていますが、CSS は JavaScript よりもや文字/* … */の必要性が少ないため、明示的な CDATA マーカーの必要性も少なくなります。<&
SGMLおよびXMLの文書型定義（DTD）ファイルでは、属性値をCDATA型（任意の文字データ）として指定できます。CDATA型の属性内では、文字およびエンティティ参照マークアップが許可され、文書の読み取り時に処理されます。
例えば、XML DTDに以下が含まれている場合：
<!ATTLIST foo a CDATA #IMPLIED >これは、foo という名前の要素には、オプションで CDATA 型の属性 を持つことができることを意味しますa。この DTD に従って有効な XML 文書では、次のような要素が現れることがあります。
<foo a= "1 & 2 は < 3 " />XMLパーサーは、a属性の値を文字データとして解釈します1 & 2 are < 3。
SGMLまたはXML DTDには、エンティティが文字データで構成されていることを示すトークンCDATAを使用したエンティティ宣言が含まれる場合があります。文字データは宣言自体の中に記述することも、URIで参照される外部データとして使用することもできます。いずれの場合も、エンティティ内では文字参照およびパラメータエンティティ参照のマークアップが許可され、読み取り時にそのように処理されます。
<DISPLAY_NAME Attribute= "Y" > <![CDATA[PFTEST0__COUNTER_6__:4:199:, PFTEST0__COUNTER_7__:4:199:]]> </DISPLAY_NAME><SVLOBJECT><LONG name= "" val= "" INTEGER name= "" val= "" LONG name= "" val= "" /></SVLOBJECT>