html - tipo - ¿Qué lenguaje de marcado para el contenido con mucho formato?

xhtml

Question

Cuando está desarrollando una aplicación basada en la web y desea permitir el texto enriquecido con formato del usuario, debe elegir cómo permitir esa entrada. Se han creado muchos lenguajes de marcado diferentes porque es discutible que sea más difícil desinfectar el HTML.

¿Cuáles son las ventajas y desventajas de los distintos lenguajes de marcado como:

• HTML
• Reducción
• BBCode
• Textil
• Marcado de MediaWiki
• otro

O para decirlo de otra manera, ¿qué factores considera al elegir usar un lenguaje de marcado particular?

Answer 1

Markdown, BBCode, Textile, MediaWiki markup son todos básicamente el mismo concepto general, por lo que realmente agruparía esto en dos categorías: HTML y marcado de texto sin formato.

HTML

El acuerdo con HTML es que el contenido ya está en un formato "presentable" para contenido web. Eso es genial, ahorra tiempo de procesamiento y es un lenguaje fácilmente analizable. Hay docenas de bibliotecas en casi cualquier idioma para manejar contenido HTML, convertir a / desde HTML a otros formatos, etc. La desventaja principal es que debido a los estándares sueltos de los primeros días web, HTML puede ser increíblemente variable y usted puede Depende siempre de la entrada correcta al aceptar HTML de los usuarios. Como se señaló, ordenar o santificar HTML a menudo es muy difícil, especialmente porque no sigue las reglas de marcado normales de la misma forma que XML (es decir, las etiquetas cerradas incorrectamente son comunes).

Marcado de texto sin formato

Esta categoría se usa frecuentemente por las siguientes razones:

• Fácil de analizar en múltiples formas de una fuente: PDF, HTML, RTF
• El contenido se almacena en texto plano legible (por lo general, mucho más fácil de leer que el HTML sin procesar) en caso de ser necesario en una fecha posterior, en lugar de tener que extraer del HTML
• Sigue reglas definidas específicas donde HTML puede ser una variable molesta y desestructurada
• Le permite forzar un subconjunto de formato de contenido que es más apropiado en muchos casos que simplemente permitir HTML completo
• Además de forzar un subconjunto de HTML, facilita la desinfección de los datos de entrada y evita problemas de scripts entre sitios, etc.
• Mantener los datos "en bruto" en un formato abstracto significa que, en una fecha posterior, si por ejemplo desea convertir su sitio de HTML 4 a XHTML, solo necesita cambiar el código de análisis. Con la entrada de usuario formateada en HTML, ahora está estancado al tener que convertir todo el HTML a XHTML individualmente, lo que, como muestra HTML Tidy, no siempre es una tarea sencilla. De forma similar, si aparece un nuevo lenguaje de marcado en algún momento o si necesita pasar a un formato alternativo (RTF, PDF, TeX), un subconjunto restringido de opciones de formato de texto lo convierte en una tarea mucho más simple.

En resumen, ¿para qué se utiliza la información del usuario? Si planea guardar los datos y es posible que deba barajar formatos, etc., tiene sentido utilizar un formato de resumen cuidadoso para almacenar la información. Si necesita trabajar manualmente con los datos brutos por alguna razón, entonces puntos de bonificación si ese formato es fácilmente legible para el ser humano. Si solo muestra el contenido en una página web (o documento HTML para un informe, etc.) y no tiene dudas sobre cómo convertirlo o protegerlo en el futuro, entonces es una práctica razonable almacenarlo en HTML.

Answer 2

Jeff discutió algunos pros y contras en codinghorror.com mientras estaban en las etapas iniciales de armar SO. Pensé que era una lectura que valía la pena.

Answer 3

"Se han creado muchos lenguajes de marcado diferentes porque es discutible que sea más difícil desinfectar HTML".

De Verdad? ¿Cómo es difícil? Hay funciones para eliminar atributos o etiquetas potencialmente peligrosos y validar el HTML antes de ingresarlo en la base de datos o archivo. ¿Me puede dar ejemplos de cómo es difícil desinfectar HTML?

Answer 4

@netrox la base de datos no es el problema, la salida del navegador es.

La única preocupación es la representación final que puede romperse mediante el código HTML insertado por el usuario. Por ejemplo, el usuario podría abrir una etiqueta <li> pero nunca cerrarla, lo que dependiendo de cómo esté estructurada la página, podría potencialmente romper todo el diseño que sigue. O bien, otro ejemplo abra una etiqueta <strong> sin cerrarla, dejando en negrita todo el contenido restante.

Por lo tanto, no solo se deben validar las etiquetas permitidas, sino cómo exactamente se permiten algunas etiquetas pero no las demás. Debido a que es muy fácil evitar el análisis de todas las etiquetas HTML utilizando el método PHP htmlspecialchars() , por ejemplo, pero cuando se trata de permitir algunas de las etiquetas tendrá que buscar otras formas. Existe la función de strip_tags() PHP que elimina (elimina por completo) las etiquetas no permitidas, pero eso significa que altera el contenido del usuario de forma incorrecta, impidiendo al usuario publicar código simple, por ejemplo (código para compartir / mostrar, no código para procesar).

Además de romper el diseño, debe considerar los ataques XSS, como insertar javascript en el atributo href de un enlace, que por ejemplo podría redirigir a los usuarios a otro sitio. Consulte esta larga lista de posibles ataques XSS: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

Como puede ver, evitar que se interpreten todas las etiquetas HTML es muy fácil, pero prevenir solo algunas de las etiquetas es mucho más complicado. Para entender eso, puedes echar un vistazo al enorme marco de trabajo " HTML Purifier " que solo tiene como objetivo permitir algunas etiquetas HTML y asegurarte de que el HTML entregado sea válido (es decir, no rompa la página) y libre de ataques XSS.