Is there a standard for storing normalized phone numbers in a database?

Where are you getting the phone numbers from? If you're getting them from part of the phone network, you'll get a string of digits and a number type and plan, eg

441234567890 type/plan 0x11 (which means international E.164)

In most cases the best thing to do is to store all of these as they are, and normalise for display, though storing normalised numbers can be useful if you want to use them as a unique key or similar.

Here's my proposed structure, I'd appreciate feedback:

The phone database field should be a varchar(42) with the following format:

CountryCode - Number x Extension

So, for example, in the US, we could have:

1-2125551234x1234

This would represent a US number (country code 1) with area-code/number (212) 555 1234 and extension 1234.

Separating out the country code with a dash makes the country code clear to someone who is perusing the data. This is not *strictly* necessary because country codes are "[prefix codes][1]" (you can read them left to right and you will always be able to unambiguously determine the country). But, since country codes have varying lengths (between 1 and 4 characters at the moment) you can't easily tell at a glance the country code unless you use some sort of separator.

I use an "x" to separate the extension because otherwise it really wouldn't be possible (in many cases) to figure out which was the number and which was the extension.

In this way you can store the entire number, including country code and extension, in a single database field, that you can then use to speed up your queries, instead of joining on a user-defined function as you have been painfully doing so far.

Why did I pick a varchar(42)? Well, first off, international phone numbers will be of varied lengths, hence the "var". I am storing a dash and an "x", so that explains the "char", and anyway, you won't be doing integer arithmetic on the phone numbers (I guess) so it makes little sense to try to use a numeric type. As for the length of 42, I used the maximum possible length of all the fields added up, based on Adam Davis' answer, and added 2 for the dash and the 'x".



[1]:

[To see links please register here]

> User friendly: +44 (0)181 464 2542 normalised: 00441814642542

The (0) is not valid in the international format. See the ITU-T E.123 standard.

The "normalised" format would not be useful to US readers as they use 011 for international access.

Look up E.164. Basically, you store the phone number as a code starting with the country prefix and an optional pbx suffix. Display is then a localization issue. Validation can also be done, but it's also a localization issue (based on the country prefix).

For example, +12125551212+202 would be formatted in the en_US locale as (212) 555-1212 x202. It would have a different format in `en_GB` or `de_DE`.

There is quite a bit of info out there about ITU-T E.164, but it's pretty cryptic.

I've used 3 different ways to store phone numbers depending on the usage requirements.

1. If the number is being stored just for human retrieval and won't be used for searching its stored in a string type field exactly as the user entered it.
2. If the field is going to be searched on then any extra characters, such as +, spaces and brackets etc are removed and the remaining number stored in a string type field.
3. Finally, if the phone number is going to be used by a computer/phone application, then in this case it would need to be entered and stored as a valid phone number usable by the system, this option of course, being the hardest to code for.

What about storing a freetext column that shows a user-friendly version of the telephone number, then a normalised version that removes spaces, brackets and expands '+'. For example:

**User friendly:** +44 (0)181 4642542

**Normalized:** 00441814642542

The standard for formatting numbers is [e.164][1], You should always store numbers in this format. You should never allow the extension number in the same field with the phone number, those should be stored separately. As for numeric vs alphanumeric, It depends on what you're going to be doing with that data.


[1]:

[To see links please register here]

First, beyond the country code, there is no real standard. About the best you can do is recognize, by the country code, which nation a particular phone number belongs to and deal with the rest of the number according to that nation's format.

Generally, however, phone equipment and such is standardized so you can almost always break a given phone number into the following components

- C Country code 1-10 digits (right now 4 or less, but that may change)
- A Area code (Province/state/region) code 0-10 digits (may actually want a region field and an area field separately, rather than one area code)
- E Exchange (prefix, or switch) code 0-10 digits
- L Line number 1-10 digits

With this method you can potentially separate numbers such that you can find, for instance, people that might be close to each other because they have the same country, area, and exchange codes. With cell phones that is no longer something you can count on though.

Further, inside each country there are differing standards. You can always depend on a (AAA) EEE-LLLL in the US, but in another country you may have exchanges in the cities (AAA) EE-LLL, and simply line numbers in the rural areas (AAA) LLLL. You will have to start at the top in a tree of some form, and format them as you have information. For example, country code 0 has a known format for the rest of the number, but for country code 5432 you might need to examine the area code before you understand the rest of the number.

You may also want to handle `vanity` numbers such as `(800) Lucky-Guy`, which requires recognizing that, if it's a US number, there's one too many digits (and you may need to full representation for advertising or other purposes) and that in the US the letters map to the numbers differently than in Germany.

You may also want to store the entire number separately as a text field (with internationalization) so you can go back later and re-parse numbers as things change, or as a backup in case someone submits a bad method to parse a particular country's format and loses information.

**Storage**

Store phones in [RFC 3966][1] (like `+1-202-555-0252`, `+1-202-555-7166;ext=22`). The main differences from [E.164][2] are

- No limit on the length
- Support of extensions

To optimise speed of fetching the data, also store the phone number in the National/International format, in addition to the RFC 3966 field.

Don't store the country code in a separate field unless you have a serious reason for that. Why? Because you shouldn't ask for the country code on the UI.

Mostly, people enter the phones as they hear them. E.g. if the local format starts with `0` or `8`, it'd be annoying for the user to do a transformation on the fly (like, "*OK, don't type '0', choose the country and type the rest of what the person said in this field*").

**Parsing**

Google has your back here. Their [libphonenumber][3] library can validate and parse any phone number. There are ports to almost any language.

So let the user just enter "`0449053501`" or "`04 4905 3501`" or "`(04) 4905 3501`". The tool will figure out the rest for you.

See the [official demo][4], to get a feeling of how much does it help.


[1]:

[To see links please register here]

[2]:

[To see links please register here]

[3]:

[To see links please register here]

[4]:

[To see links please register here]