Bonjour,
Je travail actuellement sur un formulaire mail en php.
Je le test donc à chaque mis à jour sur 3 hébergeurs différents dont 1 gratuit.

J'ai crée une reg pour valider le format d'un email.
Dans cette reg, j'utilise des \w (en minuscule: caractères alpha-numériques).
Tout était ok et fonctionnait parfaitement.

Aujourd'hui je test sur un des hébergeurs (je précise que je n'avais pas modifié cette reg depuis).
Et donc depuis aujourd'hui les \w se comportent étrangement: ils acceptent tous ou presque les caractères.
Pour résumer: la reg ne filtrait quasiement plus rien, à part le @...

C'est complètement illogique et je ne comprends pas la raison surtout que quelques jours avant, tout fonctionnait parfaitement.
J'ai donc modifié ma reg de façon classique: [a-z0-9] à la place de \w
Et maintenant tout re-fonctionne parfaitement.

Si jamais quelqu'un à une explication logique, cela m'intéresserait de comprendre.
Sinon cela peut peut-être alerter d'autres personnes de ce possible bug, si cela en est un...

ca dépend peu etre de la version de pcre

echo PCRE_VERSION;
// 7.9 2009-04-11 (de mon coté)

http://www.php.net/manual/fr/pcre.installation.php

7.9 2009-04-11

Sinon c'est pas mal dangereux cette histoire, et encore heureusement que j'ai fais une mis à jour et heureusement aussi que je m'en suis aperçut...

Je viens de re-tester la reg avec les \w.
Donc tout fonctionne parfaitement sur les 2 premiers hébergeurs.
Sur le troisième hébergeur, depuis aujourd'hui, les \w se comportent étrangement mais en remplaçant les \w par [a-z0-9] -> cela corrige le problème.


En attendant d'avoir une explication logique je déconseille l'utilisation des \w.

c'est la même version sur les 3 ?

Non les 2 autres:
7.6 2008-01-28

C'est peut-être l'explication en effet, gros bug ou grosse faille de sécurité si c'est à cause de la dernière version PCRE.
Imagine tous les scripts qui utilise \w

Ou une mauvaise configuration du serveur.
L'interprétation de "\w" peut dépendre des locales installées, pour valider ce qui constitue ou ne constitue pas un mot (problème avec les lettres accentuées, etc.)
Il faudrait voir le changelog de PCRE pour vérifier s'ils en parlent, mais j'en doute, un tel bug ne passerait pas inaperçu.

Oui et puis après reflections, c'est surement une combinaison de plusieurs éléments qui produit ce bug.
Donc pour être précis , voici la reg en question.

Bug avec \w (PCRE version: 7.9 2009-04-11):

    // Vérifier le format d'un email par Dr@ke
    function verif_mail($email) {
        if(strlen($email) < MAX_EMAIL_F && preg_match('#^\w+([-_.]\w+)?([-_.]\w+)?@\w+([-.]\w+)?\.[a-z]{2,4}$#', $email)) {
           if (is_win() && PHP_VERSION_ID < 50300) return true;
           else {
               $domaine = explode('@', $email);
               return (checkdnsrr($domaine[1], 'NS'));
           }
        }
        else return false;
    }

Fonctionne sans \w (PCRE version: 7.9 2009-04-11):

    // Vérifier le format d'un email par Dr@ke
    function verif_mail($email) {
        if(strlen($email) < MAX_EMAIL_F && preg_match('#^[a-z0-9]+([-_.][a-z0-9]+)?([-_.][a-z0-9]+)?@[a-z0-9]+([-.][a-z0-9]+)?\.[a-z]{2,4}$#', $email)) {
           if (is_win() && PHP_VERSION_ID < 50300) return true;
           else {
               $domaine = explode('@', $email);
               return (checkdnsrr($domaine[1], 'NS'));
           }
        }
        else return false;
    }

Pas simple de décoder le changelog en anglais.
Mais il est possible que \w+ ou la combinaison avec ()?
Ou comme dit Berzemus, une mauvaise configuration du serveur.

PS:
Pour les tests, le mieux est d'enlever le checkdnsrr

t'as un exemple d'adresse ou ca marchais pas ?

j'ai fait un test

//PCRE version: 7.9 2009-04-11

var_dump(preg_match('#^\w+([-_.]\w+)?([-_.]\w+)?@\w+([-.]\w+)?\.[a-z]{2,4}$#', '[email protected]'));
// int(1);

var_dump(preg_match('#^\w+([-_.]\w+)?([-_.]\w+)?@\w+([-.]\w+)?\.[a-z]{2,4}$#', 'tes***[email protected]'));
// int(0);

Oui mon Email destinataire par défaut qui est bloqué dans le script par la reg de vérification.
Et là aujourd'hui sur un 1 hébergeur -> il passait à travers:
votre_email@votre_domaine.com

normale \w comprend l'underscore,