how to Validate a Phone number so that it should not allow all same numerics like 99999999999 or 11111111111 in JAVA
thanks Sunny Mate
views:
125answers:
3
+7
A:
The following regex:
^(\d)(?!\1+$)\d{10}$
matches 11 digit strings that do not have all the same digits.
A demo:
public class Main {
public static void main(String[] args) throws Exception {
String[] tests = {
"11111111111",
"99999999999",
"99999999998",
"12345678900"
};
for(String t : tests) {
System.out.println(t+" :: "+t.matches("(\\d)(?!\\1+$)\\d{10}"));
}
}
}
which produces:
11111111111 :: false
99999999999 :: false
99999999998 :: true
12345678900 :: true
Bart Kiers
2010-10-21 10:58:37
Very nice indeed.
Tony Ennis
2010-10-21 11:43:03
@Tony, thanks. It's a bit of fancy regex-trickery. I simply answered the question but I like the answers of @aioobe's (negating a less complicated pattern) and @TheBlastOne (addressing the probable issue behind the question) better.
Bart Kiers
2010-10-21 11:46:41
@TheBlastOne has a good point. Sometimes the programmer just has to do what they're told however. @aioobe's solution would probably cause consternation. Many companies seek out phone numbers with repeated digits and a less severe solution would reject them. In fact, as I think about it, we likely do less harm with a hardcore solution like yours, or no validation at all.
Tony Ennis
2010-10-21 11:52:45
>>Sometimes the programmer just has to do what they're told however.<< I 100% agree, and understand that. But once you find out that the "feature" you just implemented feeds defects or data quality problems into your organization, and once you figure the same people who told you to protect against inplausible data will without hesitation command you to "repair the data!", "fix the phone input" NOW, the nonsense becomes clear. I, too, usually do what I am told. But if they tell me to fix a problem by hiding the symptoms, creating an even bigger problem, I deny.
TheBlastOne
2010-10-23 13:36:41
+5
A:
This code matches numbers with at least 4 repeated numbers. (You could change the 3 in the regular expression to increase this threshold.)
Pattern sameDigits = Pattern.compile("(\\d)(\\1){3,}");
for (String num : new String[] {
"11111", // matches
"1234", // does not match
"8584", // does not match
"999", // does not match (too few repetitions)
"9999"}) // matches
if (sameDigits.matcher(num).matches())
System.out.println("Same digits: " + num);
else
System.out.println("Not same digits: " + num);
Prints
Same digits: 11111
Not same digits: 1234
Not same digits: 8584
Not same digits: 999
Same digits: 9999
aioobe
2010-10-21 10:59:30
+12
A:
If feasable, I'd try to discredit that requirement so it will be rejected.
No matter what you put into your plausibility checks, a user trying to avoid mandatory fields by entering junk into them will always succeed. You either end up having "smarter" harder-to-detect junk data items, or having a plausibility check which does not let all real-world data through into the system. Shit in, shit out. Build a shitshield, and your users will create fascies you never imagined.
There is no way to program around that (except for simple things that usually are unintended, erraneously entered typos and so on).
TheBlastOne
2010-10-21 11:12:47
Exactly right. If users enter incorrect data, that should be a tell-tale sign that the field should not be mandatory. If the users see the field as important they would not input false data.
MaxVT
2010-10-21 11:17:06
I'd second moving away from any over zealous validation on such fields. Another area where this seems to happen far too often is when people attempt email address validation, and and up disallowing perfectly valid characters like '+', '.', or '-' (arbitrary examples, and there are plenty more that occur in practice).
Sinjo
2010-10-21 11:20:13
Doh! I was 99% sure you guys will yell at me for the vulgar language. Shows truth remains truth, no matter how clearly you articulate it. Great relief on my side, thanks.
TheBlastOne
2010-10-23 13:23:33