101–110 of 132 posts
Breaks for: ^([^\W]+)@((?:[a-zA-Z0-9-]+\.)+(?:org|com|net|gov))$ Though this works: ^([^\W]+)@([a-zA-Z0-9-]+\.)+(?:org|com|net|gov)$ And it doesn't seem to be the nested groups that are screwing it up because this works: ((?:tinker|tailor)+(?:soldier|spy))
^(([a-z]+)+)$Earlier quoted context omitted.
BTW, using this regex to validate email is a bad idea. For one thing, it doesn't cover RFC5322. The only right way to do it, as far as I am concerned, is state machine code that evaluates the address character by character as well as DNS.
It is probably acceptable in most cases to just use a trivial regex to match the most likely 99.9% of addresses. 'something@something.something', maybe checking that last something for some sanity. I mean, obviously unless you are writing an MTA or whatever.
The first assumption is that your intent is to capture accurate user information and the user's intent is to give it to you.
With that established, it is a good idea to apply sensible measures at your end in order to ensure that the data is accurate.
Then there's the reduction of junk signups and the like. This is a case where your user doesn't necessarily have to know that you are validating. You can simply tag the signup as potentially invalid in the database and require human inspection or discard it if there's enough information to do so. In other words, the validation happens in the server and with no feedback to the client.
The RFC822 regex expression will pass something like this as valid:
joe @example.com
joe@ example .com
joe@example.ccom
joe@example.com-
joe@example.com----------------
joe@example.com/////
http://mythic-beasts.com/~pdw/cgi-bin/emailvalidate
I haven't done exhaustive testing on that particular expression. I don't really know where it fails. And that's part of the problem.
If the "contract" is that both parties want this information to be correct the user couldn't possibly be annoyed if you point out a legitimate error in the email address. You can prevent a situation where someone fills out a form, clicks "send" and goes away thinking that the signed-up when they actually didn't because they made a mistake entering their email address. What are you going to do? Send them an email?
Obviously, if they enter
jjoe@somedomain.com
joe@somedomain.com
So, yes, even with validation you are going to loose a few.
What you are going to catch are cases where the email is entered with detectable mistakes:
jot dot@somedomain.com
jotdot@@somedomain.com
jotdot@somedomain.com.
jotdot@ somedomain.com
jotdot@somedomain..com
jotdot@ somedomain.comm
etc.
jotdot@somedomain.com
While it is true that that super-large regex expression seems to validate most addresses correctly, there's a voodoo out there in the realm of regex for email validation. Buyer beware.
It would be gorgeous if upon clicking enter you'd be redirected to an URL that you could share with someone. Even better: make it directly a "tiny" URL. I realize that then some kind of a database would be needed but it would be really sweet.
Or, you know, a good old query string.
Earlier quoted context omitted.
No, stop validating emails. Not only it's error prone and will frustrate legit users but it utterly pointless.
The thing is, email input validation is only one use case for regex and emails. Here's a more sinister one: you want to build a web scraper looking for emails to add to your spam list. Put a bit more generically, you need a script that can import email addresses from a broad and unknown host of formats, and it is impractical to condition the data beforehand. I agree that the value derived from email validation for so…
No validation = Gone. You lost them. You can't email them for a correction.
With validation = You catch the issue before the visitor leaves and you ask them to fix it.
Sure, it doesn't verify the 1 to 1 relationship between the email and the person. That requires a round-trip verification. I get it. At least you ensure that it isn't all garbage-in to begin with.
The other aspect of email verification is that you don't have to choose to bug the user with the results. Depending on what it is, if someone enters an obviously junky address you can simply tag that email as potential crud in your database. Someone would then manually look at these every so often for cleanup or re-categorization.
I don't like the idea of looking signups or customers in a transaction where both parties are interested in transferring the information accurately. That's a use-case where validation works well.
Now, regarding your last name. The issue is cause by programmers who simply go around grabbing code off the internet without vetting it in any way. There are email "validation" regex expressions out there that are horribly wrong, yet people post them on blogs and others use them without question. It's unfortunate.
Earlier quoted context omitted.
It is probably acceptable in most cases to just use a trivial regex to match the most likely 99.9% of addresses. 'something@something.something', maybe checking that last something for some sanity. I mean, obviously unless you are writing an MTA or whatever.
In general terms I absolutely agree with you. However, the subtleties might have more to do with ensuring that the intent of the transaction is adhered to rather than not. The first assumption is that your intent is to capture accurate user information and the user's intent is to give it to you. With that established, it is a good idea to apply sensible measures at your end in order to ensure that the data is accurat…
Hello, I'm the creator of this (trevmex is one of my co-workers). I just want to thank everyone for the feedback so far, I am looking into the issues that have been brought up (they'll have to wait until this evening to be fixed though...I have a day job).
(?:[^\xFF\x0D]+|\x0D(?:\x0A|\x00)|\xFF(?:[\xFA\xFB\xFC\xFD\xFE].|\xFF|.))*
Nice. I wrote something similar a while back (with the goal to show lint errors): regexp.quaxio.com Note: if you type [b-a], you fail to say it's an invalid range.