isMobilePhone: Standardize the way number validation is done

[pano9000]

Hi all,

Inspired by the discussion in one of the PR here (https://github.com/validatorjs/validator.js/pull/2109#discussion_r1039621015), I am opening up this separate issue:

Currently the isMobilePhone RegExp rules are "all over the place" in regards to how they check for numbers and do not seem to follow one standard throughout:

• some are checking for the starting + as mandatory (regardless if strictMode is set or not)
• some are checking for the + as optional
• many do not check for the 00 prefix, which actually should be valid as well
• some are checking for "local" mobile phone numbers (e.g. where you replace the international phone code, with a single 0)

This leads to some of these validators also matching "invalid" phone numbers without 00 or + as valid,

We should tackle this issue somehow, by:

• a) agreeing on one matching standard for all numbers
• b) rewriting the RegExp rules accordingly

---

General Format

Valid numbers can look like (illustrasted here with same fake numbers). Please ignore the white space, they are added for visual aid.

Case 1

{international call prefix} {dialcode} {national numbering scheme} e.g. 00 49 172xxxxx e.g. 011 49 172xxxxx

The issue with this is, that there are exceptions here, depending on where you are located, e.g. calling from Europe, you will use 00, but if you are e.g. in the US, you will need to use 011 (source) More initial information also on Wikipedia

Case 2 + {dialcode} {national numbering scheme} e.g. + 49 172xxxxx

This seems to be the "safest" bet, as it will correctly chose the dialcode, when you try to make a call

Case 3 and in some countries (not sure, if valid worldwide or not, this is something to be researched.) {trunk prefix} {national numbering scheme} e.g. 0 172xxxxx

A quick look here shows that it usually is 0, but not for all cases: hhttps://en.wikipedia.org/wiki/Trunk_prefix So also something to keep in mind.

Case 4 and this is a bit of an edge case, as it is not a really valid number, but seems to be whitespread + {dialcode} {trunk prefix in parentheses} {national numbering scheme} e.g. + 49 (0) 172xxxxx

---

With that in mind, we now need to think about what strictMode is for, and if we need to change the way this works: Currently it is used to enforce, that the numbers start with a +

IMHO it might make sense to change the way this works, and possibly introduce some option to control, if you want to match for certain cases or not, e.g. you might want to only allow numbers if they have the full call prefix + dial code (case 1). Potentially it could be a good idea to introduce a way to match against a custom international prefix, which defaults to 00 though.

An options object, with a few options that we still need to think about, e.g. matchCallPrefix - potentially allowing to enter the "call prefix" from your region current 'strictMode' - matchTrunkPrefix - potentially allowing to enter the "trunk prefix" from your region internationalCallPrefix - to be used, when matchCallPrefix is true, could e.g. default to 00 TrunkPrefix - to be used, when matchTrunkPrefix is true, could e.g. default to 0

However this is something I would need to put some more thought into.

I guess for compatibility reasons, we will have to keep the "strictMode" option work the same way as it currently does, but it potentially could be aliased, for backwards compatibility?

---

You could also potentially see this as a 2 step process: a) standardize RegExp first b) at a later point introduce the new options

What are your thoughts on this?

Kind regards,

Pano

[WikiRik]

Good write-up of the current issue. I think this provides a clear picture of the situation.

I would indeed keep strictMode like it is for backwards compatiblity. It's not a lot of effort to keep it and might keep some people happy.

It might be good to write a small contributing docs on isMobilePhone with where people can find references for updates to the validator (maybe even linking references as an comment with the RegExp), what the default build up of the RegExp is and what kind of tests they should not forget. Then we can point users towards that for the open PRs and future PRs. I would recommend trying to merge many of the open PRs for isMobilePhone first (updated to a standardized RegExp) and afterwards fix the current validation. And once that's all done we can work on the new options

[braaar]

Very good issue. A well formulated "spec" for these validators is sorely needed. The contribution guideline for phone numbers should include a robust template for test cases and some explanation of each test case, as well.

Potentially it could be a good idea to introduce a way to match against a custom international prefix, which defaults to 00 though.

This is a good point. This kind of international prefix should be independent of the actual RegEx, since it depends on the location of the caller, not the locale of the number itself.