Qu'est-ce qu'une expression régulière qui correspond à un nom de domaine valide sans sous-domaine?


123

J'ai besoin de valider un nom de domaine:

google.com

stackoverflow.com

Donc, un domaine dans sa forme la plus brute - pas même un sous-domaine comme www.

  1. Les caractères ne doivent être que az | AZ | 0-9 et point (.) Et tiret (-)
  2. La partie du nom de domaine ne doit pas commencer ou se terminer par un tiret (-) (par exemple -google-.com)
  3. La partie du nom de domaine doit comporter entre 1 et 63 caractères
  4. L'extension (TLD) peut être n'importe quoi sous les règles n ° 1 pour le moment, je peux les valider par rapport à une liste plus tard, cela devrait contenir 1 ou plusieurs caractères

Edit: TLD est apparemment 2-6 caractères tel qu'il est

non. 4 révisé: le TLD devrait en fait être étiqueté "sous-domaine" car il devrait inclure des éléments comme .co.uk - j'imagine que la seule validation possible (à part la vérification par rapport à une liste) serait 'après le premier point, il devrait y en avoir un ou plus de personnages selon les règles n ° 1

Merci beaucoup, croyez-moi, j'ai essayé!


1
Peut-être pas du tout utile. En ce qui concerne google.co.uk et certains domaines japonais, je suis sûr que vous devrez réfléchir à deux fois avant d'utiliser regex pour cela. Ma pensée personnelle est que l'expression régulière n'est pas suffisante pour valider un domaine dans un domaine réel. Pour info, voici une liste presque complète des noms de domaine de deuxième niveau de tld et de code de pays: static.ayesh.me/misc/SO/tlds.txt
Ayesh K

1
Voir ma réponse à la question relative à la validation du nom d' hôte .
SAM

2
Souvent oublié: pour les noms de domaine complets, vous devez faire correspondre un point après le tld.
schmijos

1
cela fait 4 ans, maintenant le nombre est de
89000

1
Certaines de ces réponses sont plutôt bonnes, mais il y a aussi une autre bonne réponse à cette autre question qui vaut le coup d'œil.
craftworkgames

Réponses:


49

Eh bien, c'est assez simple un peu plus sournois qu'il n'y paraît (voir les commentaires), compte tenu de vos besoins spécifiques:

/^[a-zA-Z0-9][a-zA-Z0-9-]{1,61}[a-zA-Z0-9]\.[a-zA-Z]{2,}$/

Mais notez que cela rejettera un grand nombre de domaines valides.


Bien merci, celui-ci semble fonctionner. Quels types de domaines ne passeront pas la validation savez-vous?
Dominic

12
@infensus - Bien que cette expression régulière soit correcte compte tenu de vos spécifications, vos spécifications sont fausses. g.coest un nom de domaine valide mais gne comporte qu'un seul caractère.
sch

3
Cela devrait correspondre à tous les cas que je pense: ^ ([a-z0-9]) (([a-z0-9 -] {1,61})? [A-z0-9] {1})? (\. [a-z0-9] (([a-z0-9 -] {1,61})? [a-z0-9] {1})?)? (\. [a-zA-Z] {2 , 4}) + $
transilvlad

1
x.com ne passerait pas ici
Neil McGuigan

