-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I'm sorry, but there's loads of issues... #14
Comments
Thanks @RobThree some valid points there. Regarding the HTML tag pattern, that's pretty useful for plain text HTML, like in an editor. I've now removed the password pattern as that was proving particularly controversial. PRs are very welcome if you want to make any improvements yourself. |
|
Except that feb. 30th doesn't exist 😉
Except that there are a gazillion ways the regex will match incorrectly (demonstrated here) or cause trouble otherwise. Have you read the stackoverflow answer I linked to?
All the ones I pointed out are very case-specific and hard, if not impossible (html, email for example), to get correct. Though I can think of improvements here-and-there I'd suggest taking them all down; for most, if not all, of the regexes there are better ways of handling and validating the inputs (like simply parsing a date(time) value to 'validate' it or sending an activation e-mail to verify an e-mail address). Regexes do have their use, I'm not saying they don't. But, as said, for most (if not all) of the examples there are much better solutions. Edit: Here's more I just stumbled upon. |
Re: Emails. The only true way to validate emails is with basic pattern matching. Something along the lines of looking for @.* is the most you can possibly hope to do. I completely agree with Rob on that point. |
It also lacks a ^ and $ for the time pattern, just like the date one, otherwise it matches "4;30" when you input "24:00" |
I seem to run into a bug with the pattern |
For the email, several regex can help to filter some bad formats. Lot of sites are still expecting 'simple' emails, eg. max 3 chars for TLD (.com)! Few filters Maximum length: 254 due to network protocols, not email specs, search RFC...
Rough validation of min/max length blocks: Enhancing this formula, the 3 lengths, is ?impossible? in regex as you need to know the length of each part, must use javascript, not just regex. Just for Latin char set, supposing case insensitive is set (/..../i): A bit more international, but invalid characters are not filtered (spacesss, tabsss, I think controls are except DEL):
64 is the maximum, today the maximum existing is 24 Few links To test your suppositions: Free Mailgun.com validation api, not just the syntax: Explanation of unicode in regex: For the lazy one, this one is from a framework, dont remember which one...
|
That's an easy answer. When it comes to email addresses, you never want to stop a valid user from signing up via email address. You would much rather take a hundred junk email address than prevent one valid user from signing up or filling out a form. |
Famous answer
Hex HTML/CSS color value maybe, but
0xDEADBEAF
is a perfectly valid hex value.Slowly we're moving the world to password phrases and everybody should be hashing their passwords. Then why the 32 char limit? And why, for Pete's sake, are we only allowing
a-zA-Z0-9+_-
and nothing else? *cries* (see also)Yeah. Just. No. Another famous answer
We don't all live in the US/UK. (
1,234.56
v.s.1.234,56
)+123 is a valid phonenumber? Where? Phonenumbers are notoriously hard to validate (hence libphonenumber for example).
Failed the very first 'edge case' I could come up with: 30/02/2016 but also 1852 or 2150 fail... ( as noted elsewhere).
The text was updated successfully, but these errors were encountered: