Un número escrito a mano se equivoca casi siempre de la misma forma: se cambia un carácter, se intercambian dos posiciones o se añade un dígito de más. La validación de números existe para detectar esos accidentes antes de que lleguen a una base de datos, y sostiene hoy la mayoría de los formularios que rellenamos a diario. Este artículo explica las tres capas que intervienen, en qué orden conviene aplicarlas y por qué hay que separar dos ideas que se mezclan continuamente: que un número esté bien formado y que ese número sea real.
¿Qué es la validación de números?
Comprobar un número consiste en aplicar reglas que su emisor hizo públicas para que cualquiera pueda verificar, sin consultar ningún registro, que la cadena se copió sin errores. Esas reglas no dicen quién es el titular ni si el número sigue vigente; solo describen cómo tiene que estar escrito y cómo se obtiene su último carácter.
De ahí sale la primera conclusión práctica: la comprobación es una prueba de forma, no una prueba de existencia. Un sistema que confunde ambas cosas acaba rechazando entradas legítimas o aceptando entradas inventadas, y las dos fallas se notan tarde, cuando ya hay datos sucios en la base y ya nadie recuerda de dónde salieron.
Conviene además fijar el vocabulario, porque es la parte que más se descuida. Un número que pasa la comprobación es válido según ese esquema. Uno cuya forma encaja pero cuyo último carácter no cuadra es no válido. Uno cuyo formato se conoce pero cuyo algoritmo nunca se publicó queda en solo formato. Y uno para el que no existe ninguna regla conocida se queda sin regla. Son cuatro respuestas distintas, y mezclarlas empobrece el diagnóstico. Las dos últimas merecen un desarrollo aparte, y están explicadas con detalle en la guía sobre números sin dígito verificador.
Tres capas que filtran en orden: caracteres, longitud y dígito verificador
La comprobación se organiza en tres filtros que se aplican uno detrás de otro, y cada uno atrapa un tipo de error diferente.
| Capa | Qué comprueba | Qué error detecta |
|---|---|---|
| Juego de caracteres | Que solo aparezcan los símbolos admitidos | Letras donde van cifras, símbolos pegados |
| Longitud | Que la cadena tenga las posiciones previstas | Un carácter perdido, un carácter añadido |
| Dígito verificador | Que el último carácter se pueda recalcular desde los demás | Cambios de un carácter y transposiciones |
Las dos primeras capas son baratas: no necesitan ningún cálculo, basta con recorrer la cadena una vez y contar. La tercera exige aplicar una fórmula y comparar el resultado con el carácter final, y por eso es la que más discusiones genera cuando se diseña un formulario.
El orden importa tanto como las capas. Si se calcula el dígito verificador antes de limpiar la entrada, cualquier separador produce un resultado erróneo y el sistema culpa al usuario de un fallo que es suyo. La secuencia correcta es siempre la misma: normalizar, comprobar el juego de caracteres, comprobar la longitud y, solo al final, calcular el dígito.
¿Por qué un formato correcto no significa que el número sea real?
Porque las reglas públicas describen la estructura, no el registro. Cualquiera puede construir una cadena que cumpla la fórmula sin que corresponda a nada: basta con elegir los primeros caracteres y dejar que la fórmula determine el último. Lo que se obtiene es un número perfectamente coherente consigo mismo y, con toda probabilidad, inexistente.
Esa distancia tiene consecuencias directas en la interfaz. Un mensaje que afirma que el número es correcto cuando en realidad solo se ha comprobado la fórmula promete más de lo que sabe, y esa promesa se rompe la primera vez que alguien la pone a prueba. El texto honesto describe lo comprobado: la forma coincide y el dígito verificador se cumple.
Si además hace falta saber si el número figura en algún registro, eso es una consulta distinta, más lenta y dependiente de terceros. La guía sobre validación en la API trata ese reparto con detalle.
Un mismo número puede pertenecer a varios esquemas
Una cadena corta de dígitos no lleva adosado el nombre del país que la emitió. Dos esquemas distintos pueden compartir longitud y juego de caracteres, y entonces la misma entrada satisface las reglas de ambos. Ninguna de las dos lecturas es falsa: son dos afirmaciones simultáneamente verdaderas sobre un texto ambiguo.
La consecuencia de diseño es clara: conviene enumerar los esquemas candidatos en lugar de elegir uno en silencio. Un validador que adivina el país del usuario acierta a veces y falla sin avisar el resto de las veces, y el error resulta invisible precisamente porque la interfaz nunca muestra que hubo una elección.
La normalización: espacios, guiones y mayúsculas
Antes de comprobar nada hay que reducir la entrada a su forma canónica. Los espacios, los guiones, los puntos y las barras son separadores de presentación; las letras pueden llegar en mayúsculas o en minúsculas, y a veces aparecen caracteres de ancho completo copiados desde una hoja de cálculo. Todo eso se elimina o se unifica antes de la primera comprobación.
Sin esa limpieza, el mismo número escrito de dos maneras se trata como dos entradas diferentes, aparecen duplicados en los informes y las comparaciones fallan por motivos que no tienen nada que ver con el contenido. Hay que subrayar que la normalización no arregla errores de tecleo ni es una medida de seguridad: solo hace comparable lo que ya era igual.
Para quien programa: cómo repartir la comprobación en capas
Al trasladar estas ideas al código aparecen decisiones que se repiten en casi todos los proyectos.
- Limpiar una sola vez y guardar el resultado normalizado, en lugar de repetir la limpieza en cada paso posterior.
- Separar la comprobación de forma de la consulta de existencia, con nombres distintos en el código y en los mensajes.
- Devolver un estado con varias posibilidades, no un valor de sí o no, para poder distinguir solo formato de no válido.
- Conservar el valor original junto al normalizado: el primero sirve para atender a la persona, el segundo para comparar.
- No incrustar reglas de país en la lógica de negocio; trátalas como datos que se pueden actualizar por separado.
La razón de fondo es que las reglas cambian. Un esquema puede revisar su estructura o publicar un algoritmo que antes no existía, y el sistema debería absorber ese cambio sin reescribir el flujo entero que lo utiliza.
Siguientes pasos
Reúne tres o cuatro números de ejemplo, inventados y nunca reales, que representen los casos que manejas a diario: uno bien formado, uno con el último carácter alterado, uno de longitud equivocada y uno sin algoritmo publicado. Pásalos por el validador de números y observa qué conclusión devuelve para cada uno.
Si quieres entender antes cómo se genera ese último carácter, la guía sobre algoritmos de dígito verificador describe la familia completa y los criterios para elegir entre sus miembros.
Aviso sobre los ejemplos: las cadenas que aparecen en este artículo se construyeron únicamente para explicar las tres capas de la comprobación, no corresponden a ninguna persona, empresa, cuenta ni documento existente, y no acreditan autenticidad ni sirven para superar una verificación real.