Analizadores sintácticos de HTML y XML en Ruby: una comparación basada en la carga de trabajo

Las versiones actuales y las versiones de Ruby compatibles no se han verificado en entorno de producción para este borrador, por lo que las recomendaciones que dependan del estado actual deben comprobarse en el momento de la publicación.

• Elige Nokogiri como punto de partida práctico para HTML estático o imperfecto y para el trabajo general con árboles XML.
• Elige Ox cuando el análisis de XML, la escritura, el procesamiento de tipo SAX o la serialización de objetos sean fundamentales.
• Elige LibXML Ruby cuando tu flujo de trabajo con XML necesite XPath, además de capacidades de validación o XSLT.
• Considera Oga y Hpricot como alternativas que requieren una revisión especialmente cuidadosa en cuanto a compatibilidad y mantenimiento.
• Utiliza Selenium solo cuando la representación, los clics, el desplazamiento, los formularios o el estado del navegador formen parte del trabajo.

Esa distinción basada en la carga de trabajo resulta más útil que declarar que un conjunto concreto de analizadores HTML y XML para Ruby es universalmente el mejor.

Se aplican los mismos criterios a las seis herramientas. Un asterisco indica que la información proporcionada aún debe confirmarse en la documentación oficial actual.

La categoría de análisis de HTML de Ruby Toolbox ofrece información útil sobre los paquetes, pero los datos del directorio por sí solos no permiten determinar la compatibilidad actual ni establecer una clasificación universal.

Clasifica la entrada antes de comparar las API. Pregúntate si se trata de HTML o XML, si necesitas una recuperación tolerante o un fallo estricto, si cabe en la memoria y qué funciones de consulta o transformación se requieren.

Añade restricciones operativas: compilación nativa, bibliotecas del sistema, entorno de ejecución de Ruby, imagen del contenedor y destino de implementación. Por último, comprueba si los bytes contienen los datos deseados. Si no es así, debe realizarse la recuperación, la autenticación o la representación del navegador antes de que los analizadores de HTML y XML de Ruby puedan extraerlos.

El HTML web suele ser imperfecto. Un analizador HTML de Ruby debería recuperar un árbol utilizable a partir de etiquetas que faltan, anidamientos irregulares y fragmentos, al tiempo que mantiene la previsibilidad de las consultas. Nokogiri cuenta con soporte de código fuente para CSS y XPath, así como para gestionar HTML mal formado, lo que lo convierte en una primera opción sensata para experimentar.

El XML tiene unas reglas diferentes. La estructura, los espacios de nombres y las reglas de validación pueden ser requisitos de negocio, por lo que una recuperación silenciosa puede ser peor que un fallo evidente. Elige un modo centrado en XML y define cómo se muestran los errores.

La recuperación de datos es un proceso independiente. Las cookies, la autenticación, las redirecciones y Ajax determinan qué marcado recibes. Si la respuesta contiene el nodo de destino, analízalo directamente. Si JavaScript crea ese nodo más tarde, primero renderízalo y luego analiza el DOM resultante.

Un árbol DOM carga el documento en un grafo de nodos en memoria. Resulta conveniente para la navegación por padres, hermanos o descendientes, así como para consultas repetidas. El uso de memoria aumenta con el tamaño del documento y la representación en árbol del analizador.

Una interfaz de tipo SAX o de estilo «reader» emite eventos a medida que avanza el analizador. Es adecuada para fuentes de datos de gran tamaño, transformaciones de solo adición y flujos de trabajo que pueden generar registros sin conservar el documento completo. La contrapartida es la gestión del estado: tu controlador debe realizar un seguimiento explícito del contexto, los espacios de nombres y los registros parciales.

Entre estos analizadores de HTML y XML para Ruby, los datos proporcionados indican que el procesamiento SAX se realiza con Ox y que varias interfaces no DOM se llevan a cabo con Nokogiri y LibXML para Ruby. Comprueba las API exactas y mide el pico de memoria residente con fixtures antes de diseñar en función de ellas.

Para la extracción, decide si el equipo prefiere selectores CSS, XPath o ambos. CSS es conciso para patrones de clases y atributos; XPath suele ser mejor para condiciones de texto, ejes y XML que tiene en cuenta los espacios de nombres. Una revisión centrada en XPath frente a los selectores CSS puede evitar que el estilo de los selectores se convierta en una arquitectura accidental.

