🔍 Generador de Regex para Telefonos (30+ Paises)
Genera al instante regex de validacion para numeros de telefono de 30+ paises. Cuatro variantes (E.164 / Internacional / Flexible / Movil), combinacion OR multipais, probador en vivo y snippets listos para pegar en JavaScript, PHP, Python, Ruby y Go. Ideal para validacion de formularios, extraccion de logs y limpieza de datos.
🔒 Sobre la privacidad
- ・Todo se procesa en tu navegador (JavaScript)
- ・Los numeros nunca se envian a un servidor
📝 Regex generado
/^.+$/g
🧪 Probador en vivo
💻 Snippets por lenguaje
📖 Dónde se suele tropezar
Genera patrones de validacion de numeros de telefono para mas de treinta paises, en cuatro variantes (E.164, internacional, flexible y solo movil), con combinacion OR entre paises, un probador en vivo y fragmentos para JavaScript, PHP, Python, Ruby y Go. Todo se ejecuta en el navegador. Ahora bien, lo unico que puede decidir una expresion regular es si la forma parece un numero: no puede decirte si ese numero existe, si sigue en servicio ni si puede recibir un SMS. Y los planes de numeracion cambian: que se asigne un nuevo digito inicial y un patron correcto ayer empieza hoy a rechazar numeros reales.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| Un patron demasiado estricto rechaza numeros reales | Los planes de numeracion los gestiona el regulador de cada pais y cambian cada pocos anos: se anaden digitos iniciales nuevos para movil, se dividen prefijos provinciales, se crean rangos para servicios nuevos. Un patron que enumere digitos iniciales con detalle es exacto en el momento en que se escribe y con el tiempo empieza a rechazar numeros reales. Y por la portabilidad numerica, la inferencia de que cierto prefijo significa movil y por tanto admite SMS ya no se sostiene: la correspondencia entre rango y operadora no es fija. Mientras tanto, el usuario rechazado se marcha sin saber por que: quien tiene un numero perfectamente valido y lee que es invalido no dispone de ninguna jugada. | Usa el patron solo para rechazar entradas obviamente erroneas. En concreto, limitate a una longitud minima y maxima, el conjunto de caracteres permitido y un prefijo de pais plausible: enumerar los tres primeros digitos es mas seguro dejarlo sin escribir, salvo que estes dispuesto a mantenerlo. Donde importa la exactitud (verificacion por SMS, comprobacion de identidad, facturacion), usa una biblioteca mantenida: libphonenumber sigue de forma continua los planes nacionales de numeracion, y no hay razon para asumir tu ese trabajo. La unica forma de establecer que un numero es realmente alcanzable es enviarle algo: en cuanto mandas un codigo de verificacion por SMS, la precision de tu expresion regular deja de importar para el resultado final. |
| Validar antes de normalizar | La gente escribe el mismo numero de muchas maneras: con y sin guiones, separado por espacios, entre parentesis, con y sin prefijo de pais, con y sin cero inicial, y con digitos de ancho completo. Al copiar de la agenda de un movil, pueden colarse ademas caracteres de control invisibles y espacios poco habituales. Pasa la cadena en bruto por el patron y todo eso resulta invalido, y quien lo escribio no puede ver que hay de distinto (los digitos de ancho completo y medio solo se diferencian en anchura en muchas tipografias). El otro caso incomodo es el cero inicial en formato nacional frente a internacional: en muchos paises el numero lleva un 0 inicial dentro del pais y lo pierde al anteponer el prefijo internacional. Si quieres aceptar ambos, no queda mas remedio que convertir a una sola forma antes de comparar. |
Fija el orden: normalizar, validar, guardar. Para normalizar: convierte el ancho completo a ancho medio (ver el conversor de anchura) y elimina todo salvo los digitos y un + inicial: solo con eso se absorbe la mayor parte de la variacion anterior. Valida contra la cadena normalizada y guarda en forma E.164, es decir + seguido del prefijo de pais y solo digitos: en esa forma, la comparacion, la deteccion de duplicados y el envio internacional funcionan directamente. Da formato local unicamente al mostrarlo. Y permite guiones y espacios en el campo de entrada: pedir al usuario que escriba solo digitos es endosarle a el el trabajo de normalizar. |
| El patron se comporta distinto en cada motor | El probador de aqui corre sobre el motor de JavaScript, de modo que un patron que pase aqui no tiene por que comportarse igual donde lo pegues. Destacan tres diferencias. El paquete regexp de Go es RE2, asi que no dispone de anticipacion ((?=...)) ni de retrorreferencias: un patron que las contenga falla al compilar. preg_match de PHP exige delimitadores; sin envolverlo en /.../ avisa y no casa con nada. Las anclas tambien varian: $ en muchos motores casa tambien justo antes de un salto de linea final, de modo que una entrada con el numero seguido de un salto de linea y mas texto puede colarse (en JavaScript y Python necesitas \z o \Z, o eliminar antes los saltos de linea). |
Ejecuta siempre el patron generado al menos una vez en el lenguaje que vas a usar de verdad. Go en particular no se porta mal: falla al arrancar, de modo que sin una prueba te enteras en produccion. Prepara tres clases de caso de prueba: numeros validos que deben pasar, entradas obviamente erroneas que deben rechazarse y los limites (el mas corto, el mas largo, con y sin prefijo de pais). Incluir la entrada que debe rechazarse es lo esencial: si solo pruebas el camino feliz, un patron roto que lo acepta todo tambien saldra en verde. Y no incrustes el patron en el codigo: dale un nombre y guardalo en un unico sitio, para que cuando cambie el plan de numeracion haya un solo lugar que arreglar. |
Cuanta severidad aplicar se deduce de para que sirve el numero. En un campo opcional de un formulario de contacto, una validacion estricta solo reduce el numero de consultas: si no se te puede localizar, quien sale perdiendo es quien lo escribio, y no necesitas juzgar en su lugar. A la inversa, para una verificacion por SMS o un contacto de reparto, no poder enviar es un fallo operativo inmediato, asi que incorpora al proceso la comprobacion real de alcance (el envio de un codigo) en lugar de fiarlo a la validacion de formato. Tratar ambos casos con la misma severidad es el error de diseno mas frecuente. Ademas, un numero de telefono es un dato personal: no lo escribas en los registros, no lo incluyas en los mensajes de error y no lo pases a la analitica como parametro de URL. Los disenos que envian el valor a medio escribir a una API de validacion en tiempo real merecen especial cuidado. Y evita mostrar unicamente la palabra invalido: indica cuantos digitos se esperan y si hace falta el prefijo de pais, y muestra un ejemplo; la mayoria de los errores de escritura se resuelven solos alli mismo.
📖 Cómo usar
-
1
Elige paisesElige uno o varios paises; el patron usara OR.
-
2
Elige varianteElige entre E.164, internacional, flexible o solo movil.
-
3
Copia o pruebaCopia con un clic; pega numeros para probar.
-
4
Pega en tu lenguajeSnippets listos para JS/PHP/Python/Ruby/Go/Java.
❓ Preguntas frecuentes
Por que no usan libphonenumber?
Diferencia internacional vs E.164?
Puedo combinar varios paises?
Es perfecto el regex?
🔗 Herramientas relacionadas
- ・Formateador de Telefono — Convertir a Internacional / E.164
- ・Tester de Regex — Test en vivo de regex JS
- ・Validador de Correos — RFC 5322, desechables, roles
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.