4
@Neil: Vous avez raison. La question d'origine demandait 3-63 caractères (voir modifier 3). Il peut être modifié pour supporter assez facilement les domaines d' un caractère: /^[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?\.[a-zA-Z]{2,}$/. Mais cela rejette toujours des tonnes de trucs valides ...
Cameron

85

Je sais que c'est un peu un vieux post, mais il manque à toutes les expressions régulières ici un élément très important: le support des noms de domaine IDN.

Les noms de domaine IDN commencent par xn--. Ils activent les caractères UTF-8 étendus dans les noms de domaine. Par exemple, saviez-vous que «♡ .com» est un nom de domaine valide? Ouais, "love heart dot com"! Pour valider le nom de domaine, vous devez laisser http://xn--c6h.com/ passer la validation.

Notez que pour utiliser cette expression régulière, vous devrez convertir le domaine en minuscules et également utiliser une bibliothèque IDN pour vous assurer d'encoder les noms de domaine en ACE (également connu sous le nom de «codage compatible ASCII»). Une bonne bibliothèque est GNU-Libidn.

idn (1) est l'interface de ligne de commande vers la bibliothèque de noms de domaine internationalisée. L'exemple suivant convertit le nom d'hôte en UTF-8 en encodage ACE. L'URL résultante https: //nic.xn--flw351e/ peut ensuite être utilisée comme équivalent codé ACE de https: // nic. 谷 歌 / .

  $ idn --quiet -a nic.谷歌
  nic.xn--flw351e

Cette expression régulière magique devrait couvrir la plupart des domaines (même si je suis sûr qu'il existe de nombreux cas limites valides que j'ai manqués):

^((?!-))(xn--)?[a-z0-9][a-z0-9-_]{0,61}[a-z0-9]{0,1}\.(xn--)?([a-z0-9\-]{1,61}|[a-z0-9-]{1,30}\.[a-z]{2,})$

Lorsque vous choisissez une expression régulière de validation de domaine, vous devriez voir si le domaine correspond à ce qui suit:

  1. xn--stackoverflow.com
  2. stackoverflow.xn - com
  3. stackoverflow.co.uk

Si ces trois domaines ne passent pas, votre expression régulière n'autorise peut-être pas les domaines légitimes!

Consultez la page de prise en charge des noms de domaine internationalisés du guide Oracle's International Language Environment Guide pour plus d'informations.

N'hésitez pas à essayer la regex ici: http://www.regexr.com/3abjr

L'ICANN conserve une liste des noms de domaine qui ont été délégués et qui peut être utilisée pour voir quelques exemples de domaines IDN.


Éditer:

 ^(((?!-))(xn--|_{1,1})?[a-z0-9-]{0,61}[a-z0-9]{1,1}\.)*(xn--)?([a-z0-9][a-z0-9\-]{0,60}|[a-z0-9-]{1,30}\.[a-z]{2,})$

Cette expression régulière arrêtera les domaines qui ont «-» à la fin d'un nom d'hôte comme étant marqués comme valides. De plus, il autorise un nombre illimité de sous-domaines.


1
Notez que cela ne prendra en charge qu'un sous-domaine maximum, tout ce qui aura pour résultat faux. Ce n'est pas quelque chose que vous devez rencontrer à moins de l'utiliser pour des sites internes, etc ... Une tentative rapide pour lui permettre de prendre en charge plus de sous-domaines:/^((?!-))(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
stakolee

1
Mais les tld solitaires ne fonctionnent pas: (Par exemple to.( to. ) Est une URL valide avec le contenu.
iiic

@iiic, oui, mais ce to.n'est pas un nom de domaine complet. Si vous souhaitez autoriser les domaines de premier niveau, vous devez utiliser quelque chose comme ^(((?!-))(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,})\.?$, mais soyez averti, vous laisserez passer les personnes qui mettent des domaines comme testou na, aussi!
Tim Groeneveld

Il accepte invali.dcomme nom de domaine valide tant qu'il invali.d.co.ukn'est pas valide.
Pawel Krakowiak

1
Il convient de noter que ce xn--stackoverflow.comn'est pas un nom valide car 'stackoverflow' ne peut pas être converti à partir de Punycode. C'est cependant au-delà de ce qu'une regex peut faire. Comme remarque générale, les xn--[a-z0-9]+étiquettes seraient uniquement IDN alors xn--[a-z0-9]+\-[a-z0-9]+qu'elles indiqueraient un mélange de caractères ASCII et non ASCII
Marcus

50

Mon RegEx est le suivant:

^[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})$

c'est bon pour i.oh1.me et pour wow.british-library.uk

UPD

Voici la règle mise à jour

^(([a-zA-Z]{1})|([a-zA-Z]{1}[a-zA-Z]{1})|([a-zA-Z]{1}[0-9]{1})|([0-9]{1}[a-zA-Z]{1})|([a-zA-Z0-9][a-zA-Z0-9-_]{1,61}[a-zA-Z0-9]))\.([a-zA-Z]{2,6}|[a-zA-Z0-9-]{2,30}\.[a-zA-Z]{2,3})$

Visualisation des expressions régulières

https://www.debuggex.com/r/y4Xe_hDVO11bv1DV

maintenant, il vérifie -ou _au début ou à la fin de l'étiquette de domaine.


9
Cela semble assez bon, mais les {2,6}critères devront être mis à jour pour le nouveau TLD. Probablement {2,}.
jwatts1980

@ jwatts1980 existe-t-il des exemples de telles zones? ou vous voulez dire pour d'éventuelles zones futures?
paka

1
Voici un article sur les changements à venir avec des exemples et des liens vers des ressources connexes: zdnet.com
...

1
Pourquoi ([a-zA-Z] {1} [a-zA-Z] {1}) et non ([a-zA-Z] {2})?
Anton

3
la dernière partie avec les deux alternatives est également erronée: il existe des ccTLD (deux lettres) qui acceptent les sous-étiquettes IDNA. Il existe également maintenant des étiquettes de TLD utilisant déjà des étiquettes IDNA. Vous ne devriez pas cas particulier la dernière étiquette qui n'est pas différente des autres (et a maintenant de nombreuses extensions ajoutées avec des longueurs variables, jsut comme toutes les autres étiquettes dans les sous-domaines. Notez que les étiquettes IDNA peuvent également apparaître punycodées (dans ce cas, il y aura "- - "un segment dans l'étiquette, le seul cas où" - "est autorisé dans les étiquettes .. Enfin, le trait de soulignement est invalide partout dans toutes les étiquettes.
verdy_p

24

Mon pari:

^(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.)+[a-z0-9][a-z0-9-]{0,61}[a-z0-9]$

Expliqué:

Le nom de domaine est construit à partir de segments. Voici un segment (sauf final):

[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?

Il peut contenir de 1 à 63 caractères, ne commence ni ne se termine par «-».

Maintenant, ajoutez "." et répétez au moins une fois:

(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.)+

Ensuite, attachez le dernier segment, qui comprend 2 à 63 caractères:

[a-z0-9][a-z0-9-]{0,61}[a-z0-9]

Testez-le ici: http://regexr.com/3au3g


@GaneshBabu Qu'entendez-vous par correspondances exactes?
Yaroslav Stavnichiy

1
Toutes les autres réponses n'ont pas fonctionné pour moi, mais celle-ci a fonctionné.
Danny Coulombe

J'avais une exigence similaire où je veux éviter le point-virgule et la virgule à la fin J'ai beaucoup essayé mais aucun succès ci-dessous est le Regex que j'utilise const regexDomain = / ^ (?: [A-Za-z0-9] (?: [A-Za-z0-9 -] {0,61} [A-Za-z0-9])? \.) + [A-Za-z0-9] [A-Za-z0-9 -] { 0,61} [A-Za-z0-9] / g; Eh bien, cela valide si j'utilise, et; entre les deux mais échoue à la fin pour vliadate.
Harry

J'ai trouvé plusieurs domaines qui devraient être valides mais qui ne sont pas valides avec votre regex. Par exemple, редбулл.москва est un domaine valide ou aussi редбулл.рф et 红色 的 公牛. 中国
pubkey

1
@pubkey, vous devez convertir ces noms de domaine en punycode . Le nom réel de редбулл.москва est xn - 90afc0aazy.xn - 80adxhks Et mon regex y correspond.
Yaroslav Stavnichiy le

13

Juste une correction mineure - la dernière partie devrait être jusqu'à 6. Par conséquent,

^[a-z0-9]+([\-\.]{1}[a-z0-9]+)*\.[a-z]{2,6}$

Le TLD le plus long est museum(6 caractères) - http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains


3
Remarque: Cela ne transmettra pas le nom de domaine valide (mais rare) www.my---domain.com
Chris Bier

17
Ne le coupe pas avec un nouveau TLD, par exemple.photography
Sam Figueroa

2
@SamFigueroa Il vous suffira d'en modifier la longueur
Steel Brain

3
il ne devrait pas y avoir de vérification pour le TLD, il n'est pas différent des sous-domaines. Et baser le regex sur les availabletld actuels n'est pas une preuve pour l'avenir.
Loïc Faure-Lacroix

1
Suggérer le dernier bit {2,63}: voir stackoverflow.com/questions/9238640/...
Eric Dobbs

13

La réponse acceptée ne fonctionne pas pour moi, essayez ceci:

^ ((?! -) [A-Za-z0-9 -] {1,63} (? <! -) \.) + [A-Za-z] {2,6} $

Visitez ce cas de test unitaire pour validation.


4
pas de support pour les nouveaux noms de TLD plus longs comme .audio, .photography, et la plupart d'entre eux ... data.iana.org/TLD/tlds-alpha-by-domain.txt
mrbinky3000

@ mrbinky3000 Changez simplement le dernier {2,6}en quelque chose d'autre et cela fonctionnera. Mine:^((?!-)[a-zA-Z0-9-]{1,63}(?<!-)\.)+(?!-)[a-zA-Z0-9-]{1,63}(?<!-)$
Mygod

@Mygod votre regex contient des déchets de largeur nulle après le dernier point d'interrogation, donc quiconque la
copiera

1
@MightyPork Vous avez raison! Désolé, voici une version (espérons-le) propre:^((?!-)[a-zA-Z0-9-]{1,63}(?<!-)\.)+(?!-)[a-zA-Z0-9-]{1,63}(?<!-)$
Mygod

Très agréable. Hélas, les expressions lookbehind ne sont pas valides en JavaScript. : /
PhiLho

13

Cette réponse concerne les noms de domaine (y compris les RR de service), pas les noms d'hôte (comme un nom d'hôte de messagerie).

^(?=.{1,253}\.?$)(?:(?!-|[^.]+_)[A-Za-z0-9-_]{1,63}(?<!-)(?:\.|$)){2,}$

C'est essentiellement la réponse de mkyong et en plus:

  • Longueur maximale de 255 octets, y compris les préfixes de longueur et la racine nulle.
  • Autoriser la fin de "." pour la racine DNS explicite.
  • Autoriser '_' de début pour les RR de domaine de service, (bogues: n'applique pas 15 caractères maximum pour les étiquettes _, ni ne nécessite au moins un domaine au-dessus des RR de service)
  • Correspond à tous les TLD possibles.
  • Ne capture pas les étiquettes de sous-domaine.

Par pièces

Lookahead, limite la longueur maximale entre ^ $ et 253 caractères avec le littéral de fin facultatif '.'

(?=.{1,253}\.?$)

Lookahead, le caractère suivant n'est pas un «-» et aucun «_» ne suit les caractères avant le suivant «.». C'est-à-dire que le premier caractère d'une étiquette n'est pas un «-» et que seul le premier caractère peut être un «_».

(?!-|[^.]+_)

Entre 1 et 63 des caractères autorisés par étiquette.

[A-Za-z0-9-_]{1,63}

Regarde derrière, caractère précédent pas «-». C'est-à-dire, assurez-vous que le dernier caractère d'une étiquette n'est pas un «-».

(?<!-)

Forcer un "." à la fin de chaque étiquette sauf la dernière, où elle est facultative.

(?:\.|$)

La plupart du temps combiné par le haut, cela nécessite au moins deux niveaux de domaine, ce qui n'est pas tout à fait correct, mais généralement une hypothèse raisonnable. Passez de {2,} à + si vous souhaitez autoriser les TLD ou les sous-domaines relatifs non qualifiés via (par exemple, localhost, myrouter, to.)

(?:(?!-|[^.]+_)[A-Za-z0-9-_]{1,63}(?<!-)(?:\.|$)){2,}

Tests unitaires pour cette expression.


1
Merci! C'est la meilleure regex ici. Votre explication approfondie et votre test unitaire sont un bonus.
naudster

Que signifie «RR»?
wheeler

Enregistrement des ressources. Habituellement, un champ de texte ou d'information qui vous indique comment interagir avec un service.
Andrew Domaszek

Cette expression régulière n'est pas correcte. Par exemple, le domaine redbull. 移动 est valide mais l'expression régulière ne correspondra pas.
pubkey

Convertissez d'abord en punycode, puis faites correspondre. Les limites de longueur sur la version pré-punycode sont vraiment difficiles à implémenter.
Andrew Domaszek

8

Merci d'avoir indiqué la bonne direction dans les solutions de validation de nom de domaine dans d'autres réponses. Les noms de domaine peuvent être validés de différentes manières.

Si vous devez valider le domaine IDN dans sa forme lisible par l'homme , regex\p{L} aidera. Cela permet de faire correspondre n'importe quel caractère dans n'importe quelle langue.

Notez que la dernière partie peut contenir des traits d'union ! En tant que punycode, les noms chinois peuvent avoir des caractères unicode dans tld.

Je suis venu à une solution qui correspondra par exemple:

  • google.com
  • masełkowski.pl
  • maselkowski.pl
  • m.maselkowski.pl
  • www.masełkowski.pl.com
  • xn--masekowski-d0b.pl
  • 中国 互联 网络 信息 中心. 中国
  • xn - fiqa61au8b7zsevnm8ak20mc4a87e.xn - fiqs8s

Regex est:

^[0-9\p{L}][0-9\p{L}-\.]{1,61}[0-9\p{L}]\.[0-9\p{L}][\p{L}-]*[0-9\p{L}]+$

Vérifiez et réglez ici

REMARQUE: Cette expression rationnelle est assez permissive, tout comme le jeu de caractères actuellement autorisé pour les noms de domaine.

MISE À JOUR : Encore plus simplifié, comme a-aA-Z\p{L}c'est juste\p{L}

NOTE2: Le seul problème est qu'il correspondra aux domaines avec des points doubles ..., comme masełk..owski.pl. Si quelqu'un sait comment résoudre ce problème, veuillez améliorer.


Nous pouvons simplement utiliser [:alpha:]et [:digit]au lieu de \p{L}. Ça fonctionne bien.
puchu

Vous ne pouvez pas valider un IDN de cette façon sans d'abord le convertir en punycode. Par exemple, avec votre expr, 中国互联网络信息中心中国互联网络信息中心中国互联网络信.中国vérifie comme valide, mais après la conversion IDN, il y a trop d'octets par étiquette. \ p {L} correspond à des symboles, pas à des octets de punycode (qui varient d'un symbole à l'autre), donc le nombre de répétitions est inutile lorsque vous essayez de limiter sa taille post-conversion.
Andrew Domaszek

Bon point, chaque partie est limitée à 64 octets. Cependant, nous ne pouvons pas le vérifier avec RegExp, donc des étapes de validation supplémentaires sont nécessaires à l'aide du décodeur punycode - qui échouera avec votre exemple de nom d'hôte. Les Chinois doivent être fous de cette limitation.
PeterM

7
^[a-z0-9]+([\-\.]{1}[a-z0-9]+)*\.[a-z]{2,7}$

[domaine - lettres minuscules et 0-9 uniquement] [peut avoir un trait d'union] + [TLD - minuscules uniquement, doit être compris entre 2 et 7 lettres]
http://rubular.com/ est génial pour tester les expressions régulières!
Edit: mise à jour du TLD maximum à 7 caractères pour «.rentals» comme l'a souligné Dan Caddigan.


1
Pourquoi limiter les TLD? Maintenant .photographyserait invalide. Faites-en un nombre illimité de caractères ou quelque chose comme ça.
adriaan

5

Pas encore assez de représentants pour commenter. En réponse à la solution de paka, j'ai trouvé que je devais ajuster trois éléments:

  • Le tiret et le trait de soulignement ont été déplacés car le tiret a été interprété comme une plage (comme dans "0-9")
  • Ajout d'un arrêt complet pour les noms de domaine avec de nombreux sous-domaines
  • Extension de la longueur potentielle des TLD à 13

Avant:

^(([a-zA-Z]{1})|([a-zA-Z]{1}[a-zA-Z]{1})|([a-zA-Z]{1}[0-9]{1})|([0-9]{1}[a-zA-Z]{1})|([a-zA-Z0-9][a-zA-Z0-9-_]{1,61}[a-zA-Z0-9]))\.([a-zA-Z]{2,6}|[a-zA-Z0-9-]{2,30}\.[a-zA-Z]{2,3})$

Après:

^(([a-zA-Z]{1})|([a-zA-Z]{1}[a-zA-Z]{1})|([a-zA-Z]{1}[0-9]{1})|([0-9]{1}[a-zA-Z]{1})|([a-zA-Z0-9][-_\.a-zA-Z0-9]{1,61}[a-zA-Z0-9]))\.([a-zA-Z]{2,13}|[a-zA-Z0-9-]{2,30}\.[a-zA-Z]{2,3})$

3

Pour les nouveaux gTLD

/^((?!-)[\p{L}\p{N}-]+(?<!-)\.)+[\p{L}\p{N}]{2,}$/iu

2
Veuillez nous donner plus de détails. Ce que vous répondez est meilleur que les autres? À quoi correspondez-vous le plus? Veuillez modifier votre message directement pour ajouter les informations.
Sven R.

Comme je l'ai écrit: les nouveaux gTLD. Domaines avec des caractères Unicode et également des TLD Unicode.
Ben Keil

1
@BenKeil: De quoi parle cette partie: (? <! -)
jor

@jor qui est un regard négatif derrière. Découvrez shortcutfoo.com/app/dojos/regex/cheatsheet
Muhammad Faizan

3

Comme déjà souligné, il n'est pas évident de dire les sous-domaines au sens pratique (par exemple les .co.ukdomaines). Nous utilisons cette expression régulière pour valider les domaines qui se produisent dans la nature. Il couvre tous les cas d'utilisation pratiques que je connais. Les nouveaux sont les bienvenus. Selon nos directives, il évite les groupes non capturants et les correspondances gourmandes.

^(?!.*?_.*?)(?!(?:[\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})$

Preuve, explication et exemples: https://regex101.com/r/FLA9Bv/9 ( Remarque: ne fonctionne actuellement que dans Chrome car l'expression régulière utilise des lookbehinds qui ne sont pris en charge que dans ECMA2018 )

Vous avez le choix entre deux approches lors de la validation des domaines.

Correspondance FQDN par les livres (définition théorique, rarement rencontrée en pratique):

  • max 253 caractères (selon RFC-1035 / 3.1 , RFC-2181/11 )
  • max 63 caractères par étiquette (selon RFC-1035 / 3.1 , RFC-2181/11 )
  • tous les caractères sont autorisés (selon RFC-2181/11 )
  • Les TLD ne peuvent pas être entièrement numériques (selon RFC-3696/2 )
  • Les noms de domaine complets peuvent être écrits sous une forme complète, qui inclut la zone racine (le point final)

Correspondance FQDN pratique / conservatrice (définition pratique, attendue et prise en charge dans la pratique):

  • par les livres correspondant aux exceptions / ajouts suivants
  • caractères valides: [a-zA-Z0-9.-]
  • les étiquettes ne peuvent pas commencer ou se terminer par des tirets (selon RFC-952 et RFC-1123 / 2.1 )
  • La longueur minimale du TLD est de 2 caractères, la longueur maximale est de 24 caractères selon les enregistrements existants
  • ne correspond pas au point final


2

Voici le code complet avec exemple:

<?php
function is_domain($url)
{
    $parse = parse_url($url);
    if (isset($parse['host'])) {
        $domain = $parse['host'];
    } else {
        $domain = $url;
    }

    return preg_match('/^(?!\-)(?:[a-zA-Z\d\-]{0,62}[a-zA-Z\d]\.){1,126}(?!\d+)[a-zA-Z\d]{1,63}$/', $domain);
}

echo is_domain('example.com'); //true
echo is_domain('https://example.com'); //true
echo is_domain('https://.example.com'); //false
echo is_domain('https://localhost'); //false

2
^((localhost)|((?!-)[A-Za-z0-9-]{1,63}(?<!-)\.)+[A-Za-z]{2,253})$

Merci @mkyong pour la base de ma réponse. Je l'ai modifié pour prendre en charge des étiquettes acceptables plus longues.

De plus, "localhost" est techniquement un nom de domaine valide. Je modifierai cette réponse pour accueillir les noms de domaine internationalisés.


0
/^((([a-zA-Z]{1,2})|([0-9]{1,2})|([a-zA-Z0-9]{1,2})|([a-zA-Z0-9][a-zA-Z0-9-]{1,61}[a-zA-Z0-9]))\.)+[a-zA-Z]{2,6}$/
  • ([a-zA-Z]{1,2}) -> pour n'accepter que deux caractères.

  • ([0-9]{1,2})-> pour n'accepter que deux numéros

si quelque chose dépasse au-delà de deux ([a-zA-Z0-9][a-zA-Z0-9-]{1,61}[a-zA-Z0-9])cette regex s'en chargera.

Si nous voulons faire l'appariement pendant au moins une fois +sera utilisé.


0

^ [a-zA-Z0-9] [- a-zA-Z0-9] + [a-zA-Z0-9]. [az] {2,3} (. [az] {2,3}) ? (. [az] {2,3})? $

Exemples qui fonctionnent:

stack.com
sta-ck.com
sta---ck.com
9sta--ck.com
sta--ck9.com
stack99.com
99stack.com
sta99ck.com

Cela fonctionnera également pour les extensions

.com.uk
.co.in
.uk.edu.in

Exemples qui ne fonctionneront pas:

-stack.com

cela fonctionnera même avec la plus longue extension de domaine ".versicherung"



0

L'expression régulière suivante extrait le sous, la racine et le tld d'un domaine donné:

^(?<domain>(?<domain_sub>(?:[^\/\"\]:\.\s\|\-][^\/\"\]:\.\s\|]*?\.)*?)(?<domain_root>[^\/\"\]:\s\.\|\n]+\.(?<domain_tld>(?:xn--)?[\w-]{2,7}(?:\.[a-zA-Z-]{2,3})*)))$

Testé pour les domaines suivants:

* stack.com
* sta-ck.com
* sta---ck.com
* 9sta--ck.com
* sta--ck9.com
* stack99.com
* 99stack.com
* sta99ck.com
* google.com.uk
* google.co.in

* google.com
* masełkowski.pl
* maselkowski.pl
* m.maselkowski.pl
* www.masełkowski.pl.com
* xn--masekowski-d0b.pl
* xn--fiqa61au8b7zsevnm8ak20mc4a87e.xn--fiqs8s

* xn--stackoverflow.com
* stackoverflow.xn--com
* stackoverflow.co.uk

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.