Html dentro de XML. ¿Debo usar CDATA o codificar el HTML?

Estoy usando XML para compartir contenido HTML. AFAIK, podría incrustar el HTML ya sea por:

  • Codificándolo: no sé si es completamente seguro de usar. Y tendría que decodificarlo de nuevo.

  • Usar secciones CDATA: aún podría tener problemas si el contenido contiene la etiqueta de cierre “]]>” y ciertos caracteres hexadecimales, creo. Por otro lado, el analizador XML extraería la información de forma transparente para mí.

¿Qué opción debería elegir?

ACTUALIZACIÓN: El xml se creará en java y se pasará como una cadena a un servicio web .net, donde se analizará. Por lo tanto, necesito poder exportar el xml como una cadena y cargarlo usando “doc.LoadXml (xmlString);”

Las dos opciones son casi exactamente iguales. Aquí están sus dos opciones:

This is <b>bold</b> bold]]> 

En ambos casos, debe verificar su cadena para que se escapen los caracteres especiales. Muchas personas pretenden que las cadenas CDATA no necesitan escaparse, pero como usted señala, debe asegurarse de que “]]>” no se deslice sin protección.

En ambos casos, el procesador XML devolverá su cadena decodificada.

CDATA es más fácil de leer a simple vista, mientras que el contenido codificado puede tener el final de los marcadores CDATA de forma segura, pero no tiene que preocuparse. Solo use una biblioteca XML y deje de preocuparse por eso. Entonces, todo lo que tiene que decir es “Ponga este texto dentro de este elemento” y la biblioteca lo codificará o envolverá en marcadores CDATA.

CDATA por simplicidad.

Si usa CDATA, debe decodificarlo correctamente (textContent, value e innerHTML son métodos que NO devolverán los datos correctos).

digamos que usas una estructura xml similar a esto:

   flagOK 479   htmlOutput  2013/12/05 02:00 - 2013/12/07 01:59 RastreadoPlacaData horaKm/hDireçãoAzimuteMapaSilveradoCQK005205/12/2013 13:55113NE40-22.6766,-50.2218SilveradoCQK005205/12/2013 13:56112NE23-22.6638,-50.2106SilveradoCQK005205/12/2013 18:00111SE118-22.7242,-50.2352 ]]>    

en javascript, entonces decodificará cargando el xml (jquery, por ejemplo) en una variable como xmlDoc a continuación y luego obteniendo nodeValue para la segunda ocurrencia ( item(1) ) de la etiqueta de content

 xmlDoc.getElementsByTagName("content").item(1).childNodes[0].nodeValue 

o (ambas anotaciones son equivalentes)

 xmlDoc.getElementsByTagName("content")[1].childNodes[0].nodeValue 

No sé qué creador de XML está utilizando, pero PHP (en realidad, libxml) sabe cómo manejar ]]> dentro de las secciones de CDATA, y lo mismo ocurre con cualquier otro marco XML. Entonces, usaría una sección CDATA.

Tiene sentido ajustar HTML en CDATA. El texto HTML probablemente constituirá un solo valor en XML.

Así que no incluirlo en CDATA hará que todos los analizadores xml lo lean como parte del documento XML. Si bien es fácil eludir este problema al usar el xml, ¿por qué el dolor de cabeza extra?

Si realmente quiere analizar el HTML en un DOM, entonces es mejor leer el texto HTML y configurar un analizador para leer la prueba por separado.

Espero que salga como yo quería.

Personalmente, odio los segmentos CDATA, así que utilizaría la encoding en su lugar. Por supuesto, si agrega XML a XML a XML, esto daría como resultado la encoding sobre la encoding sobre la encoding y, por lo tanto, algunos resultados muy ilegibles. ¿Por qué odio los segmentos CDATA? Ojalá supiera. Preferencia personal, en su mayoría. Simplemente no me gusta acostumbrarme a agregar “personajes prohibidos” dentro de un segmento especial donde de repente se les permitiría volver. Simplemente me confunde cuando veo el marcado XML dentro de un segmento CDATA y no es parte del XML que lo rodea. Al menos con la encoding, veré que está codificada.

Buenas bibliotecas XML manejarán los segmentos de encoding y CDATA de forma transparente. Solo son mis ojos los que se lastiman.

La encoding funcionará bien y es confiable. Puede codificar secciones codificadas, etc. sin dificultad.

La deencoding se realizará de forma automática con el analizador XML que se utilice para manejar el código HTML codificado.

Creo que la respuesta depende de lo que planeas hacer con el contenido html y también del tipo de contenido html que piensas admitir.

Especialmente cuando se trata de javascript incluido, la encoding a menudo genera problemas. CDATA definitivamente te ayuda allí.

Si planeas usar solo pequeños fragmentos (es decir, un párrafo) y tienes una forma de preprocesar / filtrarlo (porque oyu no quieres javascript o cosas extravagantes de todos modos), probablemente estarás mejor con la encoding o simplemente poniéndolo directamente como subárbol en el xml. También puede postprocesar el html (es decir, estilo de filtro o atributos onclick). Pero esto es definitivamente más trabajo.

Puedes usar la combinación de ambos. Por ejemplo, si quiere pasar

....

en el nodo xml, tiene que usar la sección CDATA para pasarlo. El contenido dentro de

...

debe estar codificado en entidades html como, por ejemplo, < , para < . La encoding entre tags resolverá el problema de]]> quedar atrapado mientras se convierte a ]]> y las tags html no contienen ]]> .

Puede hacer esto solo si html es generado por usted mismo.

Si su HTML está bien formado, simplemente incruste las tags HTML sin escaparse ni envolverse en CDTATA. Si es posible, ayuda a mantener su contenido en XML. Le da más flexibilidad para transformar y manipular el documento.

Puede establecer un espacio de nombre para el HTML, de modo que pueda desambiguar las tags HTML del otro XML que lo envuelve.

Texto escapado significa que todo el bloque HTML será un gran nodo de texto. El ajuste en CDATA le dice al analizador XML que no analice esa sección. Puede ser “más fácil”, pero limita tus capacidades hasta el límite y solo debe emplearse cuando sea apropiado; no solo porque es más conveniente. El marcado escapado se considera dañino.

    Intereting Posts