Discussion :

[lordrt]

Bonjour,
J'aurai besoin d'une aide concernant un regex en Java afin de valider ces 3 formats de numéro:
0123456789
+33123456789
0033123456789

JE dois passer ces 3 validations sur le même numéro de téléphone. Mais il faut que ça commence par 0 ou +33 ou 0033

Si par exemple j'ai mis 0123, je dois avoir un msg d'erreur, idem pour +33123456 ou 003312345678.

Est-ce que quelqu'un peut m'aider avec?

Merci d'avance...

PS. Vu que je sais pas trop les regex, j'avais essayé un truc du genre (0|\\+33|0033)[1-9][0-9]{10,13}, mais ça ne semble pas marcher, vu que même si je mets 12345, ça laisse valider le numéro.

[adiGuba]

Salut,


Déjà ton expression régulière est incorrect puisqu'elle accepte des numéro bien trop long. Cela devrait plutôt ressembler à "(0|\\+33|0033)[1-9][0-9]{8}", soit (0, +33 ou 0033), un chiffre entre 1 et 9 puis 8 chiffres entre 0 et 9...


Ensuite 12345 ne devrait pas passer avec ta regexp, donc tu dois avoir un problème dans ton code.



Enfin si tu as besoin d'une librairie plus complète, tu peux te tourner vers libphonenumber : http://code.google.com/p/libphonenumber/


a++

[professeur shadoko]

<note_accessoire>
tu as bien dit "valider" pas "refuser"....
Il n'y a rien qui m'exaspère autant que les sites WEB qui refusent une action parce que votre numero de téléphone ne correspond pas à l'idée qu'ils s'en font
tu es en voyage et tu ne peux pas faire des opérations parce que:
- ton adresse n'est pas dans la liste prédéfinie des états des états-unis (très courant)
- ton numero de tel. ne correspond pas au pattern prédéfini (exemple Apple aux US)
- ton nom comporte une espace à l'intérieur ("nom illégal": ça m'est arrivé chez un loueur de voiture!)
ou comporte des caractères non reconnus (hors ASCII!)
- ton age ou ton année de naissance n'est pas dans la liste (aussi incroyable que ça puisse paraître ça m'est arrivé!)
-tu es "apatride né dans la bande de Gaza sous administration égyptienne" et donc ta nationalité n'est pas dans la liste!
- le numero dans ta rue n'est pas connu d'une base mystérieuse (ça m'arrive en France! et pourtant ce numéro existe!)
-etc....

liste non limitative des inepties des programmeurs qui veulent bien faire!
</note_accessoire>

[Invité]

Bonjour,

Est-ce que cette expression pourrait convenir ? : ^(\\+33|0|0033)[0-9]{9}$

[joel.drigo]

Salut,

Est-ce que cette expression pourrait convenir ? : ^(\\+33|0|0033)[0-9]{9}$

Non. C'est la regex de @AdiGuba qui convient parce qu'un numéro de téléphone, , en France, c'est

• un préfixe (depuis la France, +33, 0, ou 0033),
• suivi
  
  • d'un code (zone (de 1 à 5), ou (6, 7, 8, 9 pour des codes spéciaux),
  • suivi d'un numéro sur 8 chiffres
  
  (donc 9 chiffres ne commençant pas par 0).

Si on exclut, bien sûr, tous les numéros spéciaux (genre 112, 3635, etc...) ou numéros internes.

Par contre, le fait de valider 9 chiffres peut être discutable par rapport au préfixe international : il doit y avoir des pays ou le numéro n'est pas sur 9 chiffres.

Avec ta regexp, 000000000 sera valide. Remarques, ce numéro peut être affiché par un téléphone comme numéro d'appelant, mais ce n'est pas parce que c'est son numéro, c'est juste parce que son numéro est masqué

[tchize_]

Cela devrait plutôt ressembler à "(0|\\+33|0033)[1-9][0-9]{8}",

Heu, t'as du oublier des parenthèses, parce que là je vois une regexp qui dit

un bloc formé de:
0 ou +
suivi de 3
suivi de 3 ou 0
suivis de 033

et derrière 8 chiffres


Alors qu'au final on aurait du avoir

"(0|(\\+33)|(0033))[1-9][0-9]{8}"Ceci dit, je rejoint le professeur Shadoko: ce genre de validation est extrêmement dangereuses. Tu va refuser:

Les gens qui tapent par habitude

012 34 56 789
012.345.67.89
(012) 345 67 89
01/23 45 67 89

Bien qu'il n'y aie pas d'évolution prévue à court terme, tu auras aussi un jour des problème si le plan de numérotation change. Avec le téléphone sur ip, on pourrais envisager dans le futur, par exemple, que les particulier pourraient brancher 3 ou 4 postes téléphonique dans la maison et disposer d'un numéro composé des 10 chiffres habituel + 2 pour le poste visé?

Valider des adresses, des pays, des villes, des codes postaux, des numéros de téléphone, des emails, c'est très dangereux tout ça.

[joel.drigo]

Par contre, pour les espaces, les ., les tirets, etc..., c'est sûr qu'on peut imaginer qu'un utilisateur lambda pourra saisir son numéro avec ce genre de variations. Même comme ça : +33(0)601020304... Dans ce cas, ne vaut-il pas simplement remplacer tout séparateur (donc tout ce qui n'est pas chiffre, ou + sauf en première position) par rien : en gros, reformater, avant de valider. Mais c'est vrai qu'on pourrait aussi parler de ceux qui s'amusent avec un "numéro" de téléphone sous forme de lettres, qui ne passerait pas la validation par la regex citée.

