C'è un modo per sfuggire a un token di fine CDATA in XML?

Mi chiedevo se c'è un modo per sfuggire a un token di fine CDATA ( ]]>) all'interno di una sezione CDATA in un documento XML. O, più in generale, se esiste una sequenza di escape da utilizzare all'interno di un CDATA (ma se esiste, immagino che probabilmente avrebbe senso sfuggire ai token di inizio o fine, comunque).

Fondamentalmente, puoi avere un token di inizio o fine incorporato in un CDATA e dire al parser di non interpretarlo ma di trattarlo come un'altra sequenza di caratteri.

Probabilmente, dovresti semplicemente riformattare la tua struttura xml o il tuo codice se ti ritrovi a provare a farlo, ma anche se ho lavorato con xml quotidianamente negli ultimi 3 anni circa e non ho mai avuto questo problema, Mi chiedevo se fosse possibile. Solo per curiosità.

Modificare:

Oltre all'utilizzo della codifica html ...

Chiaramente, questa domanda è puramente accademica. Fortunatamente, ha una risposta molto precisa.

Non è possibile evitare una sequenza finale CDATA. La regola di produzione 20 della specifica XML è abbastanza chiara:

[20]    CData      ::=      (Char* - (Char* ']]>' Char*))

EDIT: Questa regola del prodotto significa letteralmente "Una sezione CData può contenere tutto ciò che vuoi MA la sequenza ']]>'. Nessuna eccezione.".

EDIT2: la stessa sezione recita anche:

All'interno di una sezione CDATA, solo la stringa CDEnd viene riconosciuta come markup, in modo che le parentesi angolari sinistre e le e commerciali possano verificarsi nella loro forma letterale; non devono (e non possono) essere evitati usando " <" e " &". Le sezioni CDATA non possono essere nidificate.

In altre parole, non è possibile utilizzare riferimenti a entità, markup o qualsiasi altra forma di sintassi interpretata. L'unico testo analizzato all'interno di una sezione CDATA è]]> e termina la sezione.

Quindi, non è possibile fuggire ]]> all'interno di una sezione CDATA.

EDIT3: la stessa sezione recita anche:

2.7 Sezioni CDATA

[Definizione: le sezioni CDATA possono verificarsi ovunque si verifichino dati sui caratteri; sono usati per sfuggire a blocchi di testo contenenti caratteri che altrimenti verrebbero riconosciuti come markup. Le sezioni CDATA iniziano con la stringa "<! [CDATA [" e terminano con la stringa "]]>":]

Quindi potrebbe esserci una sezione CDATA ovunque possano verificarsi dati sui caratteri, incluse più sezioni CDATA adiacenti al posto di una singola sezione CDATA. Ciò consente di dividere il ]]>token e metterne le due parti in sezioni CDATA adiacenti.

ex:

<![CDATA[Certain tokens like ]]> can be difficult and <invalid>]]> 

dovrebbe essere scritto come

<![CDATA[Certain tokens like ]]]]><![CDATA[> can be difficult and <valid>]]> 

Devi dividere i tuoi dati in pezzi per nascondere il ]]>.

Ecco tutto:

<![CDATA[]]]]><![CDATA[>]]>

Il primo <![CDATA[]]]]>ha il ]]. Il secondo <![CDATA[>]]>ha il >.

Non sfuggite al ]]>ma sfuggite al >dopo ]]inserendo ]]><![CDATA[prima del >, pensate a questo proprio come in una \stringa C / Java / PHP / Perl ma serve solo prima di un >e dopo un ]].

BTW,

La risposta di S.Lott è la stessa di questa, formulata diversamente.

La risposta di S. Lott è giusta: non codifichi il tag di fine, lo spezzi in più sezioni CDATA.

Come affrontare questo problema nel mondo reale: usando un editor XML per creare un documento XML che verrà inserito in un sistema di gestione dei contenuti, prova a scrivere un articolo sulle sezioni CDATA. Il tuo trucco ordinario di incorporare esempi di codice in una sezione CDATA non riuscirà qui. Puoi immaginare come ho imparato questo.

