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++