C'est sur que le problème de la validation peut s'avérer gênant en empêchant des saisies valides non prévues... Mais d'un autre côté, tout dépend ce qu'on veut en faire par la suite. J'ai rencontré un jour le problème de reprise de fichiers avec des numéros de téléphone du type "01xxx...xxx (le week-end 05xxx...xxx)", "xxx...xxx (ne pas appeler le matin cause travail de nuit)" ou "aucun"..., qu'il fallait entrer dans une base de contacts, ou le numéro était formaté xx.xx.xx.xx.xx ! Dans ce cadre, peut être que la validation devrait être faite au moment du traitement, juste en loguant les datas qu'on n'a pas pu traiter. Et que la validation à la saisie ne doit pas être bloquante mais juste signaler que la donnée saisie pourrait poser problème dans certains traitements ultérieurs.

C'est tout le problème de la validation : un compromis entre un moyen de limiter les erreurs de saisie (parce que il peut arriver qu'un utilisateur saisisse son nom dans le champ téléphone), et un moyen d'éviter de bloquer des saisies valides imprévues. Le problème se pose en particulier avec les adresses e-mails avec des parties échappées entre ", qu'on ne peut que rarement entrer dans des formulaires, parce qu'elles ne passent pas la validation.

[adiGuba]

Heu, t'as du oublier des parenthèses, parce que là je vois une regexp qui dit

Non les parenthèses internes ne sont pas nécessaire à l'opérateur OU !

a|bc correspond bien à "a" ou "bc", et non pas "ac" ou "bc" qui s'écrirait plutôt comme ceci (a|b)c

Donc l'expression est bien valable, pour les numéro en France en 2013, et uniquement et sans formatage quelconque...

Ceci dit, je rejoint le professeur Shadoko: ce genre de validation est extrêmement dangereuses. Tu va refuser:

Les gens qui tapent par habitude

012 34 56 789
012.345.67.89
(012) 345 67 89
01/23 45 67 89

Ça ce discute.

Tu peux tout à fait contraindre la saisie aux chiffre et caractère +, ou même laisser la saisie libre et faire un [code]replaceAll("[^+0-9]","")[/codeinline] avant la validation.

Au passage libphonenumber que j'ai cité un peu plus haut fait cela très bien, en gérant les numéros internationaux et les préfixes locaux.


Mais une validation des données peut être très importante pour éviter des saisies bidons ou des erreurs de saisies, que ce soit volontaire ou non.
Si la personne doit être recontacté on doit avoir un numéro valide, au moins d'un point de vue format. Cela évite déjà pas mal d'erreur.

