Phone number validation - excluding non repeating separators

Question

I have the following regex for phone number validation

function validatePhonenumber(phoneNum) {
    var regex = /^[1-9]{3}[-\s\.]{0,1}[0-9]{3}[-\s\.]{0,1}[0-9]{4}$/;
    return regex.test(phoneNum);
}

However, I would liek to make sure it doesn;t pass for different separators such as in 111-222.3333

Any ideas how to make sure the separators are the same always?

Answer 1

Just make sure beforehand that there is at most one kind of separator, then pass the string through the regex as you were doing.

function validatePhonenumber(phoneNum) {
    var separators = extractSeparators(phoneNum);
    if(separators.length > 1) return false;

    var regex = /^[1-9]{3}[-\s\.]{0,1}[0-9]{3}[-\s\.]{0,1}[0-9]{3}$/;
    return regex.test(phoneNum);
}

function extractSeparators(str){
    // Return an array with all the distinct chars
    // that are present in the passed string
    // and are not numeric (0-9)
}

Answer 2

You can use the following regex instead:

\d{3}([-\s\.])?\d{3}\1?\d{4}

Here is a working example:

http://regex101.com/r/nN9nT7/1

As result it will match the following result:

111-222-3333   --> ok
111.222.3333   --> ok
111 222 3333   --> ok
111-222.3333
111.222-3333
111-222 3333
111 222-3333

EDIT: after Alan Moore's suggestion:

Also matches 111-2223333. That's because you made the \1 optional, which isn't necessary. One of JavaScript's stranger quirks is that a backreference to a group that did not participate in the match, succeeds anyway. So if there's no first separator, ([-\s.])? succeeds because the ? made it optional, and \1 succeeds because it's JavaScript. But I would have used ([-\s.]?) to capture the first separator (which might be nothing), and \1 to match the same thing again. This works in any flavor, including JavaScript.

We can improve the regex to:

^\d{3}([-\s\.]?)\d{3}\1\d{4}$

Answer 3

You'll need at least two passes to keep this maintainable and extensible.

JS' RegEx doesn't allow for creating variables for use later in the RegEx, if you want to support older browsers.
If you are only supporting modern browsers, Fede's answer is just fine...

As such, with ghetto-support, you aren't going to be able to reliably check that one separator is the same value every time, without writing a really, really, really, stupidly-long RegEx, using | to basically write out the RegEx 3 times.

A better way might be to grab all of the separators, and use a reduction or a filter to check that they all have the same value.

var userEnteredNumber = "999.231 3055";

var validNumber = numRegEx.test(userEnteredNumber);

var separators = userEnteredNumber.replace(/\d+/g, "").split("");

var firstSeparator = separators[0];
var uniformSeparators = separators.every(function (separator) { return separator === firstSeparator; });

if (!uniformSeparators) { /* also not valid */ }

You could make that a little neater, using closures and some applied functions, but that's the idea.

Alternatively, here's the big, ugly RegEx that would allow you to test exactly what the user entered.

var separatorTest = /^([0-9]{3}\.[0-9]{3}\.[0-9]{3,4})|([0-9]{3}-[0-9]{3}-[0-9]{3,4})|([0-9]{3} [0-9]{3} [0-9]{3,4})|([0-9]{9,10})$/;

Notice I had to include the exact same number-test three times, wrap each one in parens (to be treated as a single group), and then separate each group with an | to check each group, like an if, else if, else... ...and then plug in a separate special case for having no separator at all...

...not pretty. I'm also not using \d, just because it's easy to forget that - and . are both accepted "digit"s, when trying to maintain one of these abominations.

Now, a word or two of warning:

1. People are liable to enter all kinds of crap; if this is for a commercial site, it's likely better to just strip separators entirely and validate the number is the right size, and conforms to some specifics (eg: doesn't start with /^555555/).

2. If not given any instruction about number format, people will happily use either no separator or a formal number, like (555) 555-5555 (or +1 (555) 555-5555 for the really pedantic), which is obviously going to fail hard, in this system (see point #1).

3. Be prepared to trim what you get, before validating.

4. Depending on your country/region/etc laws about data-security and consumer-vs-transaction record-keeping (again, may or may not be more important in a commercial setting), it's likely better to store both a "user-given" ugly number, and a system-usable number, which you either clean on the back-end, or submit along with the user-entered text.

5. From a user-interaction perspective, either forcing the number to conform, explicitly (placeholders showing them xxx-xxx-xxxx right above the input, in bold), or accepting any text, and prepping it yourself, is going to be 1000x better than accepting certain forms, but not bothering to tell the user up-front, and instead telling them what they did was wrong, after they try.
   It's not cool for relationships; it's equally not cool, here.

6. You've got 9-digit and 10-digit numbers, so if you're trying for an international solution, be prepared to deal with all international separators (, \.\-\(\)\+) etc... again, why stripping is more useful, because THAT RegEx would be insane.