Necesito validar un nombre de dominio:
google.com
stackoverflow.com
Entonces, un dominio en su forma más cruda, ni siquiera un subdominio como www.
- Los caracteres solo deben ser az | AZ | 0-9 y punto (.) Y guión (-)
- La parte del nombre de dominio no debe comenzar ni terminar con un guión (-) (por ejemplo, -google-.com)
- La parte del nombre de dominio debe tener entre 1 y 63 caracteres
La extensión (TLD) puede ser cualquier cosa bajo las reglas n. ° 1 por ahora, puedo validarlas con una lista más adelante, aunque debería tener 1 o más caracteres
Editar: TLD aparentemente tiene 2-6 caracteres tal como está
No. 4 revisado: TLD en realidad debería estar etiquetado como "subdominio", ya que debería incluir cosas como .co.uk - Me imagino que la única validación posible (aparte de verificar una lista) sería 'después del primer punto debería haber uno o más personajes bajo las reglas # 1
Muchas gracias, créanme que lo intenté!
regex
validation
domain-name
Dominic
fuente
fuente
Respuestas:
Bueno, es
bastante sencillo,un poco más astuto de lo que parece (ver comentarios), dados sus requisitos específicos:Pero tenga en cuenta que esto rechazará muchos dominios válidos.
fuente
g.co
es un nombre de dominio válido perog
solo tiene un carácter./^[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.[a-zA-Z]{2,}$/
. Pero esto aún rechaza toneladas de cosas válidas ...Sé que esta es una publicación un poco antigua, pero a todas las expresiones regulares aquí les falta un componente muy importante: el soporte para nombres de dominio IDN.
Los nombres de dominio IDN comienzan con xn--. Permiten caracteres UTF-8 extendidos en nombres de dominio. Por ejemplo, ¿sabía que "♡ .com" es un nombre de dominio válido? ¡Sí, "love heart dot com"! Para validar el nombre de dominio, debe dejar que http://xn--c6h.com/ pase la validación.
Tenga en cuenta que para usar esta expresión regular, deberá convertir el dominio a minúsculas y también usar una biblioteca IDN para asegurarse de codificar los nombres de dominio en ACE (también conocido como "Codificación compatible con ASCII"). Una buena biblioteca es GNU-Libidn.
idn (1) es la interfaz de línea de comandos para la biblioteca de nombres de dominio internacionalizados. El siguiente ejemplo convierte el nombre de host en UTF-8 en codificación ACE. La URL resultante https: //nic.xn--flw351e/ se puede utilizar como equivalente codificado en ACE de https: // nic. 谷 歌 / .
Esta expresión regular mágica debería cubrir la mayoría de los dominios (aunque estoy seguro de que hay muchos casos extremos válidos que me he perdido):
Al elegir una expresión regular de validación de dominio, debería ver si el dominio coincide con lo siguiente:
Si estos tres dominios no pasan, es posible que su expresión regular no permita dominios legítimos.
Revisa página de Soporte de nombres de dominio internacionalizados de la Guía del entorno de idiomas internacionales de Oracle para obtener más información.
No dude en probar la expresión regular aquí: http://www.regexr.com/3abjr
ICANN mantiene una lista de tlds que se han delegado que se puede utilizar para ver algunos ejemplos de dominios IDN.
Editar:
Esta expresión regular detendrá los dominios que tienen '-' al final de un nombre de host como marcados como válidos. Además, permite subdominios ilimitados.
fuente
/^((?!-))(xn--)?[a-z0-9][a-z0-9-_]{0,61}[a-z0-9]{0,}\.?((xn--)?([a-z0-9\-.]{1,61}|[a-z0-9-]{1,30})\.?[a-z]{2,})$/i
to.
( to. ) Es una URL válida con contenido.to.
no es un nombre de dominio completamente calificado. Si desea permitir dominios de nivel superior, debe usar algo como^(((?!-))(xn--)?[a-z0-9][a-z0-9-_]{0,61}[a-z0-9]{0,1}\.)?(x--)?([a-z0-9\-]{1,61}|[a-z0-9-]{1,30}\.[a-z]{2,})\.?$
, pero tenga cuidado, ¡dejará pasar a las personas que ingresen dominios comotest
ona
también!invali.d
como un nombre de dominio válido mientrasinvali.d.co.uk
no sea válido.xn--stackoverflow.com
no es un nombre válido ya que 'stackoverflow' no se puede convertir de Punycode. Sin embargo, eso está más allá de lo que puede hacer una expresión regular. Como observación general, lasxn--[a-z0-9]+
etiquetas serían solo IDN mientras quexn--[a-z0-9]+\-[a-z0-9]+
indican una combinación de caracteres ASCII y no ASCIIMi expresión regular es la siguiente:
^[a-zA-Z0-9][a-zA-Z0-9-_]{0,61}[a-zA-Z0-9]{0,1}\.([a-zA-Z]{1,6}|[a-zA-Z0-9-]{1,30}\.[a-zA-Z]{2,3})$
está bien para i.oh1.me y para wow.british-library.uk
UPD
Aquí está la regla actualizada
https://www.debuggex.com/r/y4Xe_hDVO11bv1DV
ahora es comprobar si hay
-
o_
en el inicio o al final de la etiqueta de dominio.fuente
{2,6}
criterios deberán actualizarse para el nuevo TLD. Probablemente{2,}
.Mi apuesta:
Explicado:
El nombre de dominio se crea a partir de segmentos. Aquí hay un segmento (excepto el final):
Puede tener de 1 a 63 caracteres, no comienza ni termina con '-'.
Ahora agregue '.' y repetir al menos una vez:
Luego adjunte el segmento final, que tiene entre 2 y 63 caracteres:
Pruébelo aquí: http://regexr.com/3au3g
fuente
Solo una pequeña corrección: la última parte debe ser hasta 6. Por lo tanto,
El TLD más largo es
museum
(6 caracteres): http://en.wikipedia.org/wiki/List_of_Internet_top-level_domainsfuente
.photography
available
tlds actuales no es una prueba para el futuro.{2,63}
: consulte stackoverflow.com/questions/9238640/…La respuesta aceptada no funciona para mí, intente esto:
Visite los casos de prueba de esta unidad para su validación.
fuente
{2,6}
por otro y funcionará. Mío:^((?!-)[a-zA-Z0-9-]{1,63}(?<!-)\.)+(?!-)[a-zA-Z0-9-]{1,63}(?<!-)$
^((?!-)[a-zA-Z0-9-]{1,63}(?<!-)\.)+(?!-)[a-zA-Z0-9-]{1,63}(?<!-)$
Esta respuesta es para nombres de dominio (incluidos RR de servicio), no nombres de host (como un nombre de host de correo electrónico).
Básicamente es la respuesta de mkyong y, además:
Por partes
Lookahead, limite la longitud máxima entre ^ $ a 253 caracteres con el literal final opcional '.'
Mirando hacia adelante, el siguiente carácter no es un '-' y ningún '_' sigue a ningún carácter antes del siguiente '.'. Es decir, imponga que el primer carácter de una etiqueta no sea un '-' y solo el primer carácter puede ser un '_'.
Entre 1 y 63 de los caracteres permitidos por etiqueta.
Mirar hacia atrás, el carácter anterior no es '-'. Es decir, imponga que el último carácter de una etiqueta no sea un '-'.
Forzar un '.' al final de cada etiqueta excepto la última, donde es opcional.
Principalmente combinado desde arriba, esto requiere al menos dos niveles de dominio, lo cual no es del todo correcto, pero generalmente es una suposición razonable. Cambie de {2,} a + si desea permitir TLD o subdominios relativos no calificados a través (por ejemplo, localhost, myrouter, to.)
Pruebas unitarias para esta expresión.
fuente
Gracias por señalar la dirección correcta en las soluciones de validación de nombres de dominio en otras respuestas. Los nombres de dominio se pueden validar de varias formas.
Si necesita validar el dominio IDN en su forma legible por humanos , regex
\p{L}
lo ayudará. Esto permite hacer coincidir cualquier carácter en cualquier idioma.Tenga en cuenta que la última parte también puede contener guiones . Como los nombres chinos codificados con punycode pueden tener caracteres Unicode en tld.
He llegado a una solución que coincidirá, por ejemplo:
Regex es:
Compruebe y sintonice aquí
NOTA: Esta expresión regular es bastante permisiva, al igual que el conjunto de caracteres permitido para los nombres de dominio actuales.
ACTUALIZACIÓN : aún más simplificado, ya que
a-aA-Z\p{L}
es igual que\p{L}
NOTA 2: El único problema es que coincidirá con los dominios con puntos dobles ..., como
masełk..owski.pl
. Si alguien sabe cómo solucionar este problema, mejore.fuente
[:alpha:]
y en[:digit]
lugar de\p{L}
. Funciona bien.中国互联网络信息中心中国互联网络信息中心中国互联网络信.中国
verifica como válido, pero después de la conversión de IDN, son demasiados bytes por etiqueta. \ p {L} coincide con símbolos, no con bytes de código pequeño (que varían de un símbolo a otro), por lo que el conteo repetido no es útil cuando se trata de limitar su tamaño posterior a la conversión.[dominio - letras minúsculas y solo 0-9] [puede tener un guión] + [TLD - solo minúsculas, debe tener entre 2 y 7 letras]
http://rubular.com/ ¡ es genial para probar expresiones regulares!
Editar: TLD actualizado como máximo a 7 caracteres para '.rentals' como señaló Dan Caddigan.
fuente
.photography
sería inválido. Simplemente conviértalo en caracteres ilimitados o algo así.Aún no hay suficiente representante para comentar. En respuesta a la solución de paka, descubrí que necesitaba ajustar tres elementos:
Antes de:
Después:
fuente
Para nuevos gTLD
fuente
Como ya se señaló, no es obvio decir subdominios en el sentido práctico (por ejemplo,
.co.uk
dominios). Usamos esta expresión regular para validar dominios que ocurren en la naturaleza. Cubre todos los casos de uso práctico que conozco. Los nuevos son bienvenidos. De acuerdo con nuestras pautas , evita los grupos que no capturan y las coincidencias codiciosas.^(?!.*?_.*?)(?!(?:[\d\w]+?\.)?\-[\w\d\.\-]*?)(?![\w\d]+?\-\.(?:[\d\w\.\-]+?))(?=[\w\d])(?=[\w\d\.\-]*?\.+[\w\d\.\-]*?)(?![\w\d\.\-]{254})(?!(?:\.?[\w\d\-\.]*?[\w\d\-]{64,}\.)+?)[\w\d\.\-]+?(?<![\w\d\-\.]*?\.[\d]+?)(?<=[\w\d\-]{2,})(?<![\w\d\-]{25})$
Prueba, explicación y ejemplos: https://regex101.com/r/FLA9Bv/9 ( Nota: actualmente solo funciona en Chrome porque la expresión regular usa lookbehinds que solo son compatibles con ECMA2018 )
Hay dos enfoques para elegir al validar dominios.
Coincidencia de FQDN según los libros (definición teórica, rara vez encontrada en la práctica):
Coincidencia de FQDN práctica / conservadora (definición práctica, esperada y respaldada en la práctica):
[a-zA-Z0-9.-]
fuente
fuente
Aquí hay un código completo con un ejemplo:
fuente
Gracias @mkyong por la base de mi respuesta. Lo modifiqué para admitir etiquetas aceptables más largas.
Además, "localhost" es técnicamente un nombre de dominio válido. Modificaré esta respuesta para dar cabida a los nombres de dominio internacionalizados.
fuente
([a-zA-Z]{1,2})
-> por aceptar solo dos caracteres.([0-9]{1,2})
-> para aceptar solo dos númerossi algo excede más de dos,
([a-zA-Z0-9][a-zA-Z0-9-]{1,61}[a-zA-Z0-9])
esta expresión regular se encargará de eso.Si queremos hacer el emparejamiento durante al menos una vez
+
se utilizará.fuente
Ejemplos que funcionan:
También funcionará para extensiones
Ejemplos que no funcionarán:
funcionará incluso con la extensión de dominio más larga
".versicherung"
fuente
^((?!-))(xn--)?[a-z0-9][a-z0-9-_]{0,61}[a-z0-9]{0,}\.?((xn--)?([a-z0-9\-.]{1,61}|[a-z0-9-]{0,30})\.[a-z-1-9]{2,})$
validará dichos dominios
яндекс.рф
después de la codificación.https://regex101.com/r/Hf8wFM/1 - zona de pruebas
fuente
La siguiente expresión regular extrae el sub, root y tld de un dominio dado:
Probado para los siguientes dominios:
fuente
Hice lo siguiente para recuperar el dominio junto con el protocolo. Ejemplo: https://www.facebook.com/profile/user/ ftp://182.282.34.337/movies/M
utilice el siguiente patrón Regex: [a-zA-Z0-9] +: //.*? /
obtendrá el resultado: https://www.facebook.com/ ftp://192.282.34.337/
fuente