Bien qu'il n'y aie pas d'évolution prévue à court terme, tu auras aussi un jour des problème si le plan de numérotation change. Avec le téléphone sur ip, on pourrais envisager dans le futur, par exemple, que les particulier pourraient brancher 3 ou 4 postes téléphonique dans la maison et disposer d'un numéro composé des 10 chiffres habituel + 2 pour le poste visé?

Oui... et il faudra alors faire évoluer le logiciel.
C'est pas vraiment la mer à boire non plus...

Si demain un service de messagerie remplace les emails, il faudra aussi changer...

Valider des adresses, des pays, des villes, des codes postaux, des numéros de téléphone, des emails, c'est très dangereux tout ça.

Ok pour les adresses, codes postaux et ville, car il faut une base de données énorme pour gérer cela, et que même sans cela on n'a pas vraiment une solution fiable tellement il y a de cas particulier.

Mais dans ce cas la validation pourrait se présenter comme une saisie semi-automatique (tu rentres le code postal, on te propose la ville - que tu peux modifier librement), sans que cela soit bloquant.


Pour les téléphones c'est déjà plus facilement gérable.
Surtout si tu es limité à un pays ou à une liste prédéfini de pays.
Et si tu dois manipuler le téléphone (pour envoyer des SMS par exemple), il est préférable que celui-ci soit dans un format correct qui ne te posera pas de soucis).


Les emails c'est un peu plus délicat, à cause d'un format laissant un peu libre court à du tout et n'importe quoi... Et c'est vraiment bien chiant d'ailleurs.



a++

[tchize_]

Mais une validation des données peut être très importante pour éviter des saisies bidons ou des erreurs de saisies, que ce soit volontaire ou non.
Si la personne doit être recontacté on doit avoir un numéro valide, au moins d'un point de vue format. Cela évite déjà pas mal d'erreur.

D'où l'importance de ne pas refuser un numéro non valide. On peux attirer l'attention de l'utilisateur, mais il faut se limiter à ça. Par exemple, ici, on parle de limiter à un numéro Français. Je ne connais pas beaucoup de cas où ça se justifie. Il y a d'autres moyen de vérifier à éviter ce genre d'erreur. Comme demander de l'entrer deux fois. C'est ce qu'on fait pour la création de mot de passe et au final ça se passe pas trop mal

Oui... et il faudra alors faire évoluer le logiciel.
C'est pas vraiment la mer à boire non plus...

Tu sous entends là que, au moment où ca se passera:
- ta boite sera toujours vivante
- ton client est prêt à payer pour la mise à jour
- on n'aura pas perdu les sources.

Le jour où ce changement devra avoir lieu, pour moi, dans 99% des cas on va juste jeter le logiciel, on aura donc ajouté une validation qui fait chier certains utilisateurs en temps normal, et qui rendra le logiciel plus cher à maintenir....



Ok pour les adresses, codes postaux et ville, car il faut une base de données énorme pour gérer cela, et que même sans cela on n'a pas vraiment une solution fiable tellement il y a de cas particulier.

Et si tu dois manipuler le téléphone (pour envoyer des SMS par exemple), il est préférable que celui-ci soit dans un format correct qui ne te posera pas de soucis).

C'est un bon exemple. J'ai déjà du envoyer des SMS pas un service automatique. Ben même quand le numéro a l'air correct, parfois, ça ne passe pas et faut appeler le provider pour dépétrer le merdier. Et tu découvre que, justement, le fournisseur de service a mis en place une validation inutilement avancée. Genre il refuse le format +32xxxxyyyzzz, car on ne peux envoyer que des SMS vers la Belgique..... Oui, c'est le préfixe belge +32.... et c'est refusé car uniquement en Belgique les sms.....

Sérieusement, si tu veux être sur que le numéro de GSM est correct le plus simple c'est d'envoyer un code de validation sur le GSM en question. De la même manière que la manière la plus fiable de valider un email c'est d'envoyer un email.

[adiGuba]

D'où l'importance de ne pas refuser un numéro non valide. On peux attirer l'attention de l'utilisateur, mais il faut se limiter à ça. Par exemple, ici, on parle de limiter à un numéro Français. Je ne connais pas beaucoup de cas où ça se justifie. Il y a d'autres moyen de vérifier à éviter ce genre d'erreur. Comme demander de l'entrer deux fois. C'est ce qu'on fait pour la création de mot de passe et au final ça se passe pas trop mal