Ma nella maggior parte dei casi, non ti imbatterai in questo, ed ecco perché: se vuoi archiviare (diciamo) il testo di un documento XML come contenuto di un elemento XML, probabilmente utilizzerai un metodo DOM, ad esempio:

XmlElement elm = doc.CreateElement("foo");
elm.InnerText = "<[CDATA[[Is this a problem?]]>";

E il DOM sfugge abbastanza ragionevolmente al <e al>, il che significa che non hai inavvertitamente incorporato una sezione CDATA nel tuo documento.

Oh, e questo è interessante:

XmlDocument doc = new XmlDocument();

XmlElement elm = doc.CreateElement("doc");
doc.AppendChild(elm);

string data = "<![[CDATA[This is an embedded CDATA section]]>";
XmlCDataSection cdata = doc.CreateCDataSection(data);
elm.AppendChild(cdata);

Questa è probabilmente un'ideosincrasia del DOM .NET, ma ciò non fa eccezione. L'eccezione viene generata qui:

Console.Write(doc.OuterXml);

Immagino che ciò che sta accadendo sotto il cofano sia che XmlDocument sta usando un XmlWriter per produrre il suo output, e XmlWriter controlla la sua buona formazione mentre scrive.

semplicemente sostituirlo ]]>con]]]]><![CDATA[>

Ecco un altro caso in cui ]]>deve essere evitato. Supponiamo di dover salvare un documento HTML perfettamente valido all'interno di un blocco CDATA di un documento XML e che l'origine HTML abbia il proprio blocco CDATA. Per esempio:

<htmlSource><![CDATA[ 
    ... html ...
    <script type="text/javascript">
        /* <![CDATA[ */
        -- some working javascript --
        /* ]]> */
    </script>
    ... html ...
]]></htmlSource>

il suffisso CDATA commentato deve essere modificato in:

        /* ]]]]><![CDATA[> *//

poiché un parser XML non saprà come gestire i blocchi di commenti javascript

In PHP: '<![CDATA['.implode(explode(']]>', $string), ']]]]><![CDATA[>').']]>'

Un modo più pulito in PHP:

   function safeCData($string)
   {
      return '<![CDATA[' . str_replace(']]>', ']]]]><![CDATA[>', $string) . ']]>';
   }

Non dimenticare di utilizzare uno str_replace sicuro multibyte, se necessario (non latino1 $string):

   function mb_str_replace($search, $replace, $subject, &$count = 0)
   {
      if (!is_array($subject))
      {
         $searches = is_array($search) ? array_values($search) : array ($search);
         $replacements = is_array($replace) ? array_values($replace) : array ($replace);
         $replacements = array_pad($replacements, count($searches), '');
         foreach ($searches as $key => $search)
         {
            $parts = mb_split(preg_quote($search), $subject);
            $count += count($parts) - 1;
            $subject = implode($replacements[$key], $parts);
         }
      }
      else
      {
         foreach ($subject as $key => $value)
         {
            $subject[$key] = mb_str_replace($search, $replace, $value, $count);
         }
      }
      return $subject;
   }

Non penso che interrompere CDATA sia una buona strada da percorrere. Ecco la mia alternativa ...

Usa ]per la sequenza di escape seguita dal valore esadecimale del tuo personaggio. Come in &#xhhhh;=>]<unicode value>;

In questo modo se provi a registrare la ]]>tua codifica fn produrrà il ]005D;]005D;]003E;che è ok in CDATA.

È meglio che scappare per nome dell'entità, perché quelli non vengono decodificati ogni volta nella tua app e potresti avere priorità diverse per sfuggire alle entità con e commerciale rispetto a scappare alcuni altri caratteri / sequenze. Di conseguenza hai un maggiore controllo sul contenuto di CDATA.

Vedi questa struttura:

<![CDATA[
   <![CDATA[
      <div>Hello World</div>
   ]]]]><![CDATA[>
]]>

Per i tag CDATA interni è necessario chiudere ]]]]><![CDATA[>invece di ]]>. Semplice come quella.