This article needs additional citations for verification. (December 2021) |
El término CDATA , que significa datos de caracteres , se utiliza con fines distintos, pero relacionados, en los lenguajes de marcado SGML y XML . El término indica que una determinada parte del documento son datos de caracteres generales , en lugar de datos que no son de caracteres o datos de caracteres con una estructura más específica y limitada.
En un documento XML o una entidad externa, una sección CDATA es un fragmento de contenido de un elemento que está marcado para ser interpretado literalmente, como datos textuales, no como contenido marcado. [1] Una sección CDATA es simplemente una sintaxis alternativa para expresar datos de caracteres; no existe ninguna diferencia semántica entre los datos de caracteres en una sección CDATA y los datos de caracteres en la sintaxis estándar donde, por ejemplo, " <
" y " &
" se representan mediante " <
" y " &
", respectivamente.
Una sección CDATA comienza con la siguiente secuencia:
< ![CDATA[
y termina con la siguiente ocurrencia de la secuencia:
]]>
Todos los caracteres incluidos entre estas dos secuencias se interpretan como caracteres, no como marcas ni referencias a entidades. Todos los caracteres se toman de forma literal, con la única excepción de la ]]>
secuencia de caracteres. En:
<remitente> John Smith </remitente>
Las etiquetas de inicio y fin del remitente se interpretan como marcado. Sin embargo, el código:
<![CDATA[<sender>John Smith</sender>]]>
es equivalente a:
< remitente > John Smith < /remitente >
De esta forma, las “etiquetas” tendrán exactamente el mismo estatus que las “John Smith”; serán tratadas como texto.
De manera similar, si la referencia de carácter numérico ð
aparece en el contenido del elemento, se interpretará como el carácter Unicode único 00F0 (letra minúscula eth ). Pero si aparece en una sección CDATA, se analizará como seis caracteres: ampersand, almohadilla, dígito 2, dígito 4, dígito 0, punto y coma.
Los nuevos autores de documentos XML a menudo no comprenden el propósito de una sección CDATA, creyendo erróneamente que su propósito es "proteger" los datos para que no sean tratados como datos de caracteres ordinarios durante el procesamiento. Algunas API para trabajar con documentos XML ofrecen opciones para el acceso independiente a las secciones CDATA, pero dichas opciones existen más allá de los requisitos normales de los sistemas de procesamiento XML y aún así no cambian el significado implícito de los datos. Los datos de caracteres son datos de caracteres, independientemente de si se expresan mediante una sección CDATA o mediante un marcado ordinario. Las secciones CDATA son útiles para escribir código XML como datos de texto dentro de un documento XML. Por ejemplo, si uno desea componer un libro con XSL que explique el uso de una aplicación XML, el marcado XML que aparecerá en el libro mismo se escribirá en el archivo de origen en una sección CDATA.
Una sección CDATA no puede contener la cadena " ]]>
" y, por lo tanto, no es posible que una sección CDATA contenga secciones CDATA anidadas. El enfoque preferido para usar secciones CDATA para codificar texto que contiene la tríada " ]]>
" es usar múltiples secciones CDATA dividiendo cada ocurrencia de la tríada justo antes de " >
". Por ejemplo, para codificar " ]]>
" se escribiría:
<![CDATA[]]]]><![CDATA[>]]>
Esto significa que para codificar " ]]>
" en el medio de una sección CDATA, reemplace todas las apariciones de " ]]>
" con lo siguiente:
]]]]> <![CDATA[>
Esto detiene y reinicia efectivamente la sección CDATA.
En los datos de texto, cualquier carácter Unicode que no esté disponible en la codificación declarada en el <?xml ...?>
encabezado se puede representar mediante una &#nnn;
referencia de carácter numérico . Sin embargo, el texto dentro de una sección CDATA está estrictamente limitado a los caracteres disponibles en la codificación.
Debido a esto, el uso de una sección CDATA de manera programática para citar datos que podrían contener caracteres ' &
' o ' <
' puede causar problemas cuando los datos contienen caracteres que no se pueden representar en la codificación. Según la implementación del codificador, estos caracteres se pueden perder, se pueden convertir en los caracteres de la &#nnn;
referencia de caracteres o pueden hacer que la codificación falle. Pero no se mantendrán.
Otro problema es que un documento XML puede transcodificarse de una codificación a otra durante el transporte. Cuando el documento XML se convierte a un conjunto de caracteres más limitado, como ASCII, los caracteres que ya no se pueden representar se convierten en &#nnn;
referencias de caracteres para una conversión sin pérdida. Pero dentro de una sección CDATA, estos caracteres no se pueden representar en absoluto y deben eliminarse o convertirse en algún equivalente, alterando el contenido de la sección CDATA.
Las secciones CDATA en documentos XHTML pueden ser analizadas de forma diferente por los navegadores web si representan el documento como HTML, ya que los analizadores HTML no reconocen los marcadores de inicio y fin de CDATA, ni reconocen las referencias a entidades HTML, como las que se encuentran <
dentro de <script>
las etiquetas. Esto puede causar problemas de representación en los navegadores web y puede conducir a vulnerabilidades de secuencias de comandos entre sitios si se utiliza para mostrar datos de fuentes no confiables, ya que los dos tipos de analizadores no estarán de acuerdo sobre dónde termina la sección CDATA.
Dado que es útil poder utilizar signos de menor que ( <
) y ampersands ( &
) en scripts de páginas web, y en menor medida en estilos, sin tener que acordarse de escaparlos, es común utilizar marcadores CDATA alrededor del texto de elementos en línea <script>
y <style>
en documentos XHTML. Pero para que el documento también pueda ser analizado por analizadores HTML, que no reconocen los marcadores CDATA, estos marcadores suelen estar comentados, como en este ejemplo de JavaScript :
< script type = "text/javascript" > //<![CDATA[ documento . write ( "<" ); //]]> </ script >
o este ejemplo de CSS :
< estilo tipo = "texto/css" > /*<![CDATA[*/ cuerpo { imagen-de-fondo : url ( "marble.png?width=300&height=300" ) } /*]]>*/ </ estilo >
Esta técnica solo es necesaria cuando se utilizan scripts y hojas de estilo en línea, y es específica del lenguaje. Las hojas de estilo CSS, por ejemplo, solo admiten el segundo estilo de comentario ( /* … */
), pero CSS también tiene menos necesidad de los caracteres <
y &
que JavaScript y, por lo tanto, menos necesidad de marcadores CDATA explícitos.
En los archivos de definición de tipo de documento (DTD) para SGML y XML, un valor de atributo puede designarse como de tipo CDATA: datos de caracteres arbitrarios. Dentro de un atributo de tipo CDATA, se permite el marcado de referencia de entidad y carácter, que se procesará cuando se lea el documento.
Por ejemplo, si un DTD XML contiene
<!ATTLIST foo a CDATA #IMPLIED >
Esto significa que los elementos llamados foo pueden tener opcionalmente un atributo llamado " a " que es del tipo CDATA. En un documento XML válido según esta DTD, podría aparecer un elemento como este:
<foo a= "1 y 2 son < 3
" />
y un analizador XML interpretaría el valor del atributo " a " como los datos de caracteres " 1 y 2 son < 3 ".
Una DTD SGML o XML también puede incluir declaraciones de entidad en las que se utiliza el token CDATA para indicar que la entidad consta de datos de caracteres. Los datos de caracteres pueden aparecer dentro de la propia declaración o pueden estar disponibles externamente, referenciados por un URI . En cualquier caso, se permite el marcado de referencia de carácter y de entidad de parámetro en la entidad, y se procesará como tal cuando se lea.
<DISPLAY_NAME Atributo= "Y" > <![CDATA[PFTEST0__COUNTER_6__:4:199:, PFTEST0__COUNTER_7__:4:199:]]> </DISPLAY_NAME> <SVLOBJECT><LARGO nombre= "" val= "" ENTERO nombre= "" val= "" LARGO nombre= "" val= "" /></SVLOBJECT>