¿Hay alguna manera de escapar de un token final CDATA en xml?

Me preguntaba si hay alguna forma de escapar de un token final CDATA ( ]]>) dentro de una sección CDATA en un documento xml. O, más generalmente, si hay alguna secuencia de escape para usar dentro de un CDATA (pero si existe, supongo que probablemente tendría sentido escapar de los tokens de inicio o fin, de todos modos).

Básicamente, ¿puede tener un token de inicio o fin incrustado en un CDATA y decirle al analizador que no lo interprete sino que lo trate como una secuencia de caracteres más?

Probablemente, debería refactorizar su estructura xml o su código si intenta hacerlo, pero a pesar de que he estado trabajando con xml a diario durante los últimos 3 años más o menos y nunca he tenido este problema, Me preguntaba si era posible. Solo por curiosidad.

Editar:

Aparte de usar la codificación html ...

Claramente, esta pregunta es puramente académica. Afortunadamente, tiene una respuesta muy definitiva.

No puede escapar de una secuencia final de CDATA. La regla de producción 20 de la especificación XML es bastante clara:

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

EDITAR: Esta regla del producto significa literalmente "Una sección de CData puede contener lo que desee PERO la secuencia ']]>'. Sin excepción".

EDIT2: La misma sección también lee:

Dentro de una sección CDATA, solo la cadena CDEnd se reconoce como marcado, de modo que los corchetes angulares izquierdos y los signos de unión pueden aparecer en su forma literal; no necesitan (y no pueden) escapar usando " <" y " &". Las secciones CDATA no pueden anidar.

En otras palabras, no es posible utilizar referencias de entidades, marcas o cualquier otra forma de sintaxis interpretada. El único texto analizado dentro de una sección CDATA es ]]>, y termina la sección.

Por lo tanto, no es posible escapar ]]>dentro de una sección CDATA.

EDITAR3: La misma sección también lee:

2.7 Secciones CDATA

[Definición: las secciones CDATA pueden aparecer en cualquier lugar donde puedan aparecer datos de caracteres; se usan para escapar de bloques de texto que contienen caracteres que de otro modo se reconocerían como marcado. Las secciones CDATA comienzan con la cadena "<! [CDATA [" y terminan con la cadena "]]>":]

Entonces puede haber una sección CDATA en cualquier lugar donde puedan aparecer datos de caracteres, incluidas múltiples secciones CDATA adyacentes en lugar de una sola sección CDATA. Eso permite dividir el ]]>token y colocar las dos partes en secciones adyacentes de CDATA.

ex:

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

debe escribirse como

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

Tienes que dividir tus datos en pedazos para ocultar el ]]>.

Aquí está todo:

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

El primero <![CDATA[]]]]>tiene el ]]. El segundo <![CDATA[>]]>tiene el >.

No se escapa del ]]>pero se escapa >después ]]insertando ]]><![CDATA[antes del >, piense en esto como una \cadena C / Java / PHP / Perl, pero solo se necesita antes >y después de a ]].

Por cierto,

La respuesta de S.Lott es la misma, simplemente redactada de manera diferente.

La respuesta de S. Lott es correcta: no codifica la etiqueta final, la divide en varias secciones CDATA.

Cómo resolver este problema en el mundo real: utilizando un editor XML para crear un documento XML que se incorporará a un sistema de gestión de contenido, intente escribir un artículo sobre las secciones CDATA. Su truco habitual de incrustar ejemplos de código en una sección CDATA le fallará aquí. Puedes imaginar cómo aprendí esto.

Pero en la mayoría de las circunstancias, no encontrará esto, y he aquí por qué: si desea almacenar (por ejemplo) el texto de un documento XML como el contenido de un elemento XML, probablemente usará un método DOM, por ejemplo:

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

Y el DOM escapa razonablemente <y el>, lo que significa que no ha incrustado inadvertidamente una sección CDATA en su documento.

Ah, y esto es interesante:

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);

Esta es probablemente una ideosincrasia de .NET DOM, pero eso no arroja una excepción. La excepción se lanza aquí:

Console.Write(doc.OuterXml);

Supongo que lo que sucede debajo del capó es que el XmlDocument está utilizando un XmlWriter para producir su salida, y el XmlWriter verifica la buena forma a medida que escribe.

simplemente reemplace ]]>con]]]]><![CDATA[>

Aquí hay otro caso en el que se ]]>debe escapar. Supongamos que necesitamos guardar un documento HTML perfectamente válido dentro de un bloque CDATA de un documento XML y la fuente HTML tiene su propio bloque CDATA. Por ejemplo:

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

el sufijo CDATA comentado debe cambiarse a:

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

ya que un analizador XML no sabrá cómo manejar los bloques de comentarios de JavaScript

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

Una forma más limpia en PHP:

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

No olvide utilizar un str_replace seguro para múltiples bytes si es necesario (no latin1 $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;
   }

No creo que interrumpir CDATA sea un buen camino a seguir. Aquí está mi alternativa ...

Úselo ]para la secuencia de escape seguida del valor hexadecimal de su personaje. Como en el &#xhhhh;=>]<unicode value>;

De esta manera, si intenta grabar ]]>su codificación, fn producirá lo ]005D;]005D;]003E;que está bien en CDATA.

Es mejor que escapar por nombre de entidad, porque esos no están decodificados cada vez en su aplicación y es posible que tenga diferentes prioridades para escapar de entidades con ampersand frente a escapar de otros caracteres / secuencias. Como resultado, tiene más control sobre el contenido de CDATA.

Ver esta estructura:

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

Para las etiquetas CDATA internas, debe cerrar con en ]]]]><![CDATA[>lugar de ]]>. Simple como eso.