Last active
March 27, 2024 16:24
-
-
Save dreamstarter/9231254 to your computer and use it in GitHub Desktop.
Javascript - Use a regex to check the email address input.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
function checkEmail(email) { | |
var reg = /^([A-Za-z0-9_\-\.])+\@([A-Za-z0-9_\-\.])+\.([A-Za-z]{2,4})$/; | |
if (!reg.test(email)) return false; | |
return true; | |
} |
(function a (email){
var emailRegex = /^([A-Za-z0-9_-.])+@([A-Za-z0-9_-.])+.([A-Za-z]{2,4})$/;
if(emailRegex.test(email)){
return "Valid Email"
}
else{
return "not a valid email"
}
})("[email protected]")
)
Hi, Guys. I used this regex and it helped validate any emails.
^(([^<>()\[\]\\.,;:\s@"]+(.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@(([[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}])|(([a-zA-Z-0-9]+.)+[a-zA-Z]{2,}))$
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a very basic regex email validator. it doesn't work for email addresses with special characters: !def!xyz%[email protected] and quoted emails: "Fred Bloggs"@example.com
Restrictions on email addresses (RFC 3696)
The exact rule is that any ASCII character, including control
characters, may appear quoted, or in a quoted string. When quoting
is needed, the backslash character is used to quote the following
character. For example
is a valid form of an email address. Blank spaces may also appear,
as in
The backslash character may also be used to quote itself, e.g.,
In addition to quoting using the backslash character, conventional
double-quote characters may be used to surround strings. For example
are alternate forms of the first two examples above. These quoted
forms are rarely recommended, and are uncommon in practice, but, as
discussed above, must be supported by applications that are
processing email addresses. In particular, the quoted forms often
appear in the context of addresses associated with transitions from
other systems and contexts; those transitional requirements do still
arise and, since a system that accepts a user-provided email address
cannot "know" whether that address is associated with a legacy
system, the address forms must be accepted and passed into the email
environment.
Without quotes, local-parts may consist of any combination of
alphabetic characters, digits, or any of the special characters
period (".") may also appear, but may not be used to start or end the
local part, nor may two or more consecutive periods appear. Stated
differently, any ASCII graphic (printing) character other than the
at-sign ("@"), backslash, double quote, comma, or square brackets may
appear without quoting. If any of that list of excluded characters
are to appear, they must be quoted. Forms such as
Klensin Informational [Page 6]
RFC 3696 Checking and Transformation of Names February 2004
are valid and are seen fairly regularly, but any of the characters
listed above are permitted. In the context of local parts,
apostrophe ("'") and acute accent ("`") are ordinary characters, not
quoting characters. Some of the characters listed above are used in
conventions about routing or other types of special handling by some
receiving hosts. But, since there is no way to know whether the
remote host is using those conventions or just treating these
characters as normal text, sending programs (and programs evaluating
address validity) must simply accept the strings and pass them on.
In addition to restrictions on syntax, there is a length limit on
email addresses. That limit is a maximum of 64 characters (octets)
in the "local part" (before the "@") and a maximum of 255 characters
(octets) in the domain part (after the "@") for a total length of 320
characters. Systems that handle email should be prepared to process
addresses which are that long, even though they are rarely
encountered.