Tu demandes de rentrer tout 2 fois ? L'email, le numéro de tel, l'adresse ?
Le tout sans forcer la saisie ? Et tes "utilisateurs" jouent le jeu ?

Perso si je fais cela je me retrouve avec des "0" dans tous les champs !!!

Tu sous entends là que, au moment où ca se passera:
- ta boite sera toujours vivante
- ton client est prêt à payer pour la mise à jour
- on n'aura pas perdu les sources.

Le jour où ce changement devra avoir lieu, pour moi, dans 99% des cas on va juste jeter le logiciel, on aura donc ajouté une validation qui fait chier certains utilisateurs en temps normal, et qui rendra le logiciel plus cher à maintenir....

Dans mon cas perso, mon client c'est ma boite... donc les critères sont assurés
Mais plus globalement j'espère qu'une boite qui se fait faire un logiciel conserve un droit sur les sources...

Parce que sinon il y a un paquet de raison qui feront "jeter" le logiciel... bien avant un éventuel changement de numéro de tel !

C'est un bon exemple. J'ai déjà du envoyer des SMS pas un service automatique. Ben même quand le numéro a l'air correct, parfois, ça ne passe pas et faut appeler le provider pour dépétrer le merdier. Et tu découvre que, justement, le fournisseur de service a mis en place une validation inutilement avancée. Genre il refuse le format +32xxxxyyyzzz, car on ne peux envoyer que des SMS vers la Belgique..... Oui, c'est le préfixe belge +32.... et c'est refusé car uniquement en Belgique les sms.....

Mais là tu parles d'un problème technique de ton provider, alors que tu lui fourni un numéro "propre".
Imagines ce que cela pourrait donner si tu lui envois n'importe quoi...

Sérieusement, si tu veux être sur que le numéro de GSM est correct le plus simple c'est d'envoyer un code de validation sur le GSM en question. De la même manière que la manière la plus fiable de valider un email c'est d'envoyer un email.

Oui. Ça c'est si tu veux être sûr à 100%.
Mais c'est encore un peu plus complexe à mettre en oeuvre... et plus coûteux (surtout pour l'envoi de SMS).



Question : et qu'en est-il des dates ?
Tu laisses aussi les utilisateurs rentrer ce qu'ils veulent ou tu as une validation ?


a++

[tchize_]

Tu demandes de rentrer tout 2 fois ? L'email, le numéro de tel, l'adresse ?
Le tout sans forcer la saisie ? Et tes "utilisateurs" jouent le jeu ?

Soit c'est critique, et tu fais confirmer, soit c'est pas critique, alors pourquoi sur-contraindre? Déjà ici, comme je dit, quelle contrainte force un numéro français? Ca me semble déjà suspect à la base Parce que le service n'est fournis qu'en France? Tu fais quoi d'un Français qui a un numéro de GSM belge? A une époque, pas très lointaine, ça coutait moins cher de prendre un opérateur marocain et de payer le roaming, que d'avoir un numéro mobile belge. Tu pouvais te retrouver avec des gens domiciliés en belgique, dont le seul numéro de contact était au Maroc. Tu fais quoi de ces gens là?

Mais plus globalement j'espère qu'une boite qui se fait faire un logiciel conserve un droit sur les sources...

Tu serais surpris, ce que même avec du dev interne on peux perdre comme sources.....

Mais là tu parles d'un problème technique de ton provider, alors que tu lui fourni un numéro "propre".

Je parle d'un provider qui a mis en place une sur validation justement. Il valide trop....

Imagines ce que cela pourrait donner si tu lui envois n'importe quoi...

Rien, les SMS qui passent pas, passent pas. Eventuellement on reçois des rapport d'erreur et on peux contacter le client (email, courrier) pour lui dire que son SMS passe pas.

Je vais tourner le truc autrement. Qu'est-ce qui m'empeche si j'ai pas envie de remplir le tel de mettre +3312345679 ?? Qu'est-ce que cette validation m'empeche de me tromper en mettant un 1 au lieu d'un 2 à un endroit?


