El parser, de la línea al campo

Un parser no es solo un patrón. Una definición completa dice de qué fuente es, cómo se parte la línea, qué campos son obligatorios, en qué zona horaria se interpreta la hora y qué se hace con lo que no casa. Lo del patrón (grupos, cuantificadores) se estudia en otro módulo; aquí se lee como una pieza más.

Abre el laboratorio y lee proxy-web-v1.yml. Fíjate en tres líneas: el patron, los campos_obligatorios y si_no_casa. Después lee muestras.txt y resultado.txt, que muestran el resultado de aplicar el parser a doce líneas reales del proxy.

El parser parte una línea solo si toda ella cabe en el patrón, de principio a fin. Una línea con un campo de más o con un valor de otra forma no se parte a medias: no se parte.

Cuando una línea no casa hay que averiguar la causa antes de tocar el patrón: puede ser una variante legítima que el parser no previó, o un cambio del proveedor. Compara cada línea sin parsear con el patrón.

Dos de las tres líneas sin parsear comparten el mismo motivo: el campo del cliente trae un valor con una forma que el patrón no admite. La tercera falla por otra cosa.

Hay tres políticas posibles para una línea que no casa: descartarla, guardarla entera en un campo aparte o hacer que el parser falle. El parser de ejemplo guarda la línea entera en _sin_parsear. Es la política más segura, con una condición: alguien tiene que mirar ese campo.

Lo que se descarta en silencio no deja rastro. Una detección que lee cliente no sabe que existe una línea sin cliente: simplemente no la ve.

El parser también decide el tipo con que se guarda cada campo: texto, entero, fecha-hora, dirección. Un campo numérico guardado como texto parece correcto hasta que una detección intenta compararlo: con texto, «900» es mayor que «2000» porque se ordena letra a letra, no como cantidad.

Lee campos.txt.