i18n.phonenumbers.js icon indicating copy to clipboard operation
i18n.phonenumbers.js copied to clipboard

Invalid Netherlands phonenumber is marked as valid

Open mstalfoort opened this issue 9 years ago • 3 comments

Example testcases

0885553s300 0885553/300 0885553300,

When running these through https://cdn.rawgit.com/leodido/i18n.phonenumbers.js/master/demo/demo.html with NL selected as default country will result in a "true" response from isValidNumber whereas these testcases aren't valid phonenumbers.

By the looks of it, from the formatting output, the "s" or the "/" or the "," aren't used internally and somehow stripped so the remaining chars will result in a valid phonenumber. At the moment it's hard to rely on the boolean output from isValidNumber, please assist on this.

mstalfoort avatar Oct 06 '15 20:10 mstalfoort

Hi @mstalfoort,

thanks for the issue and yes I confirm this behavior.

However this can not be classified as bug for a simple reason: regardless of the locale used (e.g., NL, IT and so on) this always happen simply because the underlying library assumes you only inputs valid chars for your localised phone number.

The goal of the underlying library is infact to format and parse phone numbers not each possible string in the world.

This means that you have to filter the string (i.e., strip unwanted chars like commas, letters, etc.) before the validation as a phone number. The set of valid chars for valid phone numbers changes from locale to locale.

leodido avatar Oct 06 '15 21:10 leodido

Hey,

Thanks for looking into it and your fast responses. Yet I didn't expect to have to filter out any unwanted chars since on the underlying library it's also written to validate (https://github.com/googlei18n/libphonenumber#what-is-it) a phonenumber. These testcases shouldn't pass the validation imho since it now makes the underlying library far less usable. Why would I need it if I have to make my own filters? I'll add an extra layer in my case to filter invalid chars.

mstalfoort avatar Oct 07 '15 07:10 mstalfoort

I strongly agree with you @mstalfoort. The validation should return false. Rather it ignores unwanted chars and return true. As soon as possible (whenever I have some spare time) I'll investigate further.

Have you tried to submit this issue to their repo?

leodido avatar Oct 13 '15 09:10 leodido