Leading zero after country code is seen as valid

[Maik Heunisch]

I'm trying to parse a phone number.

In Germany (and e.g. UK), if you start with a country code, you leave the 0 out after the country code so the local number 0921 1234567 has to be dialled as +49 921 1234567, +49 0921 1234567 isn't supposed to be considered a valid number, yet it passes the strict call of IsValidNumber in the lib as seen here.

Is this considered a bug, a oversight or is it intention? The libary even recognises the trailing zero and corrects the number.

Is there a possibility to check for the E.164 format (in which the number with the 0 wouldn't pass, tested here)

[Lara Scheidegger]

This is intentional, because with "parse" we are trying our best to understand the number, and often on e.g. a web page, people write it this way (even though you're right, it's not diallable).

Options depending on what you are trying to achieve:

- you could use "find" and set the mode to "strict" which wouldn't find it now

- *or* you could parse, format as e164, national and international, and compare digits of each version with digits of the input string to see if any match.

--
You received this message because you are subscribed to the Google Groups "libphonenumber-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libphonenumber-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/libphonenumber-discuss/ab1ae92d-64a9-4005-b0a7-f17e77a16ff3n%40googlegroups.com.

[David Beaumont]

The demo parses to account for space and other things (including people very commonly adding the leading 0 unnecessarily).

If you are sure you have E.164 you don't need to parse the number leniently when using the library.

You can see that the demo thinks the E164 number would NOT include the leading zero (it removes it in the national_number).

{"country_code":49,"national_number":9211234567,"raw_input":"+4909211234567","country_code_source":1}

So this is just an artifact of the number being parsed leniently in the demo and the library should treat the actual E.164 number as invalid.

You can explore the canonical CSV data which it processed to make the XML data here:

https://github.com/google/libphonenumber/blob/master/metadata/metadata.zip

Look in the file:

metadata/49/ranges.csv

And you can see that no area codes start with 0.

HTH,

    David

--

You received this message because you are subscribed to the Google Groups "libphonenumber-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to libphonenumber-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/libphonenumber-discuss/ab1ae92d-64a9-4005-b0a7-f17e77a16ff3n%40googlegroups.com.

--

David Beaumont :: Îñţérñåţîöñåļîžåţîờñ Libraries :: Google
Google Switzerland GmbH., Brandschenkestrasse 110, CH-8002, Zürich - Switzerland

[Chris Wilson]

Maik,

Confusing, isn't it? I believe plenty of people have had the same problem.

libphonenumber doesn't actually seem to have a function to validate a
number - instead everytime you give it a number it performs any
corrections it can unambiguously make and returns to you whether the
outcome of that process is valid. So if you want to validate a number,
you need to perform two steps:
- Check isValidNumber() is true
- Check that when you format the number, what you get out is
identical to what you put in.

If both are true then your number is validated.


Regards,

Chris

> --
> You received this message because you are subscribed to the Google Groups "libphonenumber-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to libphonenumber-di...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/libphonenumber-discuss/ab1ae92d-64a9-4005-b0a7-f17e77a16ff3n%40googlegroups.com.



--

Chris Wilson
jak...@gmail.com

[David Beaumont]

If you have an E164 number you are certain of, you can just create a PhoneNumber object directly and just test that for validation.

I thought there was a "fromE164" method in the library, but maybe not. That wouldn't be hard to add.

I think in general the issue was that users constantly get this wrong and don't understand things like national prefixes vs international dialling, so if we had a string as a source, we'd prefer to trust the library to parse it and fix the commonest mistakes.

Re-parsing numbers from a database which you're already sure are E164 is a time when making a PhoneNumber instance directly might be appropriate.

https://github.com/google/libphonenumber/blob/master/java/libphonenumber/src/com/google/i18n/phonenumbers/Phonenumber.java

HTH,

    David

To view this discussion on the web visit https://groups.google.com/d/msgid/libphonenumber-discuss/CADQ6SvsDCLj3T31AQc60YiDFK%3Dk4iVPdTRGwy%2BZrrDf-Wyjv9A%40mail.gmail.com.

[Aravind Penmetsa]

Hi,

You are right Chris.

Libphonenumber does not have an API that could reduce the leniency while parsing the numbers.

We have PhoneNumberUtil.findNumbers() API that can test at various leniency levels;

However, that can be strict on the grouping of numbers (format of national number) only.

Will not be helpful for your case, +49 0921 1234567, where 0 is trimmed as part of parsing.

We see your point on "why such inputs are considered valid?": the idea is to use the computed

canonicalised form rather than the free text input - for later use; and save the input in "raw_input" field

To view this discussion on the web visit https://groups.google.com/d/msgid/libphonenumber-discuss/CAKxGnnujTbx_Aj%3DzMchDGb%3DsHm5EvM0WX217gXFbPVYuXX%2BdMA%40mail.gmail.com.

--

Thanks & Regards,

Aravind