En el caso del XML, comprueba por separado el registro de espacios de nombres, la validación de DTD o esquemas, XSLT y la notificación de errores. No deduzcas una característica a partir de otra. La instalación merece el mismo rigor: las extensiones nativas pueden mejorar la funcionalidad, pero pueden añadir trabajo relacionado con el compilador, las bibliotecas del sistema o la compilación de imágenes.

Anota en la decisión la versión de la gema, la versión de Ruby, las versiones de las bibliotecas nativas y la fecha de revisión. Vuelve a ejecutar las pruebas de fixture durante las actualizaciones, en lugar de dar por sentado que «se ha instalado correctamente» es prueba de compatibilidad.

Nokogiri es el punto de partida más amplio y respaldado por el código fuente de este conjunto de analizadores de HTML y XML para Ruby. Analiza HTML y XML, permite realizar consultas CSS y XPath, y puede construir un árbol útil a partir de código HTML imperfecto. Esa combinación se adapta al scraping web habitual en Ruby, a la limpieza de feeds, a la inspección de documentos y a las transformaciones que requieren acceso aleatorio a los nodos.

require "nokogiri"

html = "<article><h1>Parser choice</h1><a href='/next'>Next</a></article>"
doc = Nokogiri::HTML.parse(html)

title = doc.at_css("article h1")&.text&.strip
next_url = doc.at_xpath("//a[normalize-space()='Next']")&.attr("href")

Las llamadas de navegación segura son importantes porque los selectores fallan en producción incluso cuando funcionaban con una muestra concreta. Decide si un campo que falta significa nilun registro omitido o un error grave, y luego codifica esa elección en las pruebas.

Nokogiri no recurre páginas ni ejecuta el JavaScript del sitio. Combínalo con un cliente HTTP cuando la respuesta ya contenga los datos. Amplía la capa de recuperación cuando la autenticación o la representación del lado del cliente modifiquen el documento devuelto.

Las fuentes proporcionadas también atribuyen a Nokogiri el soporte para SAX, el análisis «push», XSLT y múltiples backends de analizadores nativos. Trata estas capacidades como funciones sujetas a verificación, especialmente a la hora de elegir entre MRI y otros entornos de ejecución o de crear contenedores mínimos.

Ox y LibXML Ruby resuelven diferentes problemas en los que el XML es lo principal. Ox cubre la entrada y salida de XML basada en árboles, la serialización de objetos Ruby y el consumo de SAX impulsado por eventos. Merece la pena tenerlo en cuenta cuando un analizador XML de Ruby deba serializar objetos o procesar documentos de gran tamaño sin consultas complejas.

LibXML Ruby envuelve libxml2 y se adapta a flujos de trabajo con gran volumen de consultas en los que son importantes las búsquedas XPath, las comprobaciones de esquemas o las transformaciones XSLT. La instantánea del directorio también incluye en la gema interfaces de árbol, eventos, lector pull y escritor, junto con la validación de DTD, RelaxNG y XSD. Comprueba esos detalles con la versión exacta que tengas previsto implementar.

xml = "<person><name>Ada</name></person>"

require "ox"
ox_tree = Ox.parse(xml)

require "xml"
libxml_doc = XML::Parser.string(xml).parse
name = libxml_doc.find("//name").first&.content

No conviertas una prueba de rendimiento antigua en una leyenda del tipo «Nokogiri contra Ox». Una prueba imparcial tiene en cuenta Ruby, los parámetros del compilador, las versiones de las bibliotecas nativas, la estructura del documento, la codificación, el tiempo de calentamiento, el número de repeticiones y si se mide la construcción del árbol, las consultas, la serialización o la transmisión. Indica por separado el rendimiento, la latencia, las asignaciones y el pico de memoria.

El material proporcionado señala posibles limitaciones de Ox en relación con XPath, los espacios de nombres y XSLT, así como una cadena de dependencias nativas para LibXML Ruby. Verifica ambos aspectos antes de la selección, especialmente en el caso de integraciones con un uso intensivo de espacios de nombres y compilaciones de contenedores portátiles.

