Many times, I have seen developers write code for validating entries and they write very many if blocks or worse combine them with numerous switch cases. This approach would not have a problem but then more times than not, they need to be updated in certain periods when something new arises or for certain edge scenarios not originally considered.
The final regular expression has recently been updated (see end of post) but the logic remains the same.
One of these situations is validating phone numbers input into a field. For the Americas and Europe, this is not normally a problem because several frameworks will have that already inbuilt. This is not the same for other countries, such as Kenya (where I am from). In this blog post, I quickly construct a regular expression for validating phone numbers in this country.
First, let us consider the common formats that people use to represent mobile phone numbers:
+2547xxxxxxxx. Sometimes you will also see
7xxxxxxxx. Most systems will store phone numbers for use in calling or verifying ownership of a phone. In these situations, they need to send a message or interact with the phone in certain ways. Usually, to do so, the phone number should be in MSISDN format (read more on that here). As a brief, the format is:
CC = 254, NDC depends on the mobile network provider (71,72,70,79 for Safaricom, 73,78 and for Airtel, etc.) The other digits in the complete phone number designate the subscriber number.
All the possible prefixes for mobile phone numbers in Kenya are described clearly here thus I will not delve into it but instead use the information provided.
In this blog, I will build regular expressions step by step. To test them I recommend using regex101.com, it is quite easy and useful.
Given the number 0712345678, it is common to consider 345678 as the subscriber number and 712 as the NDC since the latter is tightly controlled by the provider or the regulatory body. The possible prefixes range: 700 to 708, 710 to 719, 720 to 729 and 790 to 792. The regular expression for this part is thus
7(([0-9])|(0[0-8])|(9[0-2])). The first digit (7) ensures the prefix starts with digit 7. The following group is used to capture the other two numbers. If the number following the compulsory 7 is a 1 or 2, then the next number ranges 0 to 9. If the number following the compulsory 7 is a zero then the next number ranges 0 to 8. Otherwise, if the number following the compulsory 7 is a 9 then the next number only ranges 0 to 2. The character
| is used to show possible combinations.
The last 6 digits are the easiest to validate since though they are usually serialized during manufacture, they seem almost random because there is no particular pattern to validate. The only thing we need to validate is that they are 6 digits. That is done using
This is as simple as a concatenation of the two expressions to form
However, this concatenation collects groups that we do not need. To make a non-capturing group, we add ‘?:’ before the group (a group is denoted using normal brackets). In our case this becomes
As mentioned earlier, people tend to write the numbers in different prefixes (personal choices) but we desire to standardize. Before compulsory digit 7, we have three possibilities: +254, 254 or 0. To validate this choice, I use
(254|\+254|0). Making this a non-capturing group results in:
(?:254|\+254|0). However, there are situations that neither of the three is present hence we make this group optional by appending '?' at the end, resulting in
First, we combine the result of 3 with that of 4 above to get:
Finally, to ensure a whole string input is a phone number we enforce checking the beginning and end of the string by adding ^ and $ at the beginning and end respectively. The final expression is thus:
The same 5 step process (or shorter) can be used to validate phone numbers from Airtel and Orange/Telecom. Once you do your homework you can compare with my results below. They are likely the answers. :-)
The regular expression above once validate results in two groups, if it matches. The first group is normally the whole string which was validated. The second group, in this case, will be the MSISDN without the country code e.g.
712345678. Since the country is known in this case, we only need to append it to the match results. I will show you how in Java and C#.
That is not too hard after all. I find it better than having multiple switch cases and/or if conditions. In case, the possible prefixes change, I will try and keep these regular expressions update but it should not be too hard to adjust them before I update the post.
Happy coding :-)
After weeks of using the above expression in production, I encountered other numbers that did not match. Though these numbers were valid, there is no existing documentation pointing to the same. In particular, Safaricom has exhausted all prefixes in the 79x series and towards the end of 2017-Q1, they started using numbers in the 74x series.
Since the 79x series is similar to 71x and 72x series they can be combined to form:
As of the time of writing I have only encountered 740–740 and 741. Adjusting the expression for the new numbers you can now use:
Since I wrote this article, the mobile providers in have since added more prefixes. Especially recently, the phone numbers must no not always start with 07 but can also start with 01.
For Safaricom the most recent new prefixes are 0110, 0111, 0112, 0113, 0114 and 0115. The regular expression needs to be updated to include all possibilities for Safaricom (00–09, 10–19, 20–29, 40–49, 90–99, 57–59, 68–69 when prefixed with 7 and 10–15 when prefixed with 1):
For Airtel, they are 0100, 0101, 0102. The regular expression needs to be updated to include all possibilities for Airtel (30–39, 50–56, 85–89 when prefixed with 7 and 00–02 when prefixed with 1):