Filtre d'adresse courriel

Le
Pascale
Oui oui oui, je connais l'adresse de la FAQ (:
Je m'étonne juste d'un truc. J'ai un filtre fait comme ceci :

[]
if (!ereg("([A-Za-z0-9]|-|_|.)*@([A-Za-z0-9]|-|_|.)*.([A-Za-z0-9]|-
|_|.)*",$courriel))
{$err='1';
echo '<p class="erreur">'.$courriel.' n'est pas une adresse courriel
valide</p>';
$courriel="";}

Ce qui m'étonne, c'est que ce filtre laisse passer sans moufter une adresse
comprenant par exemple un é. C'est-y normal ? Comment filtrer les accents ?

--
Pascale
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Olivier Miakinen
Le #42111
Oui oui oui, je connais l'adresse de la FAQ (:
Je m'étonne juste d'un truc. J'ai un filtre fait comme ceci :

[...]
if (!ereg("([A-Za-z0-9]|-|_|.)*@([A-Za-z0-9]|-|_|.)*.([A-Za-z0-9]|-
|_|.)*",$courriel))


Beurk. :-(


Déjà, en continuant à utiliser ereg au lieu de preg et sans changer la
syntaxe de ce qu'il accepte, c'est équivalent à l'écriture plus simple
suivante :

if (!ereg("[A-Za-z0-9_.-]*@[A-Za-z0-9_.-]*.[A-Za-z0-9_.-]*",$courriel))


Et en fait, comme il manque l'ancrage au début (^) et à la fin ($),
c'est même équivalent à :

if (!ereg("@[A-Za-z0-9_.-]*.",$courriel))


Ce qui m'étonne, c'est que ce filtre laisse passer sans moufter une adresse
comprenant par exemple un é. C'est-y normal ?


Oui, c'est normal. Tu demandes juste qu'il y ait quelque part dans la
chaîne un « @ » et un « . » en contrôlant ce qui se trouve entre les
deux, mais tu ne contrôles rien de ce qu'il y a avant ou après.

Ton filtre acceptera ceci : "@é@é@é@e.é@", mais pas cela : "e@é.e".


Comment filtrer les accents ?


En faisant un filtre qui contrôle *toute* la chaîne et pas seulement une
partie. Mais ceux de la FAQ sont quand même meilleurs.

Pascale
Le #42107
Olivier Miakinen news:474e92e1$:

Beurk. :-(


Ben pourquoi ? En plus, vu mon niveau de connaissance des expressions
régulières, c'est sûrement pas moi qui l'ai pondue, celle-ci (-:

Déjà, en continuant à utiliser ereg au lieu de preg et sans changer la
syntaxe de ce qu'il accepte, c'est équivalent à l'écriture plus simple
suivante :


C'est mieux d'utiliser preg ? Pourquoi ?...

if
(!ereg("[A-Za-z0-9_.-]*@[A-Za-z0-9_.-]*.[A-Za-z0-9_.-]*",$courriel))


Et en fait, comme il manque l'ancrage au début (^) et à la fin ($),
c'est même équivalent à :

if (!ereg("@[A-Za-z0-9_.-]*.",$courriel))

Oui, c'est normal. Tu demandes juste qu'il y ait quelque part dans la
chaîne un « @ » et un « . » en contrôlant ce qui se trouve entre les
deux, mais tu ne contrôles rien de ce qu'il y a avant ou après.

Ton filtre acceptera ceci : "@é@é@é@e.é@", mais pas cela : "e@é.e".


Pourquoi ? Le test est le même avant et après l'@, pourquoi les accents
passeraient-ils sur la partie qui précède le @ et seulement là ?
J'avoue que je ne comprends pas du tout...
Pour moi, l'ereg de départ vérifie que l'on a : un ou plusieurs caractères
alpha-numériques (plus quelques autres autorisés), un @, un ou plusieurs
caractères alpha-numériques (et quelques autres), un point et enfin un ou
plusieurs caractères alphanumériques.
Un é, ce n'est pas compris entre a et z, ni entre A et Z ni entre 0 et 9,
donc ???

En faisant un filtre qui contrôle *toute* la chaîne et pas seulement
une partie. Mais ceux de la FAQ sont quand même meilleurs.


C'est vraiment ce que je pensais faire. Pourquoi seul l'@ serait-il pris en
compte dans le test que je fais ?

--
Pascale

Olivier Miakinen
Le #42106
Bonjour,


Beurk. :-(


Ben pourquoi ?


Pour plusieurs raisons, dont certaines que j'ai déjà expliquées, par
exemple la syntaxe compliquée ([A-Za-z0-9]|-|_|.)* au lieu d'écrire
tout simplement [A-Za-z0-9_.-]* mais aussi le fait que le « + » n'est
pas prévu, et donc mon adresse serait refusée si l'auteur de cette
expression n'avait pas oublié d'« ancrer » le test : « ^...$ ».

(-:


Tiens, une gauchère ! (^_^)

Déjà, en continuant à utiliser ereg au lieu de preg et sans changer la
syntaxe de ce qu'il accepte, c'est équivalent à l'écriture plus simple
suivante :


C'est mieux d'utiliser preg ? Pourquoi ?...


Parce qu'elles sont plus puissantes, et en général plus rapides.

Note: preg_match(), qui utilise la syntaxe des expressions rationnelles
compatibles PERL, est une alternative plus rapide de ereg().
</>

[...]

Ton filtre acceptera ceci : "@é@é@é@e.é@", mais pas cela : "e@é.e".


Pourquoi ? Le test est le même avant et après l'@, pourquoi les accents
passeraient-ils sur la partie qui précède le @ et seulement là ?


Le test avant l'@ et après le . sont optionnels. S'il existe un é par
là, alors la chaîne reconnue commencera *après* le é.

J'avoue que je ne comprends pas du tout...
Pour moi, l'ereg de départ vérifie que l'on a : un ou plusieurs caractères
alpha-numériques (plus quelques autres autorisés),


Non pas « un ou plusieurs » mais « zéro, un ou plusieurs ». C'est le +
qui signifie « un ou plusieurs ».

un @, un ou plusieurs
caractères alpha-numériques (et quelques autres), un point et enfin un ou
plusieurs caractères alphanumériques.
Un é, ce n'est pas compris entre a et z, ni entre A et Z ni entre 0 et 9,
donc ???


Je prends quelques exemples, ce sera plus simple pour expliquer.

Regexp = x*@x*
chaîne testée : succès, résultat =
chaîne testée éééé : succès, résultat =
chaîne testée ééé@ééé : succès, résultat = @
chaîne testée ééééééé : échec

Regexp = ^x*@x*$
chaîne testée : succès, résultat =
chaîne testée éééé : échec
chaîne testée ééé@ééé : échec
chaîne testée ééééééé : échec

Regexp = x*@x*.x*
chaîne testée : succès, résultat =
chaîne testée xééx : succès, résultat =
chaîne testée éx.xxx : échec

Regexp = ^x*@x*.x*$
chaîne testée : succès, résultat =
chaîne testée xééx : échec
chaîne testée éx.xxx : échec

En faisant un filtre qui contrôle *toute* la chaîne et pas seulement
une partie. Mais ceux de la FAQ sont quand même meilleurs.


C'est vraiment ce que je pensais faire. Pourquoi seul l'@ serait-il pris en
compte dans le test que je fais ?


Il manquait les méta-caractères ^(ancre sur le début de la chaîne) et $
(ancre sur la fin de la chaîne).


Denis Beauregard
Le #41671
Le 29 Nov 2007 00:57:44 GMT, Pascale écrivait dans fr.comp.lang.php:

Oui oui oui, je connais l'adresse de la FAQ (:
Je m'étonne juste d'un truc. J'ai un filtre fait comme ceci :

[...]
if (!ereg("([A-Za-z0-9]|-|_|.)*@([A-Za-z0-9]|-|_|.)*.([A-Za-z0-9]|-
|_|.)*",$courriel))
{$err='1';
echo '<p class="erreur">'.$courriel.' n'est pas une adresse courriel
valide</p>';
$courriel="";}

Ce qui m'étonne, c'est que ce filtre laisse passer sans moufter une adresse
comprenant par exemple un é. C'est-y normal ? Comment filtrer les accents ?


Les noms de domaine avec accents sont ou seront possibles. Il y a
déjà quelque chose prévu pour l'alphabet chinois, il me semble.

Ceci dit, je traite le problème de cette façon:

explode avec @, doit donner 2 éléments, sinon rejet
validation du 2e élément ($dom):
explode avec . et 2 éléments ou plus
doit avoir une IP équivalente (sinon, le nom de domaine est
invalide)

// $cour= courriel recu
$er = 0;
$cour2=explode("@", $cour);
if (count ($cour2) != 2) $er = 1;
if (count ($cour2) == 2) {
$dom=$cour2[1];
$cour3=explode(".", $dom);
if (count ($cour3) < 2) $er = 1;
if (count ($cour3) >= 2) {
$ip = gethostbyname($dom);
if ($ip == $dom) { $er = 1; };
};

Le code n'est pas optimisé (pas de clauses else), mais c'est peu
utilisé et comme j'ai développé un gros morceau de code rapidement
je n'ai pas voulu me mélanger dans les accolades.


Denis

Pascale
Le #41669
Olivier Miakinen news:474ecdba$:

Pour plusieurs raisons, dont certaines que j'ai déjà expliquées, par
exemple la syntaxe compliquée ([A-Za-z0-9]|-|_|.)* au lieu d'écrire
tout simplement [A-Za-z0-9_.-]* mais aussi le fait que le « + » n'est
pas prévu, et donc mon adresse serait refusée si l'auteur de cette
expression n'avait pas oublié d'« ancrer » le test : « ^...$ ».


Vu.

Tiens, une gauchère ! (^_^)


Yep (o;

Parce qu'elles sont plus puissantes, et en général plus rapides.

Note: preg_match(), qui utilise la syntaxe des expressions
rationnelles compatibles PERL, est une alternative plus rapide de
ereg(). </>


Bon bon bon, je vois qu'il faut que je me replonge dans le manuel...

Le test avant l'@ et après le . sont optionnels. S'il existe un é par
là, alors la chaîne reconnue commencera *après* le é.


C'est horriblement sournois, ce truc (:

Non pas « un ou plusieurs » mais « zéro, un ou plusieurs ». C'est le +
qui signifie « un ou plusieurs ».


Oui, c'est vrai.

Je prends quelques exemples, ce sera plus simple pour expliquer.
[couic]


Je crois que j'ai compris, finalement, tout arrive (:

Il manquait les méta-caractères ^(ancre sur le début de la chaîne) et
$ (ancre sur la fin de la chaîne).


Et le pire, c'est que ça faisait partie des quelques trucs que j'avais
pigés en matière de regexp... Et ben, ça m'apprendra à faire les
poubelles...

Merci de ta patience !

--
Pascale

Pascale
Le #41670
Denis Beauregard écrivait news::

Les noms de domaine avec accents sont ou seront possibles. Il y a
déjà quelque chose prévu pour l'alphabet chinois, il me semble.

Ceci dit, je traite le problème de cette façon:
[couic]
Le code n'est pas optimisé (pas de clauses else), mais c'est peu
utilisé et comme j'ai développé un gros morceau de code rapidement
je n'ai pas voulu me mélanger dans les accolades.


Oups... c'est bien compliqué pour mon neurone... Je m'en tiens pour
l'instant à la solution de la FAQ, du moins, tant qu'il n'y a pas d'accents
dans les noms de domaine...

--
Pascale

Mickael Wolff
Le #40790

Oups... c'est bien compliqué pour mon neurone... Je m'en tiens pour
l'instant à la solution de la FAQ, du moins, tant qu'il n'y a pas d'accents
dans les noms de domaine...


Les accents sont utilisables depuis longtemps. Mais vu que chez MS ils
ne sont pas capable de faire un navigateur respectant les normes, ben ça
ne c'est pas développé. Si tu tappes à.com dans Firefox, tu verras à
quoi ressemble une URL encodée pour supporter les accents (il est à
noter que c'est le codage qui est affiché, et non pas à .com, car de
telles URL furent utilisées pour du phishing).


Pour tester les regexp, j'utilises l'outil suivant :
mais très pratique.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Pascale
Le #40787
Mickael Wolff news:4751c07f$0$1167$:

Les accents sont utilisables depuis longtemps. Mais vu que chez MS
ils
ne sont pas capable de faire un navigateur respectant les normes, ben
ça ne c'est pas développé. Si tu tappes à.com dans Firefox, tu verras
à quoi ressemble une URL encodée pour supporter les accents (il est à
noter que c'est le codage qui est affiché, et non pas à .com, car de
telles URL furent utilisées pour du phishing).


Firefox le traduit par http://xn--0ca.com/. Opera ne le traduit pas mais
amène le même résultat. Exploser fait pareil.
Donc Firefox est le seul à savoir se débrouiller ?

Pour tester les regexp, j'utilises l'outil suivant :
(Tcl/Tk), mais très pratique.


Et zou, en marque-page. Merci ! (:

--
Pascale

Olivier Miakinen
Le #40358

[ noms de domaines avec accents ]


Firefox le traduit par http://xn--0ca.com/.


Exactement. Je n'avais pas pris la peine de répondre à Denis, mais tu
vois qu'il n'est donc pas nécessaire de modifier les regexps pour
prendre en compte les accents puisque le *vrai* nom, celui qui est
transmis, respecte déjà la vieille syntaxe.

Opera ne le traduit pas mais
amène le même résultat. Exploser fait pareil.
Donc Firefox est le seul à savoir se débrouiller ?


S'ils amènent le même résultat, c'est qu'ils traduisent exactement comme
Firefox. Simplement Firefox est le seul à afficher le nom réel. Lorsque
ces noms de domaine se généraliseront, je pense que les navigateurs
permettront d'afficher les deux.


Pascale
Le #40355
Olivier Miakinen news:47532036$:

Exactement. Je n'avais pas pris la peine de répondre à Denis, mais tu
vois qu'il n'est donc pas nécessaire de modifier les regexps pour
prendre en compte les accents puisque le *vrai* nom, celui qui est
transmis, respecte déjà la vieille syntaxe.


Donc ça roule !

S'ils amènent le même résultat, c'est qu'ils traduisent exactement comme
Firefox. Simplement Firefox est le seul à afficher le nom réel. Lorsque
ces noms de domaine se généraliseront, je pense que les navigateurs
permettront d'afficher les deux.


Ce serait logique, en effet.

--
Pascale

Publicité
Poster une réponse
Anonyme