Oga y Hpricot pertenecen a una rama del árbol de decisión en la que el estado es un factor determinante. Oga mantiene la mayor parte de su implementación en Ruby, utiliza una pequeña extensión y gestiona HTML y XML con XPath, además de consultas XML que tienen en cuenta los espacios de nombres. El punto fuerte de Hpricot es el HTML, aunque la información facilitada indica que puede aceptar XML y ofrece selectores CSS y XPath.

La información disponible también señala una escasa actividad reciente de Oga y que Hpricot ya no recibe mantenimiento, pero no se trata de verificaciones oficiales actuales. Antes de adoptar cualquiera de las dos, comprueba la última versión, la compatibilidad con Ruby, los problemas de compatibilidad y si tu entorno de destino puede compilar su extensión.

En el caso de las aplicaciones existentes, el riesgo que supone la sustitución puede justificar el uso de un adaptador protegido por fixtures. Para una nueva aplicación, es necesario realizar una prueba de compatibilidad satisfactoria y contar con un responsable de mantenimiento explícito antes de elegir cualquiera de las dos como alternativa a Nokogiri.

Selenium es una herramienta de automatización del navegador, no un analizador HTML habitual de Ruby. Úsalo cuando JavaScript cree el DOM necesario, o cuando el flujo de trabajo deba hacer clic, desplazarse, enviar formularios o conservar el estado del navegador. La documentación oficial de Selenium WebDriver explica su modelo de control del navegador.

Empieza con la recuperación HTTP más un analizador. Si una respuesta guardada carece de datos visibles en un navegador, traslada solo la representación o la interacción a Selenium. A continuación, extrae la información con localizadores o pasa el código fuente de la página representada a Nokogiri para su procesamiento mediante CSS o XPath.

Esto añade procesos del navegador, gestión de controladores, esperas y más modos de fallo. La semántica actual de las esperas y la configuración de los controladores dependen de la versión, así que compruébalas en lugar de repetir las directrices antiguas. No asumas esa sobrecarga para un marcado estático que un cliente HTTP ya devuelve.

Para el análisis de datos de producción, utiliza un contrato explícito de entrada y salida:

1. Recibe o recupera bytes y, a continuación, registra la URL final, el estado, el tipo de contenido y el juego de caracteres declarado.
2. Resuelve la codificación antes de que se ejecuten los selectores. Conserva los bytes originales, ya que puede ser necesario investigar la transcodificación o las entradas mal formadas.
3. Analiza en el modo elegido para tolerancia HTML, XML estricto o streaming.
4. Extrae los campos con selectores que gestionen deliberadamente los nodos que falten.
5. Valida los campos obligatorios, los tipos, los espacios de nombres o los esquemas antes de generar un registro.
6. Guarda ejemplos representativos, incluyendo marcado mal formado, diseños modificados, campos vacíos y muestras que no sean UTF-8.
7. Ejecuta pruebas de selectores con esos casos de prueba cada vez que se actualice el analizador o alguna dependencia.

def extract_title(html)
  doc = Nokogiri::HTML.parse(html)
  title = doc.at_css("article h1")&.text&.strip
  raise KeyError, "article h1 missing" if title.to_s.empty?
  { title: title }
end

Registra los errores de análisis con un contexto seguro para los casos de prueba, en lugar de documentos completos que contengan información sensible. Trata el XML no fiable como una revisión de seguridad independiente, en lugar de dar por sentado que los valores predeterminados del analizador son seguros.

Antes de estandarizar el uso de estos analizadores de HTML y XML en Ruby, responde a lo siguiente:

• ¿La entrada es HTML estático, HTML malformado, XML estricto o un DOM renderizado por el navegador?
• ¿Cabe el documento en la memoria o es necesario leer los registros por flujos?
• ¿Se requieren CSS, XPath, espacios de nombres, validación o XSLT?
• ¿La serialización de objetos forma parte de la carga de trabajo?
• ¿Qué bibliotecas nativas, compiladores, navegadores o controladores deben incluirse?
• ¿Se ha comprobado que la gema concreta sea compatible con la versión de Ruby y el sistema operativo de destino?
• ¿Es la herramienta una dependencia heredada que debería situarse detrás de un adaptador?
• ¿Cubren los fixtures guardados la codificación, las entradas malformadas, los selectores ausentes y las actualizaciones?

