4 ms·
Yup. My role of accepting phone numbers is `input.replace(/[^0-9+]/g, "")`. It might strip some expected information in rare cases but good enough for me. This
by kevincox 5y ago
Yup. My role of accepting phone numbers is `input.replace(/[^0-9+]/g, "")`. It might strip some expected information in rare cases but good enough for me.
This works for a lot of other things that people format wildly like Canadian postal codes (which are A1A 1A1 format but many places require presence or absence of a space), credit cards (strip the spaces) and so many other fields.
- Aachen 5y agoWhy not simply leave it as the user input the value? Validation is one thing, but silently dropping information cannot possibly be helpful for the person that then has to call this number. I agree it should work for any phone number I've ever encountered, but just why
- jodrellblank 5y agoWill it work for the convention in the UK of writing +44 (0)1234 567 8901 which says to use 01234 dialling code inside the UK or 441234 if calling from another country, and don’t dial 4401234 ever?
- jacurtis 5y agoA truly global phone number regex is quite literally impossible to make. There are too many combinations and expectations built into these conventions. You listed several here. The "best" solution is to separate country code into a different field or input. Then have everything other than the country code (generally called a "subscriber number") added to another input. Then on the backend you would essentially strip out all the non-numeric characters from the subscriber number and combine the country code and stripped "subscriber number" into an E.164 format number and store that in the database. (Source) I have spent a decade dealing with phone numbers in databases and web forms. This is the "best" way to handle it, and even it isn't bulletproof, but it works 99.8% of the time. The best way to handle the other 0.2% of cases is to make a descriptive error message that explains to the user how you are expecting them to input their number (ie. No extensions, etc). Here is the E.164 standard: https://www.itu.int/rec/T-REC-E.164/ https://www.itu.int/rec/T-REC-E.164/
- lelandfe 5y agoThis is one of the reasons why I generally don't like `maxlength` on telephone input fields: browsers will truncate pasted-in phone numbers with nary a peep to the user as to why. Validation with onblur or submission is great, but changing my input makes me angry.
- listenallyall 5y agoUsing letters in a phone number as a mnemonic, or just to flow better, is not a "rare case." You should revise your regex to accept letters, then whether you store them internally as letters or convert to the corresponding numbers is up to you.
- kevincox 5y agoThat makes sense if you are making a contact book or social profile. I was focusing on the case where I want the number as contact information. I want to validate up front that it is a number that I can actually call and don't really care about how the user wants to format it.
- listenallyall 5y agoRight, but it's user-hostile. I prefer thinking of, and typing, my phone number as a mix of numbers and letters... so why won't you allow me to do so?
- kevincox 5y agoI am letting you. It is just when the number is sent to the backend it is converted into a usable format where I can for example generate tel: links and otherwise use the number. I agree that there is some value to being able to each your number back how you typed it, but I'm not sure it is more valuable then showing you the number how I am actually going to try to call it.
- listenallyall 5y agoIsn't that exactly what I stated in my initial comment? Not sure why you were so quick to disagree
- kevincox 5y agoSorry, sounds like a misunderstanding. I always meant to accept anything, that is why I put a replace in my top comment not saying that I would reject the form.