Celui qui se trompe, continuera de se tromper, même avec la validation. Ca va faire chier que deux catégorie d'utilisateur:

Ceux qui ont rien envie de remplir => ils mettront n'importe quoi pourvu que ça passe
Ceux qui on vraiment un numéro pas prévu à la base => ils ne sauront pas le fournir....

Oui. Ça c'est si tu veux être sûr à 100%.
Mais c'est encore un peu plus complexe à mettre en oeuvre... et plus coûteux (surtout pour l'envoi de SMS).

Si t'as encodé le tél du gars, c'est que t'as bien l'intention de le contacter, c'est pas les 2 cents du SMS qui vont ruiner ton business plan...

Question : et qu'en est-il des dates ?

La différence avec une date, c'est que c'est impossible de survalider une date Je n'ai pas dit qu'il ne fallait rien valider. J'ai dit qu'il faut éviter de valider des choses pour lesquelles l'utilisateur peux avoir de très bonnes raisons de sortir des sentiers battus. Bien sur t'es jamais né un 32 février :s Et souvent, trop souvent, le développeur crois tout savoir sur la logique derrière et survalide certains champs.

Pour reprendre le tél, l'utilisateur peux très bien avoir un numéro court à moins de 10 chiffres. Si t'encode le client, et que le client veux être contacté via son numéro vert à 4 chiffre, tu l'encode comment??


En l'occurence, pour moi, un numéro de tél, c'est comme une email, y a plein de choses valide qu'on peux vouloir tapper là dedans, et valider avec des a priori, c'est très dangereux.

[adiGuba]

Soit c'est critique, et tu fais confirmer, soit c'est pas critique, alors pourquoi sur-contraindre? Déjà ici, comme je dit, quelle contrainte force un numéro français? Ca me semble déjà suspect à la base Parce que le service n'est fournis qu'en France? Tu fais quoi d'un Français qui a un numéro de GSM belge? A une époque, pas très lointaine, ça coutait moins cher de prendre un opérateur marocain et de payer le roaming, que d'avoir un numéro mobile belge. Tu pouvais te retrouver avec des gens domiciliés en belgique, dont le seul numéro de contact était au Maroc. Tu fais quoi de ces gens là?

Perso j'ai surtout conseillé d'utiliser libphonenumber qui gère très bien tous les numéros internationaux...

Par contre mis à part pour un mot de passe, j'ai toujours trouvé la double-saisie complètement inutile et chiante en fait. Bien plus qu'une validation de format.



On fait saisir les numéro de téléphones afin de pouvoir contacter le client en cas de retard/problème technique, donc cela ne va concerner qu'une partie des clients.
Si on devait valider chaque numéro via un SMS le coût serait assez important, voir même plus important que l'usage des numéro en eux-même...

De plus il faudrait mettre en place une logistique pour valider les numéros, et éventuellement retarder la commande !
Sans compter que cela risque de poser d'autres problèmes :
- Que faire s'il s'agit d'un poste fixe ? (pas de SMS donc - même si certains peuvent les recevoir c'est quand même assez rare)
- Que faire si le mec n'a pas son téléphone avec lui ?
- Que faire si la validation ne fonctionne pas ? Bloquer la commande ???



Ensuite tu parles de l’international, mais raison de plus pour valider le numéro, car la plupart des gens te fourniront le téléphone sans préfixe international.
Comment savoir de quel pays il s'agit ?
Surtout si la saisie du pays est également libre et que tu te retrouves avec tout et n'importe quoi...

Et çà devient galère si tu doit automatiser l'envoi de SMS ou même pour les contacter par tel car le numéro ne passera pas...



On a déjà eu pas mal de numéro incorrect simplement par erreur. Soit une mauvaise saisie par faute de frappe, soit même par méconnaissance de l'utilisation du préfixe.
En France par exemple beaucoup de personne saisiront "+33 01 23 45 67 89" au lieu de "+33 1 23 45 67 89".
Ok là c'est facile à voir, mais si c'est un numéro à l'étranger c'est peut être moins évident
Si tu ne valides pas un tant soit peu le format, bon nombre de numéro risquent d'être inutilisable et nécessiter derrière un traitement manuel qui empêchera toute automatisation (ce qui coûtera encore plus cher).