El mejor analizador XML o HTML de Ruby es aquel que cumple esas restricciones con el menor tiempo de ejecución fiable.

• Clasifica la carga de trabajo antes de elegir una gema: el HTML estático, el XML estricto, el XML en flujo, la serialización de objetos y las páginas renderizadas requieren herramientas diferentes.
• Mantén la recuperación, la autenticación, la representación y el análisis como etapas separadas del proceso, de modo que los fallos se asignen a la capa correcta.
• Verifica las versiones actuales, las dependencias nativas y la compatibilidad con la plataforma utilizando exactamente la versión de Ruby y la imagen de implementación que vas a utilizar.
• Realiza pruebas de rendimiento con casos de prueba representativos y comprueba los selectores, los nodos que faltan, las codificaciones y las entradas mal formadas antes de dar por listo para producción cualquier analizador.

No. Nokogiri analiza la cadena HTML o XML que se le proporciona y no ejecuta los scripts de la página. Recupera el DOM renderizado con una herramienta del navegador cuando JavaScript cree el elemento de destino; a continuación, consulta ese DOM directamente o pasa el código fuente de la página a Nokogiri. Si un punto final devuelve los mismos datos como JSON o HTML, utilizar esa respuesta suele ser más sencillo que controlar el navegador.

Utiliza el análisis en flujo o SAX cuando los documentos sean demasiado grandes para construir el árbol con comodidad o cuando cada registro pueda procesarse una sola vez en orden. Funciona bien para feeds, exportaciones y transformaciones que emiten resultados de forma incremental. Opta por un DOM cuando la extracción requiera navegación arbitraria, consultas repetidas o modificaciones en partes distantes del documento.

Considera ambas opciones como elecciones dependientes del contexto, en lugar de valores predeterminados automáticos. Antes de adoptarlas, comprueba que se trate de una versión reciente, que sea compatible con tu versión de Ruby, que la compilación se realice correctamente en todos los entornos de implementación y que la respuesta a los incidencias sea aceptable. Una pequeña prueba de compatibilidad debería analizar tus fixtures reales y poner a prueba los espacios de nombres, las entradas mal formadas y los selectores. El código existente puede justificar su mantenimiento tras un adaptador, incluso cuando una nueva compilación optaría por otra solución.

Una comparación justa requiere, en primer lugar, una salida y un comportamiento ante fallos idénticos, ya que una recuperación más rápida carece de sentido si los analizadores construyen árboles diferentes. Utiliza grupos de fixtures separados para documentos pequeños, documentos grandes, espacios de nombres, entradas mal formadas, streaming y serialización. Informa de las distribuciones de las ejecuciones en lugar de un único resultado óptimo, incluye los efectos de la recolección de basura y publica el conjunto de pruebas para que otro ingeniero pueda reproducir la prueba.

Elegir entre analizadores HTML y XML de Ruby resulta mucho más sencillo una vez que la carga de trabajo queda clara. Nokogiri es el punto de partida práctico y de uso general para el trabajo con HTML y árboles mixtos. Ox merece ser evaluado para la serialización de XML y el procesamiento de eventos, mientras que LibXML Ruby se adapta a los flujos de trabajo de XML que necesitan funciones de XPath, validación o transformación. Oga y Hpricot requieren un mayor mantenimiento y comprobaciones de compatibilidad, y Selenium solo tiene cabida cuando se requiere realmente la representación o la interacción.

Elijas lo que elijas, mantén el analizador detrás de una interfaz restringida. Conserva los datos de prueba sin procesar, prueba los selectores y el comportamiento ante nodos ausentes, registra las suposiciones de codificación y fija los detalles de tiempo de ejecución que afectan a las extensiones nativas. Realiza pruebas de rendimiento con tus propios documentos en lugar de basarte en la clasificación de velocidad de otros.

La recuperación puede acabar resultando más difícil que el análisis. Si las solicitudes bloqueadas, los CAPTCHAs o la rotación de proxies están consumiendo el presupuesto de ingeniería, la API Scraper de WebScrapingAPI puede devolver HTML sin procesar mientras se encarga del trabajo de la capa de solicitudes, dejando que tu código Ruby se centre en una etapa de extracción pequeña y comprobable. Esa es la delimitación más clara: la recuperación genera un marcado fiable y el analizador seleccionado lo convierte en datos validados.