Análisis

Un analizador (parser) es el componente que lee texto de entrada y construye una representación estructurada de él con la que un programa puede trabajar realmente. El texto en bruto es solo una secuencia de caracteres sin significado inherente para el software; un analizador es el paso que convierte ese flujo plano en algo con forma y jerarquía. Se sitúa en la frontera entre el texto escrito por humanos o generado por máquinas y los datos estructurados que necesita el resto de un programa.

Dos etapas: tokenizar y luego construir un árbol

La mayoría de los analizadores funcionan en dos etapas distintas. La primera etapa, un tokenizador o analizador léxico, agrupa caracteres en unidades significativas —etiquetas, palabras, números, operadores, símbolos— de modo que la entrada deja de ser caracteres individuales para ser una secuencia de tokens. La segunda etapa, la construcción del árbol, organiza esos tokens en una jerarquía según una gramática, produciendo un árbol estructurado. Separar estos dos trabajos mantiene cada uno más simple y es un patrón que verás una y otra vez.

La tokenización por sí sola resuelve mucha ambigüedad. Considera cómo los caracteres que forman una etiqueta de apertura, un nombre de atributo y un valor entre comillas deben reconocerse como cosas separadas antes de que pueda construirse cualquier estructura; el tokenizador es lo que establece esas distinciones. Solo una vez que la entrada es un flujo limpio de tokens puede la etapa de construcción del árbol razonar sobre cómo se anidan y se relacionan entre sí.

Los parsers están en todas partes

Los analizadores están genuinamente por todas partes en cuanto empiezas a fijarte. Los compiladores analizan el código fuente en un árbol de sintaxis abstracta antes de generar instrucciones de máquina; los navegadores analizan HTML y CSS para construir las estructuras que renderizan; y las aplicaciones ordinarias analizan JSON, XML, YAML y archivos de configuración cada vez que se inician. Casi cualquier programa que acepta entrada de texto tiene un analizador en algún lugar dentro, aunque el autor nunca piense en él con ese nombre.

Por qué el resultado es un árbol

La salida de un analizador suele ser un árbol, y el tipo de árbol depende del dominio. Para un lenguaje de programación es un árbol de sintaxis abstracta que captura la estructura de las expresiones y sentencias; para una página web es el DOM, el árbol de elementos y nodos de texto que el navegador construye a partir del HTML. En ambos casos el árbol, y no el texto original, es sobre lo que operan las etapas posteriores.

La razón por la que un árbol es la salida natural es que la mayoría de los lenguajes y formatos de documento son inherentemente anidados. Una expresión contiene subexpresiones, un elemento contiene elementos hijos, un bloque de configuración contiene bloques anidados. Una lista plana de tokens no puede capturar ese anidamiento, pero un árbol lo expresa directamente, razón por la cual el análisis se describe tan a menudo como convertir un flujo unidimensional en una estructura de varios niveles.

Qué hace que el parsing de HTML sea singular

Lo que hace inusual el análisis de HTML entre todos estos ejemplos es su recuperación de errores estandarizada. El marcado del mundo real está lleno de errores —etiquetas sin cerrar, elementos mal colocados, atributos en posiciones extrañas— y aun así las páginas necesitan mostrarse. La especificación HTML responde a esto definiendo exactamente cómo debe manejar un analizador cada tipo de entrada malformada, en lugar de dejarlo a que cada implementación adivine.

La consecuencia de esa especificación precisa es una interoperabilidad notable. Como las reglas de recuperación de errores están detalladas con minuciosidad, cada navegador moderno construye el mismo árbol DOM a partir de la misma entrada rota, en lugar de que cada uno improvise de forma diferente. Por eso una página malformada se renderiza de forma consistente entre navegadores, y contrasta con formatos más estrictos como XML, que simplemente rechazan la entrada que no está bien formada en lugar de intentar repararla.

Tolerante frente a estricto, por diseño

Ese contraste resalta una compensación de diseño deliberada. Un analizador indulgente como el de HTML prioriza la resiliencia y que el usuario siempre vea algo, a costa de dejar pasar errores en silencio. Un analizador estricto como el de XML prioriza la corrección y la previsibilidad, a costa de rechazar de plano la entrada imperfecta. Ninguno es universalmente mejor; cada uno se adecúa al trabajo para el que fue diseñado, y reconocer qué filosofía sigue un formato te dice mucho sobre cómo se comporta.

Un modelo mental para todo el stack

En cuanto empiezas a ver el software como una serie de analizadores que convierten texto en estructura, gran parte de la pila de la web se vuelve más fácil de razonar. El navegador analizando HTML en el DOM, el motor analizando JavaScript en un árbol de sintaxis, el servidor analizando el cuerpo de una petición JSON: son todos la misma idea aplicada en lugares diferentes. Esa única lente, la de texto convirtiéndose en datos estructurados a través de un analizador, es uno de los modelos mentales más útiles de toda la programación.