En cas de problème en envoi des SMS, puis on contacte "manuellement" ceux qui n'ont pas pu recevoir ce SMS.
Donc oui les erreurs de saisies ou de format peuvent nous coûter assez cher...

Tu serais surpris, ce que même avec du dev interne on peux perdre comme sources.....

Oui mais c'est un autre problème.
Je pense qu'un logiciel sans source et donc qui ne peut plus évoluer est plus un fardeau qu'autre chose.

Et la saisie du numéro de téléphone est loin d'être le seul critère qui risque de poser problème...

Je vais tourner le truc autrement. Qu'est-ce qui m'empeche si j'ai pas envie de remplir le tel de mettre +3312345679 ?? Qu'est-ce que cette validation m'empeche de me tromper en mettant un 1 au lieu d'un 2 à un endroit?

Je n'ai jamais dit le contraire.
Cela empêchera juste les erreurs avec des chiffres en trop ou en moins.
Cela n'empêchera pas l'utilisateur de rentrer des données bidons, mais là le problème viendra de lui et non pas du soft.

S'il rentre "01.23.45.67.89" mais que c'est un numéro bidon et qu'il ne reçoit pas les messages, cela devient son problème.
S'il a rentré "+33 01.23.45.67.89" et que le zéro en plus te provoque une erreur dans tes traitements, cela devient un peu plus ton problème...

Celui qui se trompe, continuera de se tromper, même avec la validation. Ca va faire chier que deux catégorie d'utilisateur:

Ceux qui ont rien envie de remplir => ils mettront n'importe quoi pourvu que ça passe
Ceux qui on vraiment un numéro pas prévu à la base => ils ne sauront pas le fournir....

Pour les premiers cela ne changera rien (sauf qu'il devront taper un peu plus de numéro). Et tu peux rendre le champ optionnel si tu ne veux pas les gêner.

Pour les seconds il y a de forte chance que tu ne puisses pas les contacter de toutes façons...

Si t'as encodé le tél du gars, c'est que t'as bien l'intention de le contacter, c'est pas les 2 cents du SMS qui vont ruiner ton business plan...

Cela dépend de la quantité de "gars" que tu dois gérer.
Si c'est du prospect pour rappeler le gars derrière ce n'est pas vraiment un problème, surtout qu'il y aura une "vérification" du numéro par un humain qui pourra corriger les éventuels problème basique.

Mais lorsque ca devient plus conséquent cela peut-être plus problématique, surtout pour une simple vérification.

La différence avec une date, c'est que c'est impossible de survalider une date Je n'ai pas dit qu'il ne fallait rien valider. J'ai dit qu'il faut éviter de valider des choses pour lesquelles l'utilisateur peux avoir de très bonnes raisons de sortir des sentiers battus. Bien sur t'es jamais né un 32 février :s Et souvent, trop souvent, le développeur crois tout savoir sur la logique derrière et survalide certains champs.

Mais tu as une partie de la population mondiale qui ne connait pas sa date de naissance exacte.
Pourquoi les forces-tu à rentrer une date précise alors que certains pourraient vouloir saisir "Printemps 1980" par exemple ?
Tu es en train de survalider ce champ !

Pour reprendre le tél, l'utilisateur peux très bien avoir un numéro court à moins de 10 chiffres. Si t'encode le client, et que le client veux être contacté via son numéro vert à 4 chiffre, tu l'encode comment??

Et... tu l'appelles comment depuis l’international ?
Un client belge te donne son numéro court : tu va pouvoir l’appeler depuis la France ?

Et en laissant une saisie libre tu vas réussir à envoyer des SMS automatiquement ?

En l'occurence, pour moi, un numéro de tél, c'est comme une email, y a plein de choses valide qu'on peux vouloir tapper là dedans, et valider avec des a priori, c'est très dangereux.

Oui mais s'il y a plein de chose valide qui te seront inutile, il vaut mieux le savoir avant qu'au dernier moment lorsque tu es dos au mur.


Cela ne sert à rien de récolter des informations qui te seront inutilisable, même si elles sont "valide".


a++