La validación y normalización de direcciones se citan casi siempre juntas, como si fueran dos nombres para la misma tarea, y sin embargo responden a preguntas distintas. Una decide si el dato merece ser aceptado; la otra decide cómo se escribe para poder compararlo. Cuando un sistema mezcla ambas responsabilidades, empieza a rechazar datos correctos y a aceptar datos imposibles, y el fallo es difícil de localizar porque no hay error visible, solo resultados que no cuadran.
Dos preguntas distintas sobre el mismo dato
La validación responde a la pregunta de si el valor cumple las condiciones para ser admitido. Esas condiciones pueden ser de forma, de coherencia interna o de existencia. La normalización responde a otra pregunta: dado un valor admisible, ¿cuál es su forma canónica para que dos escrituras equivalentes se reconozcan como la misma?
La diferencia se ve bien en un ejemplo cotidiano. Una dirección con la división administrativa y el código postal de regiones diferentes es formalmente correcta y coherente por dentro, pero no supera una validación de coherencia. Y una dirección con espacios sobrantes, mayúsculas inconsistentes y abreviaturas mezcladas puede ser perfectamente válida y necesitar normalización antes de compararse con otra.
Por qué el orden de los pasos importa
El orden natural es primero normalizar y después validar, no al contrario. Si se valida sobre la forma bruta, cualquier variación inocente —un espacio de más, un acento escrito de otra manera, una abreviatura distinta— puede provocar un rechazo que no corresponde. Si se normaliza primero, la validación trabaja sobre un valor estable y las reglas pueden ser más estrictas sin volverse frágiles.
Hay una excepción que conviene tener presente: la validación de existencia. Comprobar si una dirección determinada existe de verdad en el terreno requiere una fuente externa, y esa consulta normalmente se hace sobre la forma ya normalizada, porque de lo contrario la misma dirección se consulta varias veces con escrituras distintas y se obtienen respuestas incoherentes.
¿Qué se puede comprobar sin consultar nada externo?
Bastante, siempre que no se prometa más de lo que se puede cumplir. Sin ninguna fuente externa se pueden comprobar cosas como estas:
- Que los campos obligatorios están presentes y no contienen solo espacios.
- Que la longitud de cada campo está dentro de un rango razonable.
- Que el código de país pertenece a la lista de códigos válidos.
- Que la forma del código postal corresponde a alguno de los patrones admitidos para ese país.
- Que la división administrativa declarada pertenece a la lista de ese país.
- Que el código postal y la división no se contradicen cuando el país tiene una organización postal que lo permite comprobar.
Lo que no se puede comprobar sin una fuente externa es si la dirección existe. Y conviene decirlo con claridad en la interfaz: un sistema que dice «dirección válida» cuando solo ha comprobado el formato está prometiendo algo que no puede verificar.
¿Qué se normaliza exactamente?
La normalización más habitual afecta a detalles de escritura que no cambian el significado. Se recortan los espacios al principio y al final, se colapsan los espacios repetidos, se unifican las mayúsculas y minúsculas según la convención elegida y se sustituyen las variantes tipográficas de comillas y guiones por su forma estándar.
Después vienen las decisiones de fondo, que son las que suelen generar discusión. ¿Se expanden las abreviaturas de tipo de vía o se conservan? ¿Se quitan los acentos? ¿Se conserva el punto de la abreviatura? Cada respuesta tiene consecuencias. Expandir abreviaturas puede hacer que dos direcciones distintas se vuelvan idénticas; quitar acentos destruye información y complica la lectura local; conservar la forma original y comparar con una versión derivada es casi siempre la opción menos dañina.
| Operación | Qué cambia | Riesgo |
|---|---|---|
| Recortar y colapsar espacios | Nada relevante | Ninguno apreciable |
| Unificar mayúsculas | La presentación | Perder la forma preferida por quien la escribió |
| Expandir abreviaturas | El texto | Que dos direcciones diferentes colisionen |
| Eliminar acentos | El alfabeto | Información irrecuperable |
| Extraer los dígitos del código postal | El formato | Confundir códigos con extensiones distintas |
El problema de la forma canónica única
No existe una forma canónica universal de escribir una dirección. Cada país tiene su orden, sus abreviaturas reconocidas y sus convenciones de puntuación, y lo que es canónico en uno resulta extraño en otro. Por eso la normalización sensata es específica del país: se aplican las reglas del territorio al que pertenece la dirección y se conserva el resto.
Esto choca con la tentación de aplicar una receta única a todos los registros. Funciona mientras todos los datos vengan del mismo país y se rompe en el momento en que aparece el primero de otro. La alternativa es adoptar una forma interna propia, documentada, que sirva para comparar dentro del sistema, y no confundirla nunca con la forma que se muestra al usuario o se imprime en una etiqueta.
Cómo probar que ambas cosas funcionan
Las pruebas útiles aquí no buscan casos normales, sino variantes. Merece la pena preparar el mismo dato escrito de varias maneras —con y sin acentos, con abreviaturas distintas, con espacios de más, con la división y el código postal intercambiados— y comprobar tres cosas: que los equivalentes se reconocen como iguales, que los distintos no se fusionan y que las incoherencias se detectan.
El generador de direcciones falsas sirve para construir esos conjuntos sin usar datos de personas. Los registros que produce son solo para pruebas de software: no pertenecen a ninguna vivienda ni destinatario real y no deben utilizarse para enviar nada. Si además vas a comprobar cómo se comporta la captura en un formulario real, la guía sobre casos de prueba del formulario de dirección en el pago recoge las variantes que más fallos destapan.
Notas para quien programa
- Separa las dos funciones. Si la misma rutina rechaza y reescribe a la vez, no se puede saber cuál de las dos causó un resultado inesperado.
- Normaliza antes de validar. Las reglas se vuelven más simples y dejan de rechazar datos correctos por motivos de forma.
- No prometas existencia. El formato se comprueba en local; la existencia requiere una fuente externa. Mezclar ambos mensajes engaña a quien usa el sistema.
- Conserva el original. Guarda el valor tal como lo escribió la persona y añade aparte la versión normalizada. La conversión no siempre es reversible.
- Documenta la forma interna. Si hay una representación propia para comparar, tiene que estar escrita en algún sitio o cada desarrollador inventará la suya.
- Prueba con variantes equivalentes. Un conjunto de pruebas compuesto solo por casos bien escritos no demuestra nada sobre la normalización.
Siguientes pasos
Coge diez direcciones de tu sistema y escribe cada una de dos maneras distintas; después comprueba si tu código las considera iguales. Con ese ejercicio sabrás si tienes un problema de normalización o de validación. Si necesitas más material para el conjunto de pruebas, el generador produce direcciones completas por país y evita reutilizar datos reales.