Live data from Hacker News

Perfect email regex finally found

fightingforalostcause.net

111–118 of 118 posts

Re: Perfect email regex finally found

#111

Earlier quoted context omitted.

If they get it wrong, intentionally or not, then they don't get their receipt, confirmation, validation link, etc. and I believe in most cases the incentive is there for them to get it right. Well, I hope you have a large enough support team, because with any reasonable amount of customer growth, you'll soon be swamped with support emails that say "I didn't get my ..., where is it? You suck!". Validating the email ad…

Even if they've typed it correctly it still can be blocked for various reasons. You will still need a support mechanism (doesn't have to get all the way to a person) to sort out undelivered verification mails. It's just how it goes.

Still, some rudimentary validation can prevent cases of someone entering the wrong value (e.g., just their username) or an incomplete value (e.g., scott.trudeau@gmail ) -- which I see with some regularity ~10k signups/month. If this lowers support email volume by even just 10%, that's not insignificant.

Re: Perfect email regex finally found

#112
post #14

I've accepted that it's best to treat people like grown-ups and if there's '@' and '.' and it's retyped then it passes. Someone can easily submit a fake name or phone number or street address, and e-mail's no different. If they get it wrong, intentionally or not, then they don't get their receipt, confirmation, validation link, etc. and I believe in most cases the incentive is there for them to get it right. In the r…

You assume an email regex is only used for validating addresses. It can also be used to parse text for email addresses (for formatting or mining purposes maybe).

Re: Perfect email regex finally found

#113
post #72
post #59

Earlier quoted context omitted.

> Given this, why would we use regular expressions? If I can get a way with a simple regexp I will use it. If it starts getting complicated I would use something else.(e.g. top down parser or a combination)

> If I can get a way with a simple regexp I will use it. If it starts getting complicated I would use something else.(e.g. top down parser or a combination) Isn't that what I said?

(If understood correctly) You based it in speed and memory efficiency. I rather base it on having something simple and readable.

Re: Perfect email regex finally found

#114
post #42
post #37

Earlier quoted context omitted.

Retyped!? Grown-ups can read what they write. Retyping only makes sense for password field, which is obfuscated and doesn't allow copy&paste.

I would estimate about 0.25% of people will make a typo like "@homail.com" or "@gmial.com" Multiply that by say, 130,000 people, and you are dealing with 325 people who don't receive their download, etc. and are not happy! I think what would be really awesome is a regex that catches these common typos and warns the user immediately.

To let users revisit their email addresses without adding a second field for copy-pasting, Russ Unger of UserGlue and Jonathan Knoll found a nice solution:

Display the email address on the submit button: http://www.userglue.com/blog/2009/09/09/solving-the-repeat-e...

Also try out the live examples: http://infinityplusone.com/experiments/email-repeat/version5

Regexes take care of the syntax. The semantics still have to be checked by a human.

Re: Perfect email regex finally found

#115
post #108
post #8

Not perfect: doesn't support IDN without punycode. Doesn't support IDN TLDs at all. Users of http://موقع.وزارة-الاتصالات.مصر won't be pleased :)

At the risk of sounding flip, not supporting punycode sounds like a feature. Getting internationalization right is clearly important, but punycode as a means of doing so? It's one of the many things that make me weep for my industry. In fact, I often wonder if punycode is a prank that got out of hand. UTF-8, on the other hand, would have been excellent for this purpose.

DNS doesn't allow 8-bit characters, so UTF-8 is not an option. I think punycode is more efficient than UTF-5 would be.

Re: Perfect email regex finally found

#116
post #76
post #63

Earlier quoted context omitted.

True, but you have to balance that against the small but nonzero number of people put off by an extra text field. Plus, I would find email repetition more annoying if I didn't always do Cmd-A/Cmd-C/Tab/Cmd-V, and in this case the repeated field won't catch any errors.

The fact that you know the shortcuts for select all, copy, and paste puts you in the top percentile of users. Most people don't even know that's possible, and certainly not with keyboard shortcuts. (The point being that for most users the faster approach that requires less thinking is to type it twice. Sometimes I do things the "slow" or "long" way when coding because it doesn't require a mental shift from the task a…

Copy & Paste are one of the most used menu items in Firefox (only bookmarks are used more):

http://blog.mozilla.com/faaborg/2010/03/23/visualizing-usage...

Re: Perfect email regex finally found

#117
post #115
post #108

Earlier quoted context omitted.

At the risk of sounding flip, not supporting punycode sounds like a feature. Getting internationalization right is clearly important, but punycode as a means of doing so? It's one of the many things that make me weep for my industry. In fact, I often wonder if punycode is a prank that got out of hand. UTF-8, on the other hand, would have been excellent for this purpose.

DNS doesn't allow 8-bit characters, so UTF-8 is not an option. I think punycode is more efficient than UTF-5 would be.

True. It doesn't. But as far as I know, there is no deep technical reason why it can't. The dots in domain names are '\0', and a few characters ('@', in particular) need to remain reserved, but other than that, what stops UTF-8 from being used?

Re: Perfect email regex finally found

#118
post #96

Wow. /^[-a-z0-9~!$%^&*_=+}{\'?]+(\.[-a-z0-9~!$%^&*_=+}{\'? ]+)*@([a-z0-9_][-a-z0-9_]*(\.[-a-z0-9_]+)*\.(aero|arpa| biz|com|coop|edu|gov|info|int|mil|museum|name|net|org| pro|travel|mobi|[a-z][a-z])|([0-9]{1,3}\.[0-9]{1,3}\. [0-9]{1,3}\.[0-9]{1,3}))(:[0-9]{1,5})?$/i I mean... Why do this? Just, why? It's almost unreadable. Just write a short 20-line function which validates an email address. Use if statements. Write c…

(late, but...)

Frequently because Perl's regex library is insanely fast. Faster than if statements + smaller regex / roll-your-own.

(as long as there's no look-ahead / look-behinds. It's still fast then, but custom functions can sometimes do better.)

Post reply on HN