Cygnus a écrit :
Pourquoi la solution serait-elle syntaxiquement correcte mais totalement fausse ? 
Syntaxiquement parlant, dans sa grammaire de programmation si tu veux, la regex est tout à fait correcte car elle suit bien le plan des règles qui défini la manière d'écrire le langage des expressions régulières.
Maintenant je dis qu'elle est fausse et je vais t'expliquer pourquoi.
Vérifier syntaxiquement une adresse email c'est s'assurer qu'elle correspond à schéma établi, respectant la forme :
user@host
expreg a écrit :
La partie composant l'user d'une adresse email, ne doit contenir que des chiffres/lettres ainsi que les caractères tels que l'underscore (_), le tiret (-) ou le point(.)
La partie user doit commencer uniquement par un caractère alphanumérique
Donc c'est parfaitement clair,
une email doit commencer par une lettre/chiffre.
Ta regex :
eregi('^[_a-z0-9-]+(\.[_a-z0-9-]*)*@[a-z0-9-]+(\.[a-z0-9-]+)+$', $email)
On décortique :
1)
'^[_a-z0-9-]+
- avec ce motif, je peux commencer mon email aussi bien par un _ qu'un -
- je peux même en avoir une série genre, _-_-_-_-_ que la regex va accepter à tous les coups.
2)
(\.[_a-z0-9-]*)*
- à partir de ce motif, tout est permis, 200 points si on veut, que des underscores, même de ne rien avoir du tout.
Avec ce genre de motif, tu permet à n'importe qui de donner des emails totalement farfelue du genre :
_---_---_---_.....c.est.con.mais.c.est.bon.comme.email.....@
3)
[a-z0-9-]+
- avec ça, on a un caractère à coup sûr après l'underscore, donc c'est bon comme motif !
Hé bin non, parce que le caractère placé directement derrière un arobase ne pourra jamais être chose qu'un alphanumerique.
Mais ce n'est pas tout, même en enlevant le - ce motif ne sera efficace que si et seulement si, le motif suivant oblige d'avoir aussi un caractère alphanumérique.
Hé oui, un host,
c'est deux caractères minimum (alphanumérique)
On prend ton motif suivant :
4)
(\.[a-z0-9-]+)+
- alors, en suivant ce que je dis plus haut, il faudra accepter avant toute chose un caractère alphanumérique.
Hors ton motif m'autorise à mettre un . suivi de autant de ----- que je veux et le tout répêté autant de foix que je veux :
.------.------.------.-----
Arrivé à ce stade notre adresse finale ressemble à ça :
_---_---_---_.....c.est.con.mais.c.est.bon.comme.email.....@-.-----.----.----.----
Ma question est donc :
Ta regex est-elle efficace dans le parsage de l'adresse email.
La seule contrainte correcte dans le motif de ta regex, c'est l'arobase.
Si tel est le cas, strpos($email,'@') est mille fois plus efficace.
Pour te répondre à propos de strpos(),eregi() ou preg_match().
A quoi ça sert de faire une regex passoire acceptant n'importe quoi ?
Utilises strpos() qui vérifie la présence de @ et puis basta.
Maintenant imagine que tu sois un FAI et que tu souhaite vérifier les débilités qu'un internaute pourrait encoder niveau email.
Ta regex, ne donnera pas l'effet voulu.
Maintenant si tu veux quand même l'utiliser, opte alors pour preg_match() qui est 10 fois plus rapide que eregi().
Voilà, je crois avoir répondu à tes demandes.
========================================================
A Quentin maintenant !
QuentinC a écrit :
Je ne vois pas comment une adresse e-mail pourrait être syntaxiquement formée autrement.
Ta regex :
^[-a-z0-9_\\.]{2,}@[-a-z0-9_]{2,}\\.[a-z]{2,4}$
On décortique :
1)
^[-a-z0-9_\\.]
- Mêmes remarques qu'au point 1 précédent
En prime avec ce motif, on a aussi droit au point, qui n'a absolument aucune raison de se trouver là.
De plus \\. dans la classe ne sert absolument à rien, le métacaractère "dot" perd son statut à l'intérieur d'une classe.
Pourquoi doubler le \ ?
2)
[-a-z0-9_]{2,}
- tu obliges bien d'avoir les 2 caractères minimum requis, ce qui pourrait être valide si on ne pouvait pas y mettre seulement _-
Donc en gros même remarques que point 2 précédent avec le fait qu'ici, les sous-domaines ne sont même pas acceptés.
3)
\\.[a-z]{2,4}$
- pourquoi doubler le \ ?
- rectifier l'intervalle à {2,6} car car des extensions à 6 caractères existent (museum)
Voilà !
Epilogue :
Maintenant le tout est de savoir ce que l'on cherche à faire, chacun étant libre d'employer la forme qu'il préfère et le code qu'il souhaite aussi faux soit-il, le problème n'est pas là.
Le vraie question, c'est de savoir si on laisse l'internaute appréhender le sujet de manière erronée, parce que dans le lot, il y en a peut-être un qui a vraiment envie d'apprendre !
... non, mais ! Ceci dit, c'est pas de refus 
) que je me suis chargée de la correction de ces fautes impardonnables... 
