Как проверить адрес электронной почты в JavaScript

Как проверить адрес электронной почты в JavaScript

Регулярное выражение для проверки адреса электронной почты в javascript?

Показать лучший ответ

пожалуйста, поймите это правильно, слишком многим веб-сайтам не нравится мой адрес электронной почты "firstName@secondName.name", не все домены верхнего уровня заканчиваются на 2 или 3 буквы.

Тот факт, что слабое сопоставление с образцом в Javascript не позволяет полностью проверить RFC-совместимый почтовый адрес, не означает, что вы никогда не сможете решить эту проблему с помощью одного шаблона. На самом деле, вы можете, и здесь есть два решения , которые делают это.

Любая поддержка использования проверок регулярных выражений для электронных писем я против 100%. Я устал от того, что мне сказали, что мой адрес электронной почты "foo+bar@gmail.com" недействителен. Лучший вариант - попросить пользователя ввести свою электронную почту дважды, и если вы ДОЛЖНЫ использовать проверку на регулярные выражения, то скажите пользователю, что его адрес электронной почты не является действительным, и спросите, уверены ли они, что он его напечатал. верно. Даже зайдите так далеко, чтобы указать, ЧТО не проверялось в проверке регулярных выражений, но НЕ мешайте им отправлять форму.

Аватар WoJ

@ Soundfx4: это должен быть ответ, принятый как таковой. Проверка правильности адреса - это глупая вещь - лучший способ разочаровать клиентов. Я прошу, чтобы адрес был напечатан дважды, и намекаю, что есть некоторые возможные проблемы (отсутствуют @ , ;com и т. Д.), И позволяю пользователю исправить их, если они пожелают (и принять все, что угодно). они отправляют меня)

Я полностью согласен с ответом WoJ. Формат действующего адреса электронной почты слишком сложен, чтобы его можно было проверить с помощью простого регулярного выражения. Единственный способ убедиться, что адрес действителен, это попробовать.

шаблон = "[A-Za-z0-9 ._% + -] + @ (?:. [A-Za-Z0-9 -] + \) + [A-Za-Z] {2,4} «Мне кажется, это не так уж и плохо (« 4 »должно было быть обновлено много лет назад). Но я согласен, что говорить людям, что они не знают своего собственного адреса, плохо. Не так плохо, как сказать мне, что я не знаю своего собственного имени, что также произошло!

Вам действительно нужен Javascript для этого (чего не следует делать)? Хотя в этом выражении было две ошибки, мне кажется, более простой метод был упомянут в stackoverflow.com/questions/52030222/…

JavaScript может соответствовать регулярному выражению:

 emailAddress.match( / some_regex /);
  

Вот RFC22 регулярное выражение для электронных писем:

 ^((?>[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+\x20*|"((?=[\x01-\x7f])[^"\\]|\\[\x01-\x7f])*
"\x20*)*(?<angle><))?((?!\.)(?>\.?[a-zA-Z\d!#$%&'*+\-/=?^_`{|}~]+)+|"((?=[\x01-\x
7f])[^"\\]|\\[\x01-\x7f])*")@(((?!-)[a-zA-Z\d\-]+(?<!-)\.)+[a-zA-Z]{2,}|\[(((?(?<
!\[)\.)(25[0-5]|2[0-4]\d|[01]?\d?\d)){4}|[a-zA-Z\d\-]*[a-zA-Z\d]:((?=[\x01-\x7f])
[^\\\[\]]|\\[\x01-\x7f])+)\])(?(angle)>)$
  

Узел не может скомпилировать это регулярное выражение

Аватар Ry-

@Kato: он использует несколько несовместимых расширений, в том числе (?> для остановки возврата и (?<angle><)…(?(angle)>) , чтобы избежать предоставления длинного | .

Использование регулярных выражений , вероятно, является наилучшим способом. Вы можете посмотреть несколько тестов здесь (взяты из

Вот пример регулярного выражения, принимающего Unicode:

 var re = /^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()[\]\.,;:\s@\"]+\.)+[^<>()[\]\.,;:\s@\"]{2,})$/i;
  

Но имейте в виду, что нельзя полагаться только на валидацию JavaScript. JavaScript можно легко отключить. Это также должно быть проверено на стороне сервера.

Вот пример вышесказанного в действии:

 function validateEmail(email) {
  var re = /^(([^<>()[\]\\.,;:\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,}))$/;
  return re.test(email);
}

function validate() {
  var $result = $("#result");
  var email = $("#email").val();
  $result.text("");

  if (validateEmail(email)) {
    $result.text(email + " is valid :)");
    $result.css("color", "green");
  } else {
    $result.text(email + " is not valid :(");
    $result.css("color", "red");
  }
  return false;
}

$("#validate").on("click", validate);  
 <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>

<form>
  <p>Enter an email address:</p>
  <input id='email'>
  <button type='submit' id='validate'>Validate!</button>
</form>

<h2 id='result'></h2>  

Аватар Jon

Может ли кто-нибудь объяснить, с чем это будет и не будет совпадать? (Учитывая некоторые дополнительные ответы ниже.) Было бы неплохо узнать немного больше информации, чтобы определить, какое «решение» использовать для проекта.

+1: Единственное, что не пропустит это IP-адреса, а не домены. Он принимает домены, начинающиеся или заканчивающиеся дефисом, и домены длиной более 64 символов, но кроме этого он выполняет достаточно хорошую работу. Приветствия.

Это регулярное выражение исключает действительные, используемые электронные письма. Не использовать. Google для "RFC822" или "RFC2822", чтобы получить правильное регулярное выражение.

@Randall: Можете ли вы привести пример адреса электронной почты, который не будет пропущен?

Это хорошо работает для меня, хотя я получаю ошибку компилятора (unescaped '[') при использовании его с Appcelerator. Однако, похоже, не вызывает проблем с проверкой.

Обратите внимание, что любые IDN должны быть заштрихованы, прежде чем это регулярное выражение примет их; любые допустимые IDN верхнего уровня будут отклонены даже в форме punycode (так как префикс xn- не будет совпадать с [a-zA-Z] ).

Почему в строке var re = ... ESLint говорит: Escaped ']', unescaped '[', пробелы трудно сосчитать, используйте {2}?

Полный тестовый пример адресов электронной почты находится по адресу isemail.info/_system/is_email/test/?all ... (подробнее см. isemail.info ).

Внизу этой страницы есть раздел о проверке RFC2822: normal-expressions.info/email. HTML

Аватар P.M

a.ert#@example.com проходит :-)

Это даже не принимает примеры в RFC 822. В некоторых простых случаях это не соответствует a \ @ b @ c.com, a(b)@c.com. Смотрите RFC для получения дополнительной информации. Вот регулярное выражение, которое не отклоняет допустимые адреса [^ @] + @ [^ @] + \. [^ @] + И защищает от распространенных ошибок.

@BenRoberts n @ ai - действительный адрес электронной почты, он не работает

@GoodPerson Я просто попытался написать по электронной почте n @ ai, чтобы сказать ему / ей, что у них есть классный адрес электронной почты. Но, увы, Gmail не позволил бы мне. Я подозреваю, что у кого бы то ни было, есть большие проблемы в общении с другими по электронной почте, чем просто проверка JavaScript моего сайта! Но спасибо, что приняли вызов.

Мне интересно, почему, когда я ввел lname_fname#@yahoo.com, он принял письмо? Значение "#" разрешено?

Это решение кажется хорошим для большинства носителей английского языка, но оно не проходит тестирование в Турции (см. Джоэл Спольски). Допускается большинство писем в Юникоде, и, например, в Аргентине такие адреса, как «ñoñó1234@server.com», вполне нормальны. joelonsoftware.com/articles/Unicode.html

Подчеркивание (_) должно быть проверено на первом месте, я думаю.

Примерами действительных адресов электронной почты, которые помечены как недействительные, являются postbox @ com и user @ [IPv6: 2001: db8: 1ff :: a0b: dbd0], см. en.wikipedia.org/wiki/Email_address#Valid_email_addresses

@Ben это стандартный встроенный метод в регулярном выражении. developer.mozilla.org/en-US/ документы / Web / JavaScript / Справочник / ...

Это относится к ı@a.aa (этот первый символ странный), который недавно испортил нашу систему.

@rossipedia пример действительных почтовых адресов, которые он не анализирует? например: !#$%&'*+-/=?^_`{}|~@example.org , или postbox@com , или " "@example.org , взятые из википедия

Для всех людей, комментирующих, что это «достаточно хорошо»: смотрите, вы просто думаете об этой проблеме неправильно. Все нормально. Это выбор, который вы можете сделать для своих пользователей. Я не злюсь на это. Но, вы знаете, технически говоря, вы демонстративно, доказуемо неправы.

его сломали для nhjh@d.vn.hjhhhkkk :(

Вы не можете проверить адреса электронной почты, точка. Единственный, кто может подтвердить адрес электронной почты, является поставщиком адреса электронной почты. Например, в этом ответе говорится, что все эти адреса электронной почты: %2@gmail.com, "%2"@gmail.com, "a..b"@gmail.com, "a_b"@gmail.com, _@gmail.com, 1@gmail.com , 1_example@something.gmail.com действительны, но Gmail никогда не разрешит использование этих адресов электронной почты. Вы должны сделать это, приняв адрес электронной почты и отправив сообщение на этот адрес электронной почты с кодом / ссылкой, которую пользователь должен посетить, чтобы подтвердить действительность.

Для получения дополнительной информации о том, что он (в) правильно соответствует, см. Следующий список emailtester.pieterhordijk.com/test -pattern / MTA4

@BenRoberts MyFakeEmail@dnedomain.com не существует. И все же регулярное выражение пропустит это.

Согласно википедии, юникод может существовать и в доменном имени. var re = ...|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/; должно быть var re = ...|(([^<>()[\]\\.,;:\s@\"]+\.)+[a-zA-Z]{2,}))$/;

Это подтверждает: "foo@10.0.0.0.com"

Существуют и другие факторы, помимо RFC822, при определении того, каким может быть адрес электронной почты - например, a@a является действительным RFC822, но домены «без точек» запрещены ICANN, поэтому его следует считать недействительным.

Если вам нужно использовать это с HTML5 Pattern API вместо использования type="email" , вам нужно будет кодировать кавычки, например, так. <input pattern="^(([^<>()[\]\\.,;:\s@\&quot;]+(\.[^<>()[\]\\.,;:\s@‌​\&quot;]+)*)|(\&quot‌​;.+\&quot;))@((\[[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,})‌​)$" id="email" name="email" type="text">

В наши дни Javascript можно запускать на сервере, поэтому для тех, кто думает, что это имеет отношение только к проверке на стороне клиента, вы ошибаетесь. И тем, кто говорит, что проверить электронную почту невозможно, я полагаю, что вы упустили смысл проверки в целом. ВЫ НИКОГДА НЕ ПИШИТЕ валидацию формы, чтобы убедиться, что все идеально на 100% по двум основным причинам: 1. Это займет больше времени, чем стоило бы написать логику, и 2. Всегда будет крайний случай, когда плохие данные может быть представлен. Причина, по которой мы проверяем, заключается в поощрении правильной подачи данных и предотвращении ошибок.

это терпит неудачу для 'ajey@gmail.comsadasd'

Осторожно, это неверно: re.test("username+something@gmail.com")

Также недействительно: test@something.melbourne и другие новые TLD.

김지후 @ 삼성. Here здесь не будет работать, равно как и новые адреса не из латинского алфавита.

это недействительно для test + google.com re: должно быть: var re = / ^ (([^ <> () [] \\.,;: \ 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,})) $ /;

Теперь, когда у нас есть домены, такие как .ninja .photography и т. Д., Я бы добавил {2,} к последней проверке: /^([\w-]+(?:\ .[\w-]+)*)@ ((?:. [\ ш -] + \) * \ ш [\ ш -] {0,66}) \ ([AZ] {2,} (:.?. \ [AZ] {2} )?) $ / я

Тест @BenRoberts \\\ @ mailinator.com не учитывается этим регулярным выражением :(

@Brian - Gmail и Apple Mail тоже оставляют беднягу в покое ... :(

Очевидно, что вы не можете проверить адрес электронной почты с помощью JavaScript или RegEx. Но я думаю, что ответ демонстрирует: «Вот несколько верный способ сказать, является ли путаница символов, введенных в текстовое поле электронной почты, наиболее вероятным форматом электронной почты. Я думаю, что это дает человеку, который задаст этот вопрос достаточно для работы. Если они на самом деле, проверяя турецкую электронную почту, они должны понимать ее пределы, в противном случае, используйте ее, пока не столкнетесь с трудностями и не выполните итерацию, как любой другой программист!

Аватар PSR

Эта проверка не пройдена для идентификаторов электронной почты псевдонимов Gmail, например: firstname.lastname+test@gmail.com

Этот ответ не принимает действительное письмо от gmail, например "foo+bar@gmail.com"

Любая поддержка использования проверок регулярных выражений для электронных писем я против 100%. Я устал от того, что мне сказали, что мой адрес электронной почты "foo+bar@gmail.com" недействителен. Лучший вариант - попросить пользователя ввести свою электронную почту дважды, и если вы ДОЛЖНЫ использовать проверку на регулярные выражения, то скажите пользователю, что его адрес электронной почты не является действительным, и спросите, уверены ли они, что он его напечатал. верно. Даже зайдите так далеко, чтобы указать, ЧТО не проверялось в проверке регулярных выражений, но НЕ мешайте им отправлять форму.

Что касается «не проверять» - первое регулярное выражение выбрасывает около половины этого: ru. wikipedia.org/wiki/… , например piskvor@example.lighting ; обратите внимание, что с 2011 года было создано больше ДВУ, превышающих размер \.[a-z]{2,8} . (Это список утвержденных IANA ДВУ; мне все равно, считает ли кто-то .horse несерьезным, меня интересует только это канонично - и это так). Редактировать: Ага, я вижу, что регулярное выражение было полностью изменено в марте.

это регулярное выражение использует группы захвата, причем в этом контексте они не нужны и могут привести к проблемам с производительностью.

Попробуйте 1.2@gmail.com . регулярное выражение будет соответствовать :(

регулярное выражение также соответствует d^&fvf#3d@frf.fffffefefe , которое, как я полагаю, не является действительным идентификатором электронной почты?

stream@2x-fab0f8.png = true :)

me's@mess.co.uk.in is valid :) это должно быть?

Это выражение следует обновить, чтобы оно не учитывало адреса электронной почты с использованием ip-адресов вместо доменных имен, даже если они технически правильны.

@ AndersLindén Использование приведенной ниже ссылки для модульного тестирования и, если IP-адрес недействителен, также следует учитывать, что не соблюдается следующее: электронная почта @ [123.123.123.123] codefool.tumblr.com/post/15288874550/…

@nwolybug Вариант использования наличия ip-адресов как части адресов электронной почты настолько узок, что его следует опустить.

--@ooo.ooo это действующий адрес электронной почты.

Не работает для Abc@10.42.0.1 и Loïc.Accentué@voilà.fr

@Liberateur Как и должно быть. voilà.fr не является допустимым именем домена. В частности, à должен быть закодирован с помощью punycode в имени домена. Я не знаю фактическую кодировку punycode, но что-то вроде Loïc.Accentué@voil--xa.fr будет проверяться ... как и должно быть.

Я сделал что-то не так: new RegExp ('^ (([^ <> () [] \.,;: \ S @ \ "] + (\. [^ <> () [] \. ‌,; : \ s @ \ "] +) *) | (\" + \ ")) @ (([^ <> () [] \,;: \ s @ \.".] + \. ) + [^ <> () ‌ [] \.,;: \ S @ \ "] {2, ‌}) $ ',' i '). Test ('test@test.com') return false ?

Это недопустимое регулярное выражение, например, æææ@gmail.com передать регулярное выражение

Не работает с findEmailInStr ("sdf ll \ ud83c \ uddeb \ ud83c \ uddf7email@gmail.com sdkf")

@ AndersLindén - В: Что хуже, чем код с ошибками, говорящий людям, что они не знают своего собственного адреса? A: Говорить кому-либо, что он / она должен НАМЕРЕННО отклонить действительные адреса.

все эти узоры показывают красную волнистую линию под некоторыми символами. Почему?

Спасибо за вашу долю, но ваш код не является стандартным для "RFC822" или "RFC2822".

Это регулярное выражение отклоняет действительные адреса электронной почты на интернационализированном доменном имени.

Я настоятельно рекомендую использовать регулярное выражение, предложенное WDC html.spec. .whatwg.org / многостраничный / input.html # действительный-электронной почты обратить внима сс

Вау, здесь много сложностей. Если все, что вы хотите сделать, это просто поймать наиболее очевидные синтаксические ошибки, я бы сделал что-то вроде этого:

 ^\S+@\S+$
  

Обычно он улавливает наиболее очевидные ошибки, которые совершает пользователь, и заверяет, что форма в основном правильная, и в этом вся суть валидации JavaScript.

+1, так как отправка электронной почты и просмотр того, что происходит, - это единственный реальный надежный способ проверки адреса электронной почты, нет необходимости делать больше, чем простое совпадение с регулярным выражением.

Модифицированная версия Squirtle, представленная ниже, кажется наиболее эффективным решением на странице. Вы можете проверить все, что вы хотите, но я все еще могу ввести адрес электронной почты "@ gmaaaail.com".

Вы все еще можете сделать это простым, но сделайте немного больше, чтобы убедиться, что у него есть "." где-то после @, за которым следуют только цифры или цифры, поэтому такие вещи, как я @ здесь, я @ здесь @ и я @ herecom, недопустимы ... ^ \ S + @ \ S + [\.] [0-9a-z ] + $

Аватар Sam

Я думаю, что адреса электронной почты могут содержать пробелы. Вероятно, лучше использовать .+@.+

/\S+@\S+/.test("áéíóúý@ÁÉÍÓÚÝð") true

@gtournie Никому нет дела. Никто не собирается вводить это в поле электронной почты случайно , и это все, что требуется для проверки внешнего интерфейса: для предотвращения случайного ввода неправильным битом информации, такой как их имя, в поле электронной почты.

@ MladenJanjetović Да, в ответе конкретно говорится, что это не полный вопрос. Это, однако, лучший ответ. Никто не нуждается в "полной" проверке электронной почты на внешнем интерфейсе. Вы должны поймать очевидные опечатки, а затем отправить подтверждение по электронной почте.

@meagar Вы можете быть уверены, что люди делают такие ошибки;)

@TimmyFranks Плохое регулярное выражение. Помимо второстепенной точки вам не нужно экранировать точку в скобках, вы отменяете действительные символы в верхнем регистре, так что вы получите злых пользователей (мне, как мне нравится использовать их, когда я пишу свои адреса!) ... Рядом, это слишком ограничительно, так как foo @ [192.168.1.12] является действительным адресом электронной почты ...

@TimmyFranks На более позитивной ноте вы правы в замечании о @ b @ (опечатка, которая может произойти) и в привязке регулярного выражения. Улучшение (все еще очень благоприятное) будет /^.+@\S*(?!@).$/ . Точка даже не требуется: адрес в локальной сети может быть foo @ machinename (у нас есть этот случай в нашей сети!).

Это так раздражает, что всякий раз, когда вы запускаете проверку электронной почты, у вас 99% людей теряют контроль над тем, как неправильно использовать регулярные выражения и т. Д. Люди, мы не пытаемся выяснить, является ли это реальным адресом электронной почты! Мы пытаемся определить, правильный ли синтаксис!

| _ @ _ | - действительный адрес электронной почты?

В то время как я люблю простоту как подход «проверки смысла», просто замечание, заключающееся в том, что обертывание ее с ^ ... $ следующим образом ^ \ S + @ \ S + $, является улучшением вышеупомянутого - поскольку для соответствия требуется весь почтовый адрес, не только часть этого.

Небольшая модификация, чтобы охватить больше случаев, таких как "asd @ asd" \S+@{1}\S+\.{1}\S+

@meagar ("áéíóúý @ ÁÉÍÓÚÝð") так можно вводить в текстовое поле при использовании клавиш клавиатуры.

/\S+@\S+/ тоже работает с пустыми полями ... ничего хорошего!

Вам нужно кое-что понять, когда вы решите использовать регулярное выражение для проверки писем: Вероятно, это не очень хорошая идея . Как только вы с этим согласитесь, существует множество реализаций, которые могут помочь вам на полпути, это статья подводит их итог.

Короче говоря, единственный способ быть абсолютно уверенным в том, что введенное пользователем на самом деле является электронным письмом, - это отправить электронное письмо и посмотреть, что произойдет. Кроме этого все это только догадки.

-1 Зачем мне тратить время на проверку адреса электронной почты, который даже не проходит через регулярное выражение?

@PaoloBergantino Я имею в виду, зачем мне пытаться отправить письмо, чтобы проверить явно неправильный почтовый адрес? даже если мне нужно «быть абсолютно уверенным в том, что введенное пользователем на самом деле является электронным письмом», я проверю только те адреса электронной почты, которые соответствуют регулярному выражению

@kommradHomer - неверный адрес регулярного выражения почти всегда действителен, потому что любое регулярное выражение, которое вы используете для проверки адреса электронной почты, почти наверняка неверно и исключит действительные адреса электронной почты. Адрес электронной почты: name_part@domain_part , и практически все, включая @ , допустимо в name_part; Адрес foo@bar@machine.subdomain.example.museum является допустимым, хотя он должен быть экранирован как foo\@bar@machine.... . Как только электронная почта достигает домена, например «example.com» этот домен может маршрутизировать почту «локально», поэтому могут существовать «странные» имена пользователей и хостов.

Второе регулярное выражение в ответе Вояджера в stackoverflow.com/a/1373724/69697 практично для использования и не должно иметь почти никакого ложного негативы. Я согласен с @kommradHomer здесь - зачем отправлять электронную почту, если вам не нужно? Я могу понять рефлексивную неприязнь к непонятным регулярным выражениям и желание сохранить код простым, но это пара строк кода, которые могут спасти ваш сервер от многих проблем, немедленно отсеивая элементы, которые определенно недействительны. Регулярное выражение само по себе бесполезно, но служит хорошим дополнением к проверке на стороне сервера.

@ StephhenP прав. Практически невозможно найти регулярное выражение, которое будет соответствовать всем действительным электронным письмам. Плюс форматы адресов электронной почты могут меняться.

@kommradHomer - "зачем мне тратить время на проверку ..."? Тратить свое время? Конечно нет, глупо! Вы бы написали код, чтобы сделать это для вас. И тогда вы на самом деле знаете, если у вас есть действительный адрес без риска отчуждения пользователей. Это круто! Или вы можете дуться и демонстративно использовать сломанный раствор. Я не злюсь на это. Они ваши пользователи.

@StephenP «Недопустимый адрес регулярного выражения» почти всегда действителен, потому что любое регулярное выражение, которое вы используете для проверки адреса электронной почты, почти наверняка неверно и исключит действительные адреса электронной почты. «Я считаю этот аргумент логически ошибочным. Люди вводят в формы всевозможные недействительные вещи.

@dmur Я признаю, что «почти всегда действительный», вероятно, преувеличивает, но мои адреса электронной почты (совершенно действительные и работающие) слишком часто отклоняются веб-сайтами только потому, что у меня есть домен .us или потому, что Я использовал + слева от @ - во многих местах исправлены эти вопиющие ошибки, но локальная часть (слева от @) может быть чем угодно владелец домена хочет. -> "foo@bar.com"@example.com <- это действующий адрес электронной почты.

Нет ли абсолютно никакого способа узнать, является ли адрес электронной почты действительным, не отправляя письмо? Существует ли какая-либо централизованная регистрация в DNS, где накапливаются все используемые адреса электронной почты, и, таким образом, можно запрашивать наличие определенного адреса электронной почты?

@Cupidvogel: Увы, мы не живем в этом мире.

@ AttitudeMonger - такая база данных может содержать от миллиардов до миллиардов адресов электронной почты, поэтому поиск будет медленным. Также нет способа обеспечить регистрацию адресов электронной почты для поддержания актуальности реестра, а также для пользователей, чтобы гарантировать, что их адрес электронной почты был зарегистрирован. Таким образом, любой такой центральный реестр потерпит неудачу и в конечном итоге будет хуже, чем регулярное выражение (или просто отправка электронного письма и проверка его доставки, и вы получите ответ).

@kommradHomer "Неверный адрес регулярного выражения - это% 100 неверный адрес." Простите ... извините? Знаете ли вы, сколько раз мне говорили, что foo+bar@gmail.com НЕ является действительным электронным письмом, хотя на самом деле ЭТО СОВЕРШЕННО ДЕЙСТВИТЕЛЬНО ?! Ваша логика крайне ошибочна. Я отправил формы с электронными письмами в следующем виде: thisisafakeemailbutitwillpassyourstupidregexcheck @ regexcheck‌ sareretarded.com И угадайте, что? Это проходит проверку REGEX ... но это НЕ действительный адрес электронной почты (хотя технически это так, но я обещаю, что его не существует ... пока <я> царапает его подбородок ). Как уже говорили многие, это плохая идея ...

Я думаю, что в этом обсуждении отсутствует различие между синтаксически действительным адресом электронной почты и тем, который фактически получает почту. Еще одна вещь, которую мы упускаем из виду, это то, что на самом деле существует техническая спецификация того, что считается действительным адресом электронной почты. Проблема заключается в том, что большинство веб-сайтов создают свою собственную логику проверки, основанную на некоторых наивных предположениях, а не в соответствии с требованиями.

Извините, но это не очень хороший ответ. -1 "и посмотрим что получится"? Как вы узнаете, получил ли пользователь электронное письмо или нет? Кроме того, что-то может быть синтаксически действительным письмом, даже если никто не владеет почтовым ящиком с таким адресом. Кроме того, если вы проверяете пользовательский ввод, вы не должны выполнять медленные сетевые вызовы как часть проверки. Плюс ....

Это отфильтровывает постоянно популярные домены .museum и .travel (из-за ограничения в 4 символа после . )

Изменение {2,4} на {2,6} не будет проблемой

@Anton N: у него есть еще около миллиарда других проблем; окончательный {2,4} является всего лишь его полезным индикатором (например, «когда вы видите эту ошибку, другие могут быть рядом»). самый простой один - отсутствие + в локальной части; это поле для комментариев слишком маленькое, чтобы указать на все ошибки, допущенные выше.

Аватар MT.

Почему ты не можешь просто сделать return filter.test(email.value); ?

@Piskvor - после добавления + и удаления в конце избыточной обратной косой черты и того же плюса я не могу найти в этом ничего плохого. Посмотрите эту демонстрацию: codepen.io/anon/pen/lzJtB?editors=100. Если вы все-таки найдете какие-либо недостатки, я буду рад узнать, какие.

@FrankConijn: Ну, для начала - внимательно посмотрите на этот список, а затем скажите мне: как, например, это регулярное выражение будет рассматривать адреса в сингапурском TLD (.新加坡 ) как допустимые? en.wikipedia.org/wiki/List_of_Internet_top-level_domains Это не Интернет вашего деда Больше; и даже интернет вашего дедушки позволил намного, намного расширить круг символов в локальной части. Другими словами, это регулярное выражение слишком строго и будет сообщать о ложных отрицаниях на полностью действительных адресах электронной почты.

@AntonN: теперь у нас есть 10+ TLD (xn--clchc0ea0b2g2a9gcd ). Все еще не проблема?

Мне это нравится больше: var re = /^[0-9a-zA-Z.,+\-_]+@[0-9a-zA-Z.\-]+\.[a-zA-Z]+$/; Для меня, если адрес электронной почты содержит символы Юникода, это в значительной степени указывает на ошибку. (также я из не родной англоговорящей страны, поэтому я сталкиваюсь с такими ошибками ежедневно). Так что неплохо бы отфильтровать акцентированные символы.

Это позволяет: tes.t. @ example.com

/^[a-zA-Z0-9]([a-zA-Z0-9_\.\-])+[a-zA-Z0-9]\@(([a-zA-Z0-9\- ] ‌) + \.) + ([A-zA-Z0-9] {2‌, 6}) + $ / недопустимо: tes.t. @ example.com или .tes.t. @ example.com

Следующее регулярное выражение:

 /^([\w]+)(.[\w]+)*@([\w]+)(.[\w]{2,3}){1,2}$/;
  

Это не соответствует RFC.

Трудно получить валидатор электронной почты на 100% правильно. Единственный реальный способ исправить это - отправить тестовое электронное письмо на аккаунт. Тем не менее, есть несколько основных проверок, которые помогут убедиться, что вы получаете что-то разумное.

Некоторые вещи для улучшения:

Вместо нового RegExp просто попробуйте написать regexp следующим образом:

 if (reg.test(/@/))
  

Во-вторых, убедитесь, что точка стоит после знака @ , и убедитесь, что между символами @ и точками есть символы.

Просто для полноты, здесь у вас есть еще одно регулярное выражение, соответствующее RFC 2822

  

Официальный стандарт известен как RFC 2822 . Он описывает синтаксис, которому должны соответствовать действительные адреса электронной почты. Вы можете (, но не должны - читать ) реализовать это с помощью этого регулярного выражения:

     

(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])

     

(...) Мы получим более практическую реализацию RFC 2822, если мы опустим синтаксис, используя двойные кавычки и квадратные скобки. Он по-прежнему будет совпадать с 99,99% всех адресов электронной почты, используемых сегодня.

     

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?

     

Еще одно изменение, которое вы можете внести, - разрешить использование любого двухбуквенного домена верхнего уровня с кодом страны и только определенных общих доменов верхнего уровня. Это регулярное выражение фильтрует фиктивные адреса электронной почты, например asdf@adsf.adsf . Вам потребуется обновить его по мере добавления новых доменов верхнего уровня .

     

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+(?:[A-Z]{2}|com|org|net|gov|mil|biz|info|mobi|name|aero|jobs|museum)\b

     

Таким образом, даже при соблюдении официальных стандартов все же приходится идти на компромиссы. Не копируйте вслепую регулярные выражения из онлайн-библиотек или дискуссионных форумов. Всегда проверяйте их на своих данных и в своих собственных приложениях.

Акцент на шахте

NB: «При фактическом использовании сегодня », возможно, был действительным, когда код был написан, еще в 200 раз. Код будет , вероятно, использоваться в течение указанного года. (Если бы у меня было десять центов на каждое «ме, никто бы никогда не использовал ДВУ с 4 + буквами, кроме тех, которые мне приходилось исправлять», я мог бы загнать в угол мировой рынок меди и никеля;))

Для практической реализации RFC 2822 окончание должно быть немного изменено, чтобы не допустить расширения одного символа в домене. / [! А-z0-9 # $% & '* + \ / = ^ _ {|}~-]+(?:\.[a-z0-9!#$%&'*+\/=?^_ {|} ~ -] +) * @ (?: [А-z0-9] (?: [а-z0-9 -] * [а-z0-9]?). \) + [а-z0-9] [а-z0-9-] * [a- z0-9] /

Кроме того, первая часть должна быть (?: [A-z с заглавной буквы A, чтобы избежать ложных отрицаний, когда пользователь вводит заглавные буквы своего адреса электронной почты.

Используя «практическую реализацию», я столкнулся с проблемой в Safari: если часть адреса, соответствующая после @ , составляет 32 символа или более, тест регулярного выражения не пройден. Это связано с ограничением синтаксического анализатора webkit: github.com/WebKit/webkit/blob/master/Source/JavaScriptCore/... . Обратите внимание, что это только в случае определения регулярного выражения следующим образом: var email_re = new RegExp("[a-z ...0-9])?", "i"); (в отличие от var email_re = new RegExp(/[a-z ...0-9])?/i); Добавление дополнительного экранирующего кода \` before each .` также устраняет проблему. + + @ Cal за предложение этого решения!

В спецификации d._.___d@gmail.com не является действительным адресом электронной почты, но он все равно обнаруживает, что он правильный

@ DonRolling Не делай этого. Это не просто означает «от А до Я, от а до я», это также означает «[\] ^ _` », потому что это между " Z "и" a ". Используйте \w или, что лучше, просто введите адрес электронной почты в нижнем регистре, прежде чем что-либо делать с ним, так как в любом случае это соглашение.

Я использую этот со следующей модификацией: [a-z0-9! # $% & '* + / =? ^ _ {|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_ {|} ~ -] +) ‌ * @ (? : [а-z0-9]: - \) + (([A-Z 0-9] * [а-z0-9]?):?.? [A-Za-Z] {2} | com | o‌ rg | net | gov | mil | biz | i‌ nfo | mobi | name | aero | j‌ obs | museum) \ b Добавлена ​​модификация az для окончания, чтобы разрешить .au, .it и многие верхние уровни домены страны, которые используют два символа нижнего регистра. Я хотел бы знать, почему это не было включено.

@willFarrell, кроме предотвращения односимвольных доменов верхнего уровня (somebody@example.c), не должны ли мы также запретить односимвольные домены (somebody@e.com)? это дает [a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]‌​+)*@(?:[a-z0-9][a-z0‌​-9-]*[a-z0-9]\.)+[a-‌​z0-9][a-z0-9-]*[a-z0‌​-9] Кроме того, будьте осторожны в том, что уценка делает с вашим регулярным выражением, оно съело некоторые из ваших обратных кавычек ("` ")! Также ваш @nwolybug!

Второе регулярное выражение "соответствует 99,99%" не запрещает me@domain.fr. или .me@domain.fr , что может быть простой ошибкой при наборе и недопустимо, если точка "появляется как первый или последний символ " верно?

«Вам нужно будет обновить его по мере добавления новых доменов верхнего уровня». Что ж, так много сейчас - существует более 1500 признанных доменов верхнего уровня.

Я обнаружил, что должен был изменить все a-z на a-zA-Z.

@MadeInMoon Также не запрещает пробелы и множественные знаки @. asdasd asdasd @asdasd@gmail.com действителен

Это позволяет использовать пробелы, подобные следующей строке: sdf @ fdsfsdf sdfsdfdf @ klk@com.c

позволяет %20f3v34g34@gvvre.com? Я не думаю, что это действительно, чтобы начать с%

Средний не разрешает локальные адреса: P hello@localhost = false

Хороший ответ. Я думаю, что практическая реализация RFC 2822 лучше всего подходит для проверки регулярных выражений. Потому что только поставщик услуг электронной почты может сказать, что адреса электронной почты действительны или нет. То, что мы можем сделать с помощью регулярных выражений, это проверка общих проверок. Никто не может на 100% проверить все адреса электронной почты с помощью регулярных выражений. Потому что у разных почтовых провайдеров разные методы проверки.

Вот очень хорошее обсуждение использования регулярных выражений для проверки адресов электронной почты; " Сравнение адресов электронной почты, проверяющих регулярные выражения "

Вот текущее верхнее выражение, совместимое с JavaScript, для справочных целей:

 /^[-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
  

-1 Белый список оставляет желать лучшего - в частности, вы пропустили .jobs . Кроме того, существуют живые IDN (большинство из которых, я признаю, были официально одобрены только после вашего поста - например, .中國 в июне 2010 года; но большинство работали годами).

-1 не используйте постоянные домены верхнего уровня. Там всегда (и будет, например, 2013) могут быть добавлены новые TLD.

Подтверждено 100 новых TLD. Этот ответ недействителен и никогда не должен использоваться.

Ага. Я сказал это в 2011 году и скажу еще раз: белый список «специальных» доменов со временем будет только ухудшаться, так как будет одобрено больше ДВУ. Существует более 100 полностью действительных доменов верхнего уровня, не соответствующих вышеуказанному белому списку: en.wikipedia.org/wiki/List_of_Internet_top -level_domains

Это 2015 год. Ваше выражение не практично. Вы должны записать этот ответ, но вы, вероятно, слишком заняты исправлением всех страниц, на которых написано это выражение. Правильно?

Видимо, вот и все:

 /^([\w\!\#$\%\&\'\*\+\-\/\=\?\^\`{\|\}\~]+\.)*[\w\!\#$\%\&\'\*\+\-\/\=\?\^\`{\|\}\~]+@((((([a-z0-9]{1}[a-z0-9\-]{0,62}[a-z0-9]{1})|[a-z])\.)+[a-z]{2,6})|(\d{1,3}\.){3}\d{1,3}(\:\d{1,5})?)$/i
  

Взято из http://fightingforalostcause.net/misc/2006/compare- email-regex.php 1 октября 2010 года.

Но, конечно, это игнорирует интернационализацию.

Они забыли сбежать из @ .

Правильная проверка адреса электронной почты в соответствии с RFC - это не то, чего можно достичь с помощью регулярного выражения с одной строкой. Статья с лучшим решением, которое я нашел в PHP, - это Что такое действительный адрес электронной почты? . Очевидно, он был портирован на Java. Я думаю, что эта функция слишком сложна для переноса и использования в JavaScript. Порт JavaScript / node.js: https://www.npmjs.com/package/email-addresses .

Рекомендуется проверять данные на клиенте, но дважды проверять проверку на сервере. Имея это в виду, вы можете просто проверить, выглядит ли строка как действительный адрес электронной почты на клиенте, и выполнить строгую проверку на сервере.

Вот функция JavaScript, которую я использую, чтобы проверить, похожа ли строка на действительный почтовый адрес:

 function looksLikeMail(str) {
    var lastAtPos = str.lastIndexOf('@');
    var lastDotPos = str.lastIndexOf('.');
    return (lastAtPos < lastDotPos && lastAtPos > 0 && str.indexOf('@@') == -1 && lastDotPos > 2 && (str.length - lastDotPos) > 2);
}
  

Пояснение:

  • lastAtPos < lastDotPos : последний @ должен быть перед последним . , поскольку @ не может быть частью имени сервера (поскольку как я знаю).

  • lastAtPos > 0 : перед последним @ должно быть что-то (имя пользователя электронной почты).

  • str.indexOf('@@') == -1 : в адресе не должно быть @@ . Даже если @ отображается как последний символ в имени пользователя электронной почты, его необходимо заключить в кавычки, чтобы " находился между этим @ и последним @ в адресе.

  • lastDotPos > 2 : перед последней точкой должно быть не менее трех символов, например a@b.com .

  • (str.length - lastDotPos) > 2 . После последней точки должно быть достаточно символов для формирования двухсимвольного домена. Я не уверен, что скобки необходимы.

Этот fn выглядит хорошо, но лучше ли это, чем регулярное выражение, написанное в верхнем ответе?

Я сомневаюсь в этом. Я использую его только для проверки того, выглядит ли строка как электронное письмо, и оставляю детали для кода на стороне сервера.

Он проверяет правильность любой строки, например «aaaa», то есть без «@» и «.»

Это не должно быть. lastIndexOf () должен вернуть -1, если не находит стрелку.

Аватар Ry-

«Даже если @ отображается как последний символ в имени пользователя электронной почты, его необходимо заключить в кавычки, чтобы " находился между этим @ и последним @ в адресе. ” Как насчет "@@"@example.com ?

"@@"@example.com действителен.

test @ .ds также действителен (?)

Сам HTML5 имеет проверку электронной почты. Если ваш браузер поддерживает HTML5, вы можете использовать следующий код.

 <form><input type="email" placeholder="me@example.com" required>
    <input type="submit">
</form>
  

jsFiddle link

Из спецификации HTML5 :

  

действительный адрес электронной почты - это строка, которая соответствует продукции email следующего ABNF, для которого установлен код Unicode.

 email   = 1*( atext / "." ) "@" label *( "." label )
label   = let-dig [ [ ldh-str ] let-dig ]  ; limited to a length of 63 characters by RFC 1034 section 3.5
atext   = < as defined in RFC 5322 section 3.2.3 >
let-dig = < as defined in RFC 1034 section 3.5 >
ldh-str = < as defined in RFC 1034 section 3.5 >
  
     

Это требование является преднамеренным нарушением RFC 5322, который определяет синтаксис для адресов электронной почты, который является одновременно слишком строгим (перед символом "@"), слишком расплывчатым (после символа "@") и слишком слабым (допускает комментарии, пробельные символы и строки в кавычках незнакомым образом для большинства пользователей) для практического использования здесь.

     

Следующее JavaScript- и Perl-совместимое регулярное выражение является реализацией приведенного выше определения.

 /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/
  

это хорошо, но проблема в том, что он должен быть внутри тега form и передаваться с помощью ввода submit , что не каждый может себе позволить. Кроме того, вы не можете оформить сообщение об ошибке.

Я добавил ответ ниже, который освобождает вас от формы и отправки. Но да, браузеры обычно также применяют только некоторую проверку достоверности, а не полную проверку RFC 822.

Аватар tim

также некоторые люди (например, я) больше не используют теги input и вместо этого полагаются на contenteditable на стандартные теги div .

a@a.a подтверждено в FF22

@ br1: он недействителен только потому, что не существует домена верхнего уровня «а». Что делать, если у вашего интернета есть какой-то IP-адрес?

Html5 тип поля электронной почты принимает электронные письма, такие как user @ email

Это регулярное выражение, которое я использую, и вы можете видеть, что оно передает все Тесты Chromium , упомянутые в принятом ответе здесь .

Примечание @ Комментарий Пуче: при вводе электронной почты в HTML 5 принимается user@email , в то время как, например, в filter_var PHP - нет. Это может вызвать проблемы.

Никогда не стоит полагаться только на проверку на стороне клиента. Есть так много способов ввести плохие значения в ваше серверное приложение.

Вы не должны использовать регулярные выражения для проверки входной строки, чтобы проверить, является ли это электронное письмо. Это слишком сложно и не охватывает все случаи.

Теперь, поскольку вы можете охватить только 90% случаев, напишите что-то вроде:

 function isPossiblyValidEmail(txt) {
   return txt.length > 5 && txt.indexOf('@')>0;
}
  

Вы можете уточнить это. Например, 'aaa @' допустимо. Но в целом вы понимаете суть. И не увлекайтесь ... Простое решение на 90% лучше, чем решение на 100%, которое не работает.

Мир нуждается в более простом коде ...

Это позволяет вводить столько недействительных адресов электронной почты, что это бесполезный совет.

Это не должно быть невозможно отладить вообще. В этой теме есть много прекрасных примеров, которые проверяют дальше, чем "содержит ли он @". Ваш пример позволяет считать "u @" действительным адресом электронной почты. По крайней мере, оцените, есть ли домен или что-то, что может быть доменом. Ваш пример того, что я бы назвал «агрессивно-ленивым кодированием». Я не уверен, почему вы защищаете его, так как это, безусловно, самый низкий рейтинг в ветке.

@cazlab возможно ты прав. В конце концов я был отклонен. В отличие от вас, я не думаю, что любой из приведенного выше кода показывает легко отлаживать фрагменты. Мой «агрессивно ленивый» подход, по крайней мере, может быть улучшен при необходимости.

Один из лучших ответов на этот вопрос. Вы никогда не должны блокировать пользователя из-за «странного» адреса электронной почты. Всегда лучше попытаться отправить письмо по адресу и потребовать от пользователя щелкнуть ссылку активации, если вы хотите быть уверены, что электронное письмо является действительным.

Чем это отличается от использования регулярных выражений? (.+)@(.*) делает то же самое и короче.

+1 - если цель состоит в том, чтобы убедиться, что пользователь хотя бы попытался ввести адрес электронной почты, то проверьте, можно ли определить, что адрес электронной почты определенно НЕ является адресом электронной почты. отличное решение. Хорошим примером будет, если вы хотите, чтобы имя пользователя было адресом электронной почты. Если пользователь вводит «sexy_chick_23», то это регулярное выражение можно использовать, чтобы предупредить его, что ожидается электронное письмо. Если набрано что-то похожее на электронное письмо, но это не так, то пользователь никогда не получит электронное письмо с подтверждением и процесс регистрации никогда не будет подтвержден.

@cazlab - Какой у вас сценарий использования информации о том, является ли адрес электронной почты пользователя действительным, не просто отправив ему электронное письмо и не узнав, что происходит? Как вы думаете, от чего вас может защитить регулярное выражение?

@ lwburk, если вы не хотите бесполезно рассылать электронные письма в эфир. «it @ u» пройдет эту «проверку». я не считаю этот пример проверкой, извините.

+1, хотя txt.length > 0 && является избыточным из-за второго теста. В любом случае, цель состоит в том, чтобы дать пользователю небольшую быструю обратную связь, в то же время предотвращая некоторые попадания на сервер, когда это возможно. Никто из тех, кто знает что-либо, на самом деле полагается только на JavaScript для проверки.

+1 не потому, что мне нравится ваше решение (как заявляет @cookiemonster, длина> 0 - это глупый тест, поскольку минимальный допустимый адрес электронной почты RFC составляет не менее 3 символов, реальный адрес электронной почты с возможностью маршрутизации в Интернете не менее 5), но я согласен всегда предпочтительнее простое решение, и ЕДИНСТВЕННЫЙ способ действительно проверить электронную почту - это отправить письмо. Я всегда люблю читать эти семантические споры между обманщиками, которые могут излагать стандарты и не могут кодировать в реальном мире, чтобы спасти свои жизни. Спасибо!

Я немного изменил ответ Джеймона для людей, которым нужна действительно простая проверка в виде:

 anystring@anystring.anystring
  

Регулярное выражение:

 /\S+@\S+\.\S+/
  

Пример функции JavaScript:

 function validateEmail(email) 
{
    var re = /\S+@\S+\.\S+/;
    return re.test(email);
}
  

Вы можете реализовать что-то в 20 раз дольше, что может вызвать проблемы у нескольких пользователей и может оказаться недействительным в будущем, или вы можете взять версию ImmortalFirefly, чтобы убедиться, что они хотя бы приложат усилия, чтобы это выглядело реальным. В зависимости от вашего приложения может возникнуть вероятность, что кто-то разозлится из-за того, что вы не принимаете их нетрадиционную электронную почту, а не из-за проблем, возникающих при вводе адресов электронной почты, которые на самом деле не существуют (что они могут сделать в любом случае, введя 100% действительный адрес электронной почты RFC2822, но с использованием незарегистрированного имени пользователя или домена). Upvoted!

@ImmortalFirefly, предоставленное вами регулярное выражение будет фактически соответствовать name@again@example.com . Попробуйте вставить свою строку в консоль JavaScript. Я полагаю, что ваше намерение состояло в том, чтобы сопоставить только весь текст, что потребовало бы начала текстовых операторов '^' и конца текста '$'. Я использую /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('name@again@example.com')

На основании этой проверки это письмо действительно: check @ this..com

один из моих адресов электронной почты - damiann @ dragon, это не учитывает случай машин, которые видны непосредственно веб-серверу или серверу электронной почты.

Гектометр Википедия утверждает, что "very.unusual.@.unusual.com"@example.com является действительным адресом электронной почты. /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test('"very.unusual.@.unusual.c‌​om"@example.com') // false . К сожалению.

Разве это также не позволяет @@@.@ ? : D

Аватар tk_

'/\S+@\S+\.\S+/.test('name@example.-com') '' true '

Я думаю, что худшая часть этого простого решения состоит в том, что оно только проверяет, что шаблон содержится . Конечно, мы не хотим заканчивать регулярным выражением overkill, но, по крайней мере, сделайте его релевантным и добавьте эти начальные и конечные проверки: /^...$/ - Не то чтобы это усложняло написание ... Отбрасывание дополнительные знаки @ тоже хорошая идея

OregonTrail ваш regex передает a@b._com , a@b_.com , чтобы быть правдой

Я объединил ответы на странице, чтобы достичь духа проверки внешнего интерфейса: выявление типичных ошибок пользователей. Вот мое регулярное выражение: /^[^\s@#!]+@[^\s@.#!]+.[^\s@.]+$/ Это немного сложнее, но для него конкретно требуется один и только один @ и . в этот порядок и запрещает символы # и ! по обе стороны от @ . Я исключаю только те, потому что их можно случайно нажать при нажатии @ . Он не исчерпывающий, но он ловит @ b..com или a@#b.com и т. Д.

В отличие от squirtle , здесь есть сложное решение, но оно отлично справляется с проверкой электронной почты надлежащим образом:

 function isEmail(email) { 
    return /^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))$/i.test(email);
} 
  

Используйте вот так:

 if (isEmail('youremail@yourdomain.com')){ console.log('This is email is valid'); }
  

Вам не нужен == true в вашем примере.

Решение Sectrean отлично работает, но оно не помогло моему линтеру . Поэтому я добавил несколько побегов:

 function validateEmail(email){ 
     var re = /^(([^<>()[]\\.,;:\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,}))$/; 
     return re.test(email); 
}
  

validateEmail ("e_mail@sth.com") и validateEmail ("e.mail@sth.com") оба возвращают значение false

 function validateEmail(elementValue){        
    var emailPattern = /^[a-zA-Z0-9._]+[a-zA-Z0-9]+@[a-zA-Z0-9]+\.[a-zA-Z]{2,4}$/;  
    return emailPattern.test(elementValue);   
  }   
  

Возвращает true, если адрес электронной почты действителен. В противном случае он вернет false.

Сделайте это:

 [a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?
  

Почему? Он основан на RFC 2822 , который является стандартным письмом ALL адреса ДОЛЖНЫ придерживаться. И я не уверен, почему вы возитесь с чем-то «более простым» ... вы все равно скопируете и вставите его;)

Часто при хранении адресов электронной почты в базе данных я делаю их строчными, и на практике регулярные выражения обычно помечают без учета регистра. В этих случаях это немного короче:

 [a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?
  

Вот пример его использования в JavaScript (с нечувствительным к регистру флагом i в конце).

 var emailCheck=/^[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?$/i;
console.log( emailCheck.test('some.body@domain.co.uk') );
  

<сильный> Примечание :
Технически, некоторые электронные письма могут содержать кавычки в разделе перед символом @ с escape-символами внутри кавычек (поэтому ваш пользователь электронной почты может быть неприятным и содержать такие вещи, как @ и "..." до тех пор, пока это написано в кавычках). ЭТО НИКОГДА НЕ ДЕЛАЕТ! Это устарело. Но он включен в настоящий RFC 2822 стандарт и здесь опущен.

Дополнительная информация: http://www.regular-expressions.info/email.html

@Kondal код JavaScript не чувствителен к регистру из-за флага /i в конце регулярного выражения. Я упоминаю тот факт, что это должно быть сравнение без учета регистра, но я сделаю это более ясным.

Работал для меня как шарм

В современных браузерах вы можете опираться на ответ @ Sushil, используя чистый JavaScript и DOM

 function validateEmail(value) {
  var input = document.createElement('input');

  input.type = 'email';
  input.required = true;
  input.value = value;

  return typeof input.checkValidity === 'function' ? input.checkValidity() : /\S+@\S+\.\S+/.test(value);
}
  

Я собрал пример в скрипке http://jsfiddle.net/boldewyn/2b6d5/ . В сочетании с обнаружением функций и проверкой с помощью ответа Squirtle он освобождает вас от расправы с регулярными выражениями и не мешает в старых браузерах.

Это умная идея, чтобы разобраться с проблемой, но она не работает, потому что браузеры также имеют дрянную проверку. Например. .@a проверяется как true в текущих версиях Chrome, Firefox и Safari.

@HenryJackson К сожалению, в этом случае да. Это потому, что в соответствии с RFC это действительный адрес электронной почты (например, интранет). Браузеры будут получать на гриле, если они проверяют слишком узко и выдают ложные негативы.

Обновлен, теперь содержит обнаружение функций и постепенную деградацию, теперь он не ломается в новых браузерах, а использует любое регулярное выражение, которое вам нравится.

Хорошее решение. К сожалению, это только для HTML5 +.

Это, безусловно, лучшее решение исходного вопроса. Да, он использует HTML5, но большинство приложений, которым требуется такой уровень точности, наверняка уже будет в любом случае полагаться на HTML5, так что спорный вопрос. Мы никогда не сможем определить, является ли чья-то электронная почта действительной, не заставляя их проверять ее, так или иначе, поэтому мы действительно не должны тратить столько времени или усилий на ее проверку. Быстрая проверка на любой очевидный синтаксис или попытку наглости - все усилия, которые мы должны приложить.

Интересно, что этот код вернул true для пустых строк. Я отредактировал его, чтобы добавить проверку нулевой и пустой строки.

Да, потому что пустые значения допускаются, если ввод не требуется. Вы также можете установить input.required = true для того же эффекта.

 <form name="validation" onSubmit="return checkbae()">
    Please input a valid email address:<br />

    <input type="text" size=18 name="emailcheck">
    <input type="submit" value="Submit">
</form>

<script language="JavaScript1.2">
    var testresults
    function checkemail(){
        var str = document.validation.emailcheck.value
        var filter = /^([\w-]+(?:\.[\w-]+)*)@((?:[\w-]+\.)*\w[\w-]{0,66})\.([a-z]{2,6}(?:\.[a-z]{2})?)$/i
        if (filter.test(str))
            testresults = true
        else {
            alert("Please input a valid email address!")
            testresults = false
        }
        return (testresults)
    }
</script>

<script>
    function checkbae(){
        if (document.layers || document.getElementById || document.all)
            return checkemail()
        else
            return true
    }
</script>
  

Может быть, если вы добавили объяснение или описание, чтобы пойти с ним? Я не думаю, что вам действительно нужно показывать какие-либо HTML; все люди обеспокоены, это Javascript и регулярное выражение. Если вы сведете свой ответ только к jacascript и добавите небольшую рекламу, я дам вам голос.

Мои знания о регулярных выражениях не так уж хороши. Вот почему я сначала проверяю общий синтаксис с помощью простого регулярного выражения, а затем проверяю более конкретные параметры с другими функциями. Возможно, это не лучшее техническое решение, но в этом случае я стал более гибким и быстрым.

Наиболее распространенными ошибками, с которыми я сталкивался, являются пробелы (особенно в начале и конце) и иногда двойная точка.

 function check_email(val){
    if(!val.match(/\S+@\S+\.\S+/)){ // Jaymon's / Squirtle's solution
        // Do something
        return false;
    }
    if( val.indexOf(' ')!=-1 || val.indexOf('..')!=-1){
        // Do something
        return false;
    }
    return true;
}

check_email('check@thiscom'); // Returns false
check_email('check@this..com'); // Returns false
check_email(' check@this.com'); // Returns false
check_email('check@this.com'); // Returns true
  

Это правильная версия RFC822.

 function checkEmail(emailAddress) {
  var sQtext = '[^\\x0d\\x22\\x5c\\x80-\\xff]';
  var sDtext = '[^\\x0d\\x5b-\\x5d\\x80-\\xff]';
  var sAtom = '[^\\x00-\\x20\\x22\\x28\\x29\\x2c\\x2e\\x3a-\\x3c\\x3e\\x40\\x5b-\\x5d\\x7f-\\xff]+';
  var sQuotedPair = '\\x5c[\\x00-\\x7f]';
  var sDomainLiteral = '\\x5b(' + sDtext + '|' + sQuotedPair + ')*\\x5d';
  var sQuotedString = '\\x22(' + sQtext + '|' + sQuotedPair + ')*\\x22';
  var sDomain_ref = sAtom;
  var sSubDomain = '(' + sDomain_ref + '|' + sDomainLiteral + ')';
  var sWord = '(' + sAtom + '|' + sQuotedString + ')';
  var sDomain = sSubDomain + '(\\x2e' + sSubDomain + ')*';
  var sLocalPart = sWord + '(\\x2e' + sWord + ')*';
  var sAddrSpec = sLocalPart + '\\x40' + sDomain; // complete RFC822 email address spec
  var sValidEmail = '^' + sAddrSpec + '$'; // as whole string

  var reValidEmail = new RegExp(sValidEmail);

  return reValidEmail.test(emailAddress);
}
  

@ БГМ: Вы бы предпочли красивую функцию, которая не работает?

@Piskvor Нет, я бы предпочел красивую функцию, которая работает. А что насчет тебя?

@BGM: тогда иди и отредактируй. Ответ, в конце концов, помечен как «сообщество вики».

Адреса IDN не подтверждены (info@üpöü.com)

Просто проверьте, является ли введенный адрес электронной почты действительным или не использует HTML.

 <input type="email"/>
  

Нет необходимости писать функцию для проверки.

IE <10 не поддерживает это, как и собственный браузер Android.

Upvoting. IE <10 мертв.

Все адреса электронной почты содержат символ «at» (т.е. @). Проверьте это необходимое условие:

 email.indexOf("@") > 0
  

Не беспокойтесь о чем-нибудь более сложном. Даже если бы вы могли точно определить, является ли электронная почта RFC-синтаксически действительной, это не скажет вам, принадлежит ли оно тому, кто его предоставил. Вот что действительно имеет значение.

Чтобы проверить это, отправьте сообщение проверки.

что если будет более одного символа '@'? другие запрещенные символы? Этой проверке нельзя доверять ...

Отлично, этот ответ был простым, только дополнительная проверка уровня. уже есть слой на переднем конце, так что это помогает, спасибо

Это, безусловно, лучший ответ ИМО. Достаточно хорошо, чтобы поймать большинство случайных входных данных (то есть большинство вещей, которые не являются адресами электронной почты) без каких-либо ложных негативов.

Если вы используете Closure, вы можете использовать встроенный тип goog.format.EmailAddress :

  

http: //docs.closure-library.googlecode.com/git/class_goog_format_EmailAddress.html

Например:

 goog.format.EmailAddress.isValidAddrSpec("blah@blah.com")
  

Обратите внимание, что читая источник (ссылка выше), вы можете увидеть, что в комментариях говорится, что IDN не поддерживаются и что он предназначен только для большинства адресов:

 // This is a fairly naive implementation, but it covers 99% of use cases.
// For more details, see http://en.wikipedia.org/wiki/Email_address#Syntax
// TODO(mariakhomenko): we should also be handling i18n domain names as per
// http://en.wikipedia.org/wiki/Internationalized_domain_name
  

Вот как узел-валидатор это делает:

 /^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9](?:[a-zA-Z0-9\-](?!\.)){0,61}[a-zA-Z0-9]?\.)+[a-zA-Z0-9](?:[a-zA-Z0-9\-](?!$)){0,61}[a-zA-Z0-9]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/
  

W3Schools предлагает хороший простой и эффективный скрипт для проверки электронной почты:

 function validateEmail(email) {
    var atpos=email.indexOf("@");
    var dotpos=email.lastIndexOf(".");
    if (atpos < 1 || dotpos < atpos+2 || dotpos+2 >= email.length) {
        alert("Not a valid e-mail address");
        return false;
    }
    return true;
}
  

Обратите внимание, что вам придется удалить пробелы, если они есть, с чем-то вроде этого:

 .replace(/ /g,'')
  

Источник: Проверка формы JavaScript

abc@xyz - это совершенно действительный адрес электронной почты, который не распознается вашим регулярным выражением.

Это не мое регулярное выражение, это регулярное выражение w3schools, и для простой проверки электронной почты, если вы предпочитаете быть слишком ограничительным, чем недостаточным, это просто работает. Если вы хотите полный пакет, используйте решение Voyager.

Довольно ужасно, однако, это будет проверять много неправильных электронных писем, то есть что-то вроде d @@. Com будет действительным.

Используйте этот код внутри функции валидатора:

 var emailID = document.forms["formName"]["form element id"].value;
atpos = emailID.indexOf("@");
dotpos = emailID.lastIndexOf(".");
if (atpos < 1 || ( dotpos - atpos < 2 ))
{
    alert("Please enter correct email ID")
    return false;
}
  

В противном случае вы можете использовать jQuery . Внутренние правила определяют:

 eMailId: {
    required: true,
    email: true
}
  

abc@xyz - это совершенно действительный адрес электронной почты, который не распознается вашим регулярным выражением.

Нет, это не так. Правильный шаблон электронной почты - что-то@something.something, abc @ xyz не соответствует этому шаблону. Так что это не правильный адрес.

Я говорю, что электронная почта имеет: local-part @ domain. И есть "." в доменной части.

Можете ли вы указать действительный адрес электронной почты типа что-то @ что-то?

У вас была страница в Википедии? ДВУ - это действительное имя хоста. Таким образом, abc@tld является действительным адресом электронной почты.

Ну, я никогда не сталкивался с такой электронной почтой, вышеупомянутая проверка прекрасно работает со мной. Если вы не хотите этого, просто удалите dotpos и связанный с ним пункт. Затем он будет работать для abc @ xyz. Я хотел бы предложить проверить электронную почту со ссылкой, если вы хотите быть в этом уверены. davidcel.is/blog/2012/09 / 06 / ...

И API проверки JQuery также не принимает электронную почту типа abc @ xyz

Единственный способ подтвердить адрес электронной почты - это отправить письмо и дождаться ответа. Кроме этого, здесь есть URL, где вы можете проверить, соответствует ли ваш адрес RFC822: mythic-beasts.com/~pdw/cgi-bin/emailvalidate . Вы можете видеть, что abc @ xyz является действительным адресом для RFC822.

Регулярное выражение, предоставленное Microsoft в ASP.NET MVC , называется

 /^[\w-]+(\.[\w-]+)*@([a-z0-9-]+(\.[a-z0-9-]+)*?\.[a-z]{2,6}|(\d{1,3}\.){3}\d{1,3})(:\d{4})?$/
  

Который я выкладываю здесь на случай, если он некорректен - хотя он всегда идеально подходил для моих нужд.

Не позволяет + в части имени электронной почты.

 <pre>
**The personal_info part contains the following ASCII characters.
1.Uppercase (A-Z) and lowercase (a-z) English letters.
2.Digits (0-9).
3.Characters ! # $ % & ' * + - / = ? ^ _ ` { | } ~
4.Character . ( period, dot or fullstop) provided that it is not the first or last character and it will not come one after the other.**
</pre>
*Example of valid email id*
<pre>
yoursite@ourearth.com
my.ownsite@ourearth.org
mysite@you.me.net
xxxx@gmail.com
xxxxxx@yahoo.com
</pre>
<pre>
xxxx.ourearth.com [@ is not present] 
xxxx@.com.my [ tld (Top Level domain) can not start with dot "." ]
@you.me.net [ No character before @ ]
xxxx123@gmail.b [ ".b" is not a valid tld ]
xxxx@.org.org [ tld can not start with dot "." ]
.xxxx@mysite.org [ an email should not be start with "." ]
xxxxx()*@gmail.com [ here the regular expression only allows character, digit, underscore and dash ]
xxxx..1234@yahoo.com [double dots are not allowed
</pre>
**javascript mail code**

    function ValidateEmail(inputText)
    {
    var mailformat = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/;
    if(inputText.value.match(mailformat))
    {
    document.form1.text1.focus();
    return true;
    }
    else
    {
    alert("You have entered an invalid email address!");
    document.form1.text1.focus();
    return false;
    }
    }
  

Очень просто в JavaScript . следуйте этому коду.

 function validate(){
    var email = document.getElementById('Email');
    var filter = /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})+$/;

    if (!filter.test(email.value))
    {
        alert('Please Enter the valid email address');
        email.focus;
        return false;
    }
    else
{
        return true;
    }
  

HTML код для этого:

 form name="form"
     enctype="multipart/form-data"
     name="form"
     action="register.php"
     method="POST" onsubmit="return validate();" >
    <input type="text" placeholder="Enter ur Email Id" id="Email" name="Email" />
    <input type="submit" id="submit" value="save" name="Like" class="button" />
</form>
  

Этот фильтр делает недействительными многие распространенные действительные адреса электронной почты ... Например: user+tag@gmail.com

Один из моих коллег поделился этим регулярным выражением со мной. Мне это очень нравится.

 function isValidEmailAddress (email) {
    var validEmail = false;
    if (email) {
        email = email.trim().toLowerCase();
        var pattern = /^[\w-']+(\.[\w-']+)*@([a-zA-Z0-9]+[a-zA-Z0-9-]+(\.[a-zA-Z0-9-]+)*?\.[a-zA-Z]{2,6}|(\d{1,3}\.){3}\d{1,3})(:\d{4})?$/;
        validEmail = pattern.exec(email);
    }

    return validEmail;
}

if (typeof String.prototype.trim !== 'function') {
    String.prototype.trim = function() {
        return this.replace(/^\s+|\s+$/g, '');
    };
}
  

 function validatecontactEmail(email) { 

 if (/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(email))  
  {  
    return (true)  
  }  

    return (false)  

}
  

Как насчет просто return /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(email) ?

Вот функция, которую я использую для проверки электронной почты внешнего интерфейса. (Регулярное выражение взято из parsley.js)

 <!DOCTYPE html>
<html>
<head>
    <title>Our Company</title>
    <style>
        .form-style {
            color: #ccc;
        }
    </style>
</head>
<body>
    <h1>Email Validation Form Example</h1>
    <input type="text" name="email" id="emailInput" class="form-style">
    <script>
        function validateEmail(emailAddress) {
            var regularExpression = /^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))){2,6}$/i;
             return regularExpression.test(emailAddress);
        }

        function showEmailValidationState(event) {
            if (validateEmail(event.target.value)) {
                document.getElementById("emailInput").style.color = 'black';
            }
        }
    document.getElementById("emailInput").addEventListener("keyup", showEmailValidationState);
    </script>
</body>
</html>
  

Я люблю регулярные выражения, но не для проверки электронной почты. Получайте удовольствие отладки, если кто-то обнаружит проблему с этим!

Я использовал 3 этапа проверки для электронной почты. Во-первых, я использую HTML5 с типом = требуется электронная почта. 2-й - это регулярное выражение JS, показанное выше, затем последний - на стороне сервера.

@ нули, за исключением того, что здесь вы используете type="text" , а не type="email" : - /

Да, это правильно, я нахожу проверку HTML5 раздражающей.

Если вы используете AngularJS, просто добавьте type="email" к элементу ввода:

  

https://docs.angularjs.org/api/ng/ вход / вход% 5Bemail% 5D

Если элемент ввода отсутствует, его можно создать динамически:

 var isEmail = $compile('<input ng-model="m" type="email">')($rootScope.$new()).
    controller('ngModel').$validators["email"];

if (isEmail('email@gmail.com')) {
  console.log('valid');
} 
  

Но что такое эта функция парсера электронной почты? Не могли бы вы опубликовать его, чтобы можно было использовать без углов?

Да, если вы собираетесь опубликовать ответ «черного ящика», пожалуйста, найдите RegEx за функцией парсера электронной почты и покажите нам, что он использует.

Проверочное выражение для электронной почты:

 var rex_email = /^(([^<>()[\]\\.,;:\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,}))$/;

if(email=="") {
    window.plugins.toast.showShortBottom( "Please enter the details. ", function(a) {
        console.log('toast success: ' + a);
    }, function(b) { });
} else if(!rex_email.test(email)) {
    window.plugins.toast.showShortBottom( "Please enter the valid email id. ", function(a) {
        console.log('toast success: ' + a);
    }, function(b) { });
}
  

Это будет работать для очень распространенных, базовых адресов электронной почты, но есть определенные крайние случаи, когда это будет отклонять действительные адреса электронной почты. Если бы вы прочли остальные 36 (!) Ответов здесь, вы бы знали об этом сейчас.

Я знаю, это не регулярное выражение, но в любом случае ...

Это пример с узлом и пакетом npm наличие электронной почты . адрес электронной почты существует, и если он находится в правильной форме:)

Это будет проверять электронную почту, если она отвечает, если она не получила ответа, она вернет false или иначе true.

 function doesEmailExist(email) {
    var emailExistence = require('email-existence');
    return emailExistence.check(email,function (err,status) {
            if (status) {
                return status;
            }
            else {
                throw new Error('Email does not exist');
            }
        });
}
  

Следующие проверки Regex:

  • До @
  • нет специальных символов
  • (-) и (.) не должны быть вместе после @ Никаких специальных символов после @ не должно быть до 2 символов Длина электронной почты должна быть не более 128 символов
 function validateEmail(email) {
var chrbeforAt = email.substr(0, email.indexOf('@'));
if (!($.trim(email).length > 127)) {
    if (chrbeforAt.length >= 2) {
        var re = /^(([^<>()[\]{}'^?\\.,!|//#%*-+=&;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?/;
        //var re = /[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?/;
        return re.test(email);
    } else {
        return false;
    }
} else {
    return false;
}
}
  

В итоге я воспользовался этим, он работает лучше всего для моих нужд, и в основном я просто угнал пользовательскую часть и использовал что-то другое для совпадения после знака @, потому что мне нужна была моя реализация, чтобы позволить пользователям только определенного домена. Но этот умный!

Следующие проверки Regex:

  • До @
  • нет специальных символов
  • (-) и (.) не должны быть вместе после @
  • Никаких специальных символов после @ 2 символов не должно быть до @
  • Длина электронной почты должна быть не более 128 символов

     function validateEmail(email) {
        var chrbeforAt = email.substr(0, email.indexOf('@'));
        if (!($.trim(email).length > 127)) {
            if (chrbeforAt.length >= 2) {
                var re = /^(([^<>()[\]{}'^?\\.,!|//#%*-+=&;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?/;
                return re.test(email);
            } else {
                return false;
            }
        } else {
            return false;
        }
    }
      

 \b[a-z][\w\d_\.]+@\w+\.[a-z]{2}[a-z]?\.?[a-z]{,2}\s
  

Это позволяет:

 abcxyz123@qwert.com    
abc123xyz@asdf.co.in   
abc1_xyz1@gmail1.com   
abc.xyz@gmail.com.in
  

Хорошая попытка: 2 обновления здесь: для диапазонов соответствия мы предоставляем {min,max} . Пустой min является ошибкой, но может содержать пустой max . Я имею в виду [a-z]{,2} не так, напишите как {0,2} . Более того: ваше регулярное выражение показывает kamal@_gmail.com как допустимое, а это не так!

лучший: D (дружественный RFC и без ошибок "слишком сложный"):

 function    isMail(mail)
{
    pattuser = /^([A-Z0-9_%+\-!#$&'*\/=?^`{|}~]+\.?)*[A-Z0-9_%+\-!#$&'*\/=?^`{|}~]+$/i;
    pattdomain = /^([A-Z0-9-]+\.?)*[A-Z0-9-]+(\.[A-Z]{2,9})+$/i;

    tab = mail.split("@");
    if (tab.length != 2)
        return false;
    return (pattuser.test(tab[0]) && pattdomain.test(tab[1]));
}
  

Пользователь разрешает пробелы, что именно там разрешает пробелы?

ты прав, я забыл, что я не принимаю их в этом

Если вы хотите использовать Jquery и хотите использовать современный подход, используйте маску ввода JQuery с проверкой.

http://bseth99.github.io/projects/ jquery-ui / 5-jquery-masks.html

Демонстрация того, как простая маска ввода jquery, представлена ​​здесь: http://codepen.io/anon/pen/ gpRyBp

Пример простой маски ввода для примера даты НЕ полная проверка

  <input id="date" type="text" placeholder="YYYY-MM-DD"/>
  

и сценарий:

  $("#date").mask("9999-99-99",{placeholder:"YYYY-MM-DD"});
  

Рекомендуется использовать встроенный тег HTML5 для электронной почты.

 <input type="email" name="email">
  

или общий синтаксис электронной почты для распознавания @ и. из строки дается ниже.

 ^[a-zA-Z0-9_\-.]+@[a-zA-Z0-9\-]+\.[a-zA-Z0-9\-.]+$
  
  

Обратите внимание, что при этом недействительный адрес электронной почты все равно будет совпадать   регулярное выражение, почти невозможно поймать их всех, но это будет   немного улучшить ситуацию.

Согласно вашему регулярному выражению "_.............. kamal@gmail.com" является действительным, что не должно быть!

Вот что я сказал в записке

Я считаю, что это лучшее решение:

 /^[^\s@]+@[^\s@]+\.[^\s@]+$/
  

Он поддерживает следующие форматы:

1. prettyandsimple@example.com
2. very.common@example.com
3. одноразовый.стиль.email.with+symbol@example.com
4. other.email-with-dash@example.com
9. #!$%&'*+-/=?^_`width угадываемое~~@example.org
6. "() []:,; @ \\\"! # $% & '* + - / =? ^ _ `{} | ~ .A "@ example.org
7. "" @ example.org (пробел между кавычками)
8. üñîçøðé@example.com (символы Юникода в локальной части)
9. üñîçøðé@üñîçøðé.com (символы Юникода в доменной части)
10. Pelé@example.com (латиница)
11. δοκιμή@παράδειγμα.δοκιμή (греческий)
12. 買 買 @ 屋企. 香港 (китайский)
13. 斐 斐 @ 黒 川. 日本 (японский)
14. чебурашка@ящик-с-апельсинами.рф (кириллица)

Он явно универсален и допускает все важные международные символы, но при этом поддерживает базовый формат any@anything.anything. Он заблокирует пробелы, которые технически разрешены RFC, но они настолько редки, что я с радостью это сделаю.

Он поддерживает следующие форматы:

, но они настолько редки, что я с радостью это сделаю. 

Он поддерживает следующие форматы:

1.  prettyandsimple@example.com
2.  very.common@example.com
3.  disposable.style.email.with+symbol@example.com
4.  other.email-with-dash@example.com
9.  #!$%&'*+-/=?^_`{}|~@example.org
6.  "()[]:,;@\\\"!#$%&'*+-/=?^_`{}| ~.a"@example.org
7.  " "@example.org (space between the quotes)
8.  üñîçøðé@example.com (Unicode characters in local part)
9.  üñîçøðé@üñîçøðé.com (Unicode characters in domain part)
10. Pelé@example.com (Latin)
11. δοκιμή@παράδειγμα.δοκιμή (Greek)
12. 我買@屋企.香港 (Chinese)
13. 甲斐@黒川.日本 (Japanese)
14. чебурашка@ящик-с-апельсинами.рф (Cyrillic)

It's clearly versatile and allows the all-important international characters, while still enforcing the basic anything@anything.anything format. It will block spaces which are technically allowed by RFC 1. prettyandsimple@example.com 2. very.common@example.com 3. одноразовый.стиль.email.with+symbol@example.com 4. other.email-with-dash@example.com 9. #!$%&'*+-/=?^_`width угадываемое~~@example.org 6. "() []:,; @ \\\"! # $% & '* + - / =? ^ _ `{} | ~ .A "@ example.org 7. "" @ example.org (пробел между кавычками) 8. üñîçøðé@example.com (символы Юникода в локальной части) 9. üñîçøðé@üñîçøðé.com (символы Юникода в доменной части) 10. Pelé@example.com (латиница) 11. δοκιμή@παράδειγμα.δοκιμή (греческий) 12. 買 買 @ 屋企. 香港 (китайский) 13. 斐 斐 @ 黒 川. 日本 (японский) 14. чебурашка@ящик-с-апельсинами.рф (кириллица)

Он явно универсален и допускает все важные международные символы, но при этом поддерживает базовый формат any@anything.anything. Он заблокирует пробелы, которые технически разрешены RFC, но они настолько редки, что я с радостью это сделаю.

Он поддерживает следующие форматы:

, но они настолько редки, что я с радостью это сделаю. 

Это именно то, что я делаю. Все эти «сложные» ответы порождают проблемы: они либо не допускают использование маленького кода IDN, либо используют фиксированный набор доменов верхнего уровня, либо излишне ограничивают пользователя, чтобы он не использовал символы, подобные [@ çµ.ö, в своем префиксе электронной почты (до @) или доменное имя. JavaScript в веб-интерфейсе (не для внутреннего использования причины) недостаточно для проверки по соображениям безопасности. Так почему бы просто не помочь пользователю предотвратить основные опечатки. Основные опечатки: забыть TLD или префикс пользователя (перед @), доменную часть или неправильный тип @ как . (или наоборот). Конечно, мы должны быть более строгими на стороне сервера.

По некоторым странным причинам username@domain.com не работает с этим шаблоном

Согласно вашему регулярному выражению "_.............. kamal@gmail.com" является действительным, что не должно быть!

Вот заявленный RegEx с примерами, если вы хотите возиться с этим решением: regex101.com/r/AzzGQU/ 2

Это регулярное выражение верно. Если кто-то вводит свой адрес электронной почты, например, a@b@c@d.x.y.@.z , то, возможно, он заслуживает того, чтобы ему было плохо? : D

Протестировал его для regex.test ("john-appleseed@mac.com") и regex.test ("anna-haro@mac.com"). Первый показывал false, а последний - true, поэтому что-то не так с упомянутым вами регулярным выражением.

@ spa900 оба дают мне правду

Это регулярное выражение предотвращает дублирование доменных имен, таких как abc@abc.com.com.com.com, только два раза разрешает домен, как abc@abc.co.in. Кроме того, он не позволяет выполнять статистику с номера, например 123abc@abc.com

 regexp: /^([a-zA-Z])+([a-zA-Z0-9_.+-])+\@(([a-zA-Z])+\.+?(com|co|in|org|net|edu|info|gov|vekomy))\.?(com|co|in|org|net|edu|info|gov)?$/,  
  

Все лучшее !!!!!

Почему вы хотите использовать что-то подобное? Спецификация стандартов адресов электронной почты предполагает, что адреса электронной почты могут начинаться с цифр и могут содержать несколько символов точки как в домене, так и в части lcoal. Этот ответ, кажется, является тем, что вы создали для какого-то совершенно нестандартного сценария, когда вы эффективно дискриминируете людей за наличие адресов электронной почты, которые вам не нравятся! Чтобы немного расширить, адреса электронной почты также могут содержать IP-адреса, поэтому это может быть даже более ограничительным, чем описано.

Правда !!!!!! Но разные люди могут иметь разные требования, и именно поэтому мы пишем проверки .... не так ли ?????????

Ну не совсем. Мы используем проверку, чтобы подтвердить, что вводные данные соответствуют нашим ожиданиям, чтобы избежать попыток использовать плохо отформатированные данные определенным образом. В этом случае OP ищет код, который может проверять адрес электронной почты, как и предполагалось. В вашем случае вы, кажется, проверяете строку на то, что хотите. Проще говоря, вы проверяете, соответствует ли строка чему-то, что вы хотите, чтобы она соответствовала, а не является адресом электронной почты, в то время как OP ищет подтверждение, что строка соответствует адресу электронной почты. Это не одно и то же.

Простое регулярное выражение для идентификатора электронной почты

  String EMAIL_PATTERN ="^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()[\]\.,;:\s@\"]+\.)+[^<>()[\]\.,;:\s@\"]{2,})$";
  

Согласно вашему регулярному выражению "_.............. kamal@gmail.com" является действительным, что не должно быть!

Используйте регулярное выражение:

  /^[a-z][a-zA-Z0-9_.]*(\.[a-zA-Z][a-zA-Z0-9_.]*)?@[a-z][a-zA-Z-0-9]*\.[a-z]+(\.[a-z]+)?$/
  

Пример:

 function validateEmail(email) {
    var re = /^[a-z][a-zA-Z0-9_.]*(\.[a-zA-Z][a-zA-Z0-9_.]*)?@[a-z][a-zA-Z-0-9]*\.[a-z]+(\.[a-z]+)?$/;
    return re.test(email);
}
  

Это должно разрешать только @,. , _

Я смешал @mevius и @Boldewyn Code, чтобы создать этот окончательный код для проверки электронной почты с использованием JavaScript.

 function ValidateEmail(email){
 
  var re = /^(([^<>()\[\]\\.,;:\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,}))$/;
 
  var input = document.createElement('input');
 
  input.type = 'email';
  input.value = email;
 
  return typeof input.checkValidity == 'function' ? input.checkValidity() : re.test(email);
 
}  

Я поделился этим кодом в своем блоге здесь .

Это не удастся, если поле пустое. Вы можете добавить обязательный атрибут и обрезать адрес электронной почты, чтобы решить эту проблему.

Я действительно с нетерпением жду, чтобы решить эту проблему. Поэтому я изменил регулярное выражение проверки электронной почты выше

  • Оригинальный
    /^(([^<>()\[\]\\.,;:\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,}))$/

  • Модифицированный
    /^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()\.,;\s@\"]+\.{0,1})+[^<>()\.,;:\s@\"]{2,})$/

передать примеры в адрес электронной почты Википедии .

Результат можно увидеть в здесь .

enter описание изображения здесь

Это кажется хорошим решением, оно работает и с новыми TLD, и с 1-м письмом.

Почему john..doe@example.com должно быть не правильно? Это действительный угловой случай.

Если вы используете ng-pattern и материал, это делает работу.

 vm.validateEmail = '([a-zA-Z0-9_.]{1,})((@[a-zA-Z]{2,})[\\\.]([a-zA-Z]{2}|[a-zA-Z]{3}))';
  

Тот, кто использует решение @pvl и хочет, чтобы он прошел ESLint Prefer-template тогда вот версия, где я использовал шаблонные литералы вместо конкатенации строк.

 validateEmail(email) {
    let sQtext = '[^\\x0d\\x22\\x5c\\x80-\\xff]';
    let sDtext = '[^\\x0d\\x5b-\\x5d\\x80-\\xff]';
    let sAtom = '[^\\x00-\\x20\\x22\\x28\\x29\\x2c\\x2e\\x3a-\\x3c\\x3e\\x40\\x5b-\\x5d\\x7f-\\xff]+';
    let sQuotedPair = '\\x5c[\\x00-\\x7f]';
    let sDomainLiteral = `\\x5b(${sDtext}|${sQuotedPair})*\\x5d`;
    let sQuotedString = `\\x22(${sQtext}|${sQuotedPair})*\\x22`;
    let sDomainRef = sAtom;
    let sSubDomain = `(${sDomainRef}|${sDomainLiteral})`;
    let sWord = `(${sAtom}|${sQuotedString})`;
    let sDomain = `${sSubDomain}(\\x2e${sSubDomain})*`;
    let sLocalPart = `${sWord}(\\x2e${sWord})*`;
    let sAddrSpec = `${sLocalPart}\\x40${sDomain}`; // complete RFC822 email address spec
    let sValidEmail = `^${sAddrSpec}$`; // as whole string

    let reValidEmail = new RegExp(sValidEmail);

    return reValidEmail.test(email);
}
  

Regex для проверки адреса электронной почты

 [a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])+
  

Я не вижу вашего регулярного выражения в RFC5322: tools.ietf.org/html/rfc5322 - есть какая-то ошибка?

"Лучшее регулярное выражение когда-либо"? Возможно, какое-то объяснение здесь?

Почему вы сказали, что это лучшее решение из всех, можете ли вы объяснить немного больше, пожалуйста?

Я не могу вспомнить, почему я написал «лучшее когда-либо регулярное выражение». Извините, ребята, если это вас беспокоит.

Решение, которое не проверяет существование TLD, является неполным.

Почти все ответы на эти вопросы предлагают использовать Regex для проверки адресов электронной почты. Я думаю, что Regex хорош только для элементарной проверки. Кажется, что проверка правильности адресов электронной почты на самом деле является двумя отдельными проблемами:

1- Проверка формата электронной почты: . Убедитесь, что электронная почта соответствует формату и шаблону электронных писем в RFC 5322 и действительно ли существует TLD. Список всех допустимых TLD можно найти здесь .

Например, хотя адрес example@example.ccc будет проходить через регулярное выражение, он не является действительным адресом электронной почты, поскольку ccc не является доменом верхнего уровня IANA.

2- Убедитесь, что электронная почта действительно существует. Для этого единственным вариантом является отправить пользователям электронное письмо .

Я искал Regex в JS, который проходит все тестовые случаи адреса электронной почты:

  • email@example.com Действительный адрес электронной почты

  • firstname.lastname@example.com Электронная почта содержит точку в поле адреса

  • email@subdomain.example.com Письмо содержит точку с поддоменом

  • firstname+lastname@example.com Знак плюс считается допустимым символом

  • email@192.0.2.123 Домен является действительным IP-адресом

  • email@[192.0.2.123] Квадратная скобка вокруг IP-адреса считается действительной

  • “email”@example.com Цитаты по электронной почте считаются действительными

  • 1234567890@example.com Цифры в адресе действительны

  • email@domain-one.example Тире в доменном имени действительна

  • _______@example.com Подчеркивание в поле адреса допустимо

  • email@example.name .name является допустимым именем домена верхнего уровня

  • email@example.co.jp Точка в имени домена верхнего уровня также считается допустимой (с использованием co.jp в качестве примера здесь)

  • firstname-lastname@example.com Тире в поле адреса действительна

Вот и мы:

http://regexr.com/3f07j

ИЛИ регулярное выражение:

 Regex = /(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@[*[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+]*/
  

В nodeJS вы также можете использовать модуль узла валидатора и просто использовать его

Установите библиотеку с помощью валидатора npm install

 var validator = require('validator');

validator.isEmail('foo@bar.com'); //=> true 
  

Если вы определяете свое регулярное выражение как строку, то все обратные слэши необходимо экранировать, поэтому вместо '\ w' у вас должно быть '\ w'.

Или же определите его как регулярное выражение:

 var pattern = /^\w+@[a-zA-Z_]+?\.[a-zA-Z]{2,3}$/; 
  

Здесь написано несколько сложных регулярных выражений, которые тоже работают.

Я протестировал этот, и он тоже работает:

 [a-zA-Z0-9._]+[@]+[a-zA-Z0-9]+[.]+[a-zA-Z]{2,6}
  

Проверьте это здесь: http://www.regextester.com/?fam=97334

Надеюсь, это поможет.

me@localhost не удалось.

Я хотел бы добавить короткую заметку о не-ASCII символах. Решение Rnevius (и других) великолепно, но оно позволяет добавлять кириллицу, японские символы, смайлики и другие символы юникода, которые могут быть ограничены некоторыми серверами.

Приведенный ниже код напечатает true , хотя он содержит символ UTF-8 Ё .

 console.log (/^(([^<>()\[\]\\.,;:\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,}))$/.test ('Ё@example.org'))  

В моем случае все символы не ASCII запрещены, поэтому я изменил исходное выражение, чтобы исключить все символы выше U + 007F:

 /^(([^\u0080-\uffff<>()\[\]\\.,;:\s@"]+(\.[^\u0080-\uffff<>()\[\]\\.,;:\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,}))$/  

Может быть, это поможет кому-то предотвратить нежелательное поведение.

Нах, я думаю, что это достаточно необычный вариант использования, который должен быть его собственным ответом

Как насчет создания функции, которая будет проверять любую строку на соответствие шаблону писем с помощью регулярного выражения в JavaScript, поскольку мы знаем, что адреса электронной почты могут сильно различаться в разных регионах, например, в Великобритании и Австралии это обычно заканчивается на .co.uk или , поэтому я попытался охватить их, а также проверить, передана ли строка в функцию, что-то вроде этого:

 .com.au  

и убедитесь, что это электронная почта, как показано ниже:

 var isEmail = function(str) {
  return typeof str==='string' && /^[\w+\d+._]+\@[\w+\d+_+]+\.[\w+\d+._]{2,8}$/.test(str);
}
   

Что происходит с alireza@test.uk или phil.h\@\@cked+liked~it@haacked.com ?

Стандартный синтаксис Wikipedia:

https://en.wikipedia.org/wiki/Email_address#Examples https://fr.wikipedia.org/wiki/Adresse_%C3%A9lectronique#Syntaxe_exacte

 function validMail(mail)
{
    return /^(([^<>()\[\]\.,;:\s@\"]+(\.[^<>()\[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()\.,;\s@\"]+\.{0,1})+([^<>()\.,;:\s@\"]{2,}|[\d\.]+))$/.test(mail);
}

// VALID MAILS

validMail('Abc@example.com') // Return true
validMail('Abc@example.com.') // Return true
validMail('Abc@10.42.0.1') // Return true
validMail('user@localserver') // Return true
validMail('Abc.123@example.com') // Return true
validMail('user+mailbox/department=shipping@example.com') // Return true
validMail('"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com') // Return true
validMail('!#$%&\'*+-/=?^_`.{|}~@example.com') // Return true
validMail('"()<>[]:,;@\\\"!#$%&\'-/=?^_`{}| ~.a"@example.org') // Return true
validMail('"Abc@def"@example.com') // Return true
validMail('"Fred Bloggs"@example.com') // Return true
validMail('"Joe.\\Blow"@example.com') // Return true
validMail('Loïc.Accentué@voilà.fr') // Return true
validMail('" "@example.org') // Return true
validMail('user@[IPv6:2001:DB8::1]') // Return true

// INVALID MAILS

validMail('Abc.example.com') // Return false
validMail('A@b@c@example.com') // Return false
validMail('a"b(c)d,e:f;g<h>i[j\k]l@example.com') // Return false
validMail('just"not"right@example.com') // Return false
validMail('this is"not\allowed@example.com') // Return false
validMail('this\ still\"not\\allowed@example.com') // Return false
validMail('john..doe@example.com') // Return false
validMail('john.doe@example..com') // Return false
  

Показать этот тест: https://regex101.com/r/LHJ9gU/1

Образец ES6

 const validateEmail=(email)=> /^(([^<>()\[\]\\.,;:\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,}))$/.test(email);
  

Теперь ReactNative версии 0.46 используйте код ниже для проверки электронной почты.

  validateEmail = (email) => {
     var re = /^(([^<>()\[\]\\.,;:\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,}))$/;
     if (re.test(email)) {
     } else {
       alert('email: ' + "Please enter valid emailID.")
     }
 }
  

Вы также можете попробовать

 var string = "hmharsh3@gmail.com"
var exp = /(\w(=?@)\w+\.{1}[a-zA-Z]{2,})/i
alert(exp.test(string))
  

Этот ответ далек от правильного: my.mail@gmail.com уже ломает его

Regex update 2018! попробуйте это

 let val = 'email@domain.com';
if(/^[a-z0-9][a-z0-9-_\.]+@([a-z]|[a-z0-9]?[a-z0-9-]+[a-z0-9])\.[a-z0-9]{2,10}(?:\.[a-z]{2,10})?$/.test(val)) {
   console.log('passed');
}
  

Версия Typscript завершена

 //
export const emailValid = (val:string):boolean => /^[a-z0-9][a-z0-9-_\.]+@([a-z]|[a-z0-9]?[a-z0-9-]+[a-z0-9])\.[a-z0-9]{2,10}(?:\.[a-z]{2,10})?$/.test(val);
  

дополнительная информация https://git.io/vhEfc

Это не удалось для стандартного email@domain.com

@RickS это просто не правда. Проверьте еще раз, пожалуйста

  <input type="email" class="form-control" required="required" placeholder="Email Address" name="Email" id="Email" autocomplete="Email">
 <button class="btn-1 shadow-0 full-width" type="button" id="register">Register account</button>
  

  $("#register").click(function(){       
    var rea = /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;
    var Email = $("#Email").val();
    var x = rea.test(Email);
    if (!x) {
        alert('Type Your valid Email');
        return false;
    }           
 </script>
  

Вот простое регулярное выражение, которое просто проверяет основной формат электронной почты, например, X@Y.C :

\S+@\S+\.\S+

На этот вопрос ответить сложнее, чем кажется на первый взгляд.

В мире было множество людей, которые искали «регулярное выражение, чтобы управлять ими всеми», но правда в том, что есть тоны поставщиков электронной почты.

В чем проблема? Ну, «a_z%@gmail.com не может существовать, но может существовать такой же адрес через другого провайдера» a__z@provider.com.

Почему? По данным РФЦ: https://en.wikipedia.org/wiki/Email_address#RFC_specification . . р>

Я возьму выдержку, чтобы облегчить лекцию:

 The local-part of the email address may use any of these ASCII characters:

- uppercase and lowercase Latin letters A to Z and a to z;
- digits 0 to 9;
- special characters !#$%&'*+-/=?^_`{|}~;
- dot ., provided that it is not the first or last character unless quoted, and provided also that it does not appear consecutively unless quoted (e.g. John..Doe@example.com is not allowed but "John..Doe"@example.com is allowed);[6]
Note that some mail servers wildcard local parts, typically the characters following a plus and less often the characters following a minus, so fred+bah@domain and fred+foo@domain might end up in the same inbox as fred+@domain or even as fred@domain. This can be useful for tagging emails for sorting, see below, and for spam control. Braces { and } are also used in that fashion, although less often.
- space and "(),:;<>@[\] characters are allowed with restrictions (they are only allowed inside a quoted string, as described in the paragraph below, and in addition, a backslash or double-quote must be preceded by a backslash);
- comments are allowed with parentheses at either end of the local-part; e.g. john.smith(comment)@example.com and (comment)john.smith@example.com are both equivalent to john.smith@example.com.
  

Итак, я могу владеть таким адресом электронной почты:

 A__z/J0hn.sm{it!}h_comment@example.com.co
  

Если вы попробуете этот адрес, держу пари, он потерпит неудачу во всех или в большей части регулярных выражений, размещенных по всей сети. Но помните, что этот адрес следует правилам RFC, поэтому он действительно действителен.

Представьте, что я разочарован тем, что не могу нигде зарегистрироваться, проверенный этими регулярными выражениями !!

Единственный, кто действительно может подтвердить адрес электронной почты, - это поставщик адреса электронной почты.

Как с этим бороться, так?

Не имеет значения, добавляет ли пользователь недействительный адрес электронной почты почти во всех случаях. Вы можете положиться на HTML 5 input type = "email", который работает рядом с RFC, и у вас мало шансов на провал. HTML5 input type = "email" info: https : //www.w3.org/TR/2012/WD-html-markup-20121011/input.email.html

Например, это действительное письмо с RFC:

 "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com
  

Но проверка html5 скажет вам, что текст перед @ не должен содержать, например, символы "или (), что на самом деле неверно.

В любом случае, вы должны сделать это, приняв адрес электронной почты и отправив сообщение на этот адрес электронной почты с кодом / ссылкой, которую пользователь должен посетить, чтобы подтвердить действительность.

Хорошей практикой при этом является ввод "введите свой адрес электронной почты снова", чтобы избежать ошибок при вводе пользователем. Если вам этого недостаточно, добавьте модальное окно предварительной отправки с заголовком «Это ваш текущий адрес электронной почты?», А затем сообщение, введенное пользователем внутри тега h2, вы знаете, чтобы четко показать, какой адрес -почту они ввели, затем кнопку "да, отправить".

Как написать особое регулярное выражение в Android или Java.

1) USER_NAME = "^[A-Za-z0-9_-]{min number of character,max number of character}$";

2) TELEPHONE = "(^\\+)?[0-9()-]*";

3) TELEPHONE_OPTIONAL = "^($|(^\\+)?[0-9()-]*)$";

4) EMAIL = "[a-zA-Z0-9_\\.\\+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-\\.]+";

5) EMAIL_OPTIONAL = "^($|[a-zA-Z0-9_\\.\\+-]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-\\.]+)$";

6) WEB_URL = "^($|(http:\\/\\/|https:\\/\\/)?(www.)?([a-zA-Z0-9]+).[a-zA-Z0-9]*.[a-z]{3}.?([a-z]+)?)$";

7) WEB_URL_YOUTUBE_BE = "https?\\:\\/\\/(www\\.)?youtu(\\.)?be(\\.com)?\\/.*(\\?v=|\\/v\\/)?[a-zA-Z0-9_\\-]+";

8) POSTAL_ADDRESS = "[a-zA-Z\\d\\s\\-\\,\\#\\.\\+]+";

9) FIELD_NOT_EMPTY = "[^\\s]*";

10) PINCODE = "^([0-9]{6})?$";

11) IFSC_CODE = "^[^\\s]{4}\\d{7}$";

12) SWIFT_CODE = "^([0-9]{10})?$";

13) PINCODE = "^([0-9]{6})?$";

Это перевод на JavaScript валидации, предложенной официальным руководством Rails, используемым тысячами веб-сайтов:

 /^([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})$/i
  

Относительно прост, но проверяет наиболее распространенные ошибки.

Протестировано на наборе данных из тысяч электронных писем, в котором не было ни одного ложного негатива / позитива.

Пример использования:

 const emailRegex = /^([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})$/i;

emailRegex.test('email@example.com');    // true

// Multi-word domains
emailRegex.test('email@example.co.uk');  // true
emailRegex.test('email@mail.gmail.com'); // true

// Valid special characters
emailRegex.test('unusual+but+valid+email1900=/!#$%&\'*+-/=?^_`.{|}~@example.com') // true

// Trailing dots
emailRegex.test('email@example.co.uk.'); // false

// No domain
emailRegex.test('email@example');        // false

// Leading space
emailRegex.test(' email@example.com');   // false

// Trailing space
emailRegex.test('email@example.com ');   // false

// Incorrect domains
emailRegex.test('email@example,com ');   // false

// Other invalid emails
emailRegex.test('invalid.email.com')        // false
emailRegex.test('invalid@email@domain.com') // false
emailRegex.test('email@example..com')       // false
  

Не работает для drikk@øl.com или любого другого персонажа за пределами a-z

Вот решение, которое работает и включает функциональность проверки / уведомления в форме:

Вы можете запустить его по этой ссылке

JAVASCRIPT

 (function() {
  'use strict';

  window.addEventListener('load', function() {
    var form = document.getElementById('needs-validation');
    form.addEventListener('submit', function(event) {
      if (form.checkValidity() === false) {
        event.preventDefault();
      }
      form.classList.add('was-validated');
      event.preventDefault();              
    }, false);
  }, false);
})();
  

HTML

 <p class='title'>
    <b>Email validation</b>
  <hr size="30px;">
</p>
<br>

<form id="needs-validation" novalidate>
  <p class='form_text'>Try it out!</p>
  <div class="form-row">
    <div class="col-12">
      <input type="email" class="form-control" placeholder="Email Address" required>
        <div class="invalid-feedback">
          Please enter a valid email address.
        </div>
    </div>
  <div class="row">
    <div class="col-12">
      <button type="submit" 
          class="btn btn-default btn-block">Sign up now
      </button>
    </div>
   </div>
</form>
  

Я написал валидатор электронной почты JavaScript, который полностью совместим с реализацией PHP filter_var($value, FILTER_VALIDATE_EMAIL) .

https://github.com/mpyw/FILTER_VALIDATE_EMAIL.js

 import validateEmail from 'filter-validate-email'

const value = '...'
const result = validateEmail(value)
  

эквивалентно:

 <?php

$value = '...';
$result = (bool)filter_var($value, FILTER_VALIDATE_EMAIL, FILTER_FLAG_EMAIL_UNICODE);
  

 function ValidateEmail(mail) 
{
  if (/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(myForm.emailAddr.value))
  {
    return (true)
  }
  alert("You have entered an invalid email address!")
  return (false)
}
  

Ссылочный URL: https://www.w3resource.com/javascript/ форма / электронный-validation.php

Это работает для меня:

 function Email(mail)
{
 if (/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(myForm.emailAddr.value))
  {
    return (true)
  }
    alert("Invalid email address!")
    return (false)
}
  

Часть personal_info содержит следующие символы ASCII.

  1. Прописные (A-Z) и строчные (a-z) английские буквы. Цифры (0-9).
  2. Персонажи! # $% & '* + - / =? ^ _ `{| } ~
  3. Персонаж (точка, точка или точка) при условии, что это не первый или последний символ, и он не придет один за другим.

Доменное имя [например, com, org, net, in, us, info] содержит буквы, цифры, дефисы и точки.

  function ValidateEmail(mail) 
{
 if (/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(myForm.emailAddr.value))
  {
    return (true)
  }
    alert("You have entered an invalid email address!")
    return (false)
}
  

Вы также можете использовать новый класс Regex и сделать так:

function validateEmail( str ) { return new RegExp( /([\w\.\-_]+)?\w+@[\w-_]+(\.\w+){1,}/, 'igm' ).test( str ); }

ссылка: https://developer.mozilla.org/en-US/ документы / Web / JavaScript / Руководство / Regular_Expressions

Вот рекомендуемый шаблон Regex для HTML5 в MDN:

  

Браузеры, которые поддерживают тип ввода электронной почты, автоматически проверяют, чтобы в поле ввода был введен только текст, соответствующий стандартному формату адресов электронной почты в Интернете. Браузеры, которые реализуют спецификацию, должны использовать алгоритм, эквивалентный следующему регулярному выражению:

 /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}
[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/
  

https: //developer.mozilla .org / EN-US / Docs / Web / HTML / элемент / вход / электронная почта # Проверка

Хорошо. Вы когда-нибудь пробовали другие методы проверки, такие как службы PHP или API? Как и инструмент DeBounce Проверка электронной почты .

Вы используете https://github.com/chriso/validator.js и просто сделайте:

 var validator = require('validator');

validator.isEmail('foo@bar.com'); //=> true
  

Обратите внимание, что это может работать на клиенте.

Вот как я это делаю. Я использую match () для проверки стандартного шаблона электронной почты и добавляю класс во входной текст для соответствующего уведомления пользователя. Надеюсь, это поможет!

 $(document).ready(function(){
  $('#submit').on('click', function(){
      var email = $('#email').val();
      var pat = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/;
      if (email.match(pat)){
        $('#email')
          .addClass('input-valid');
        return false;
      } else {
        $('#email')
        	.addClass('input-error')
          .val('');
        return false;
      }
  });
});  
 .input-error {
  border: 1px solid red;
  color: red;
}

.input-valid {
  border: 1px solid green;
  color: green;
}  
 <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<form>
    <input type="text" id="email" placeholder="name@service.xx" class="">
    <input type="submit" id="submit" value="Send"/>
</form>  

Вы когда-нибудь пробовали DeBounce Проверка электронной почты ? Я предлагаю взглянуть на это.

Есть моя версия валидатора электронной почты. Этот код выполняется с помощью объектно-ориентированного программирования и реализуется как класс со статическими методами. Вы найдете две версии валидаторов: строгий (EmailValidator.validate ) и добрый (EmailValidator.validateKind ).

Первый выдает ошибку, если адрес электронной почты недействителен, и возвращает адрес электронной почты в противном случае. Вторая возвращает логическое значение, которое говорит, является ли электронная почта действительной. Я предпочитаю строгую версию в большинстве случаев.

 export class EmailValidator {
    /**
     * @param {string} email
     * @return {string}
     * @throws {Error}
     */
    static validate(email) {
        email = this.prepareEmail(email);

        const isValid = this.validateKind(email);

        if (isValid)
            return email;

        throw new Error(`Got invalid email: ${email}.`);
    }

    /**
     * @param {string} email
     * @return {boolean}
     */
    static validateKind(email) {
        email = this.prepareEmail(email);

        const regex = this.getRegex();

        return regex.test(email);
    }

    /**
     * @return {RegExp}
     * @private
     */
    static getRegex() {
        return /^(([^<>()\[\]\\.,;:\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,}))$/;
    }

    /**
     * @param {string} email
     * @return {string}
     * @private
     */
    static prepareEmail(email) {
        return String(email).toLowerCase();
    }
}
  

Чтобы проверить электронную почту, вы можете выполнить следующие действия:

 // First way.

try {
    EmailValidator.validate('balovbohdan@gmail.com');
} catch (e) {
    console.error(e.message);
}
  
 // Second way.

const email = 'balovbohdan@gmail.com';
const isValid = EmailValidator.validateKind(email);

if (isValid)
    console.log(`Email is valid: ${email}.`);
else
    console.log(`Email is invalid: ${email}.`);
  

Я использую эту функцию

 /**
 * @param {*} email
 */
export const validateEmail = email => {
    return new RegExp(/[\w-]+@([\w-]+\.)+[\w-]+/gm).test(email);
};
  

Не работает для Unicode. validateEmail('køkø@gmail.com') === false . Забудьте проверку с помощью проверок, подобных этой. Проверьте @ и просто отправьте пользователю электронное письмо.

Общее регулярное выражение электронной почты (официальный стандарт RFC 5322): https://emailregex.com/

JavaScript:

 /^(([^<>()\[\]\\.,;:\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,}))$/
  

Аватар Pax

Найдите знак @ в поле ввода.

Эта! Это единственная действительная проверка, которую вы действительно можете сделать, которая не усложняет вещи без необходимости. Если вы действительно хотите узнать, является ли электронная почта действительной, отправьте пользователю электронное письмо.

Если вы хотите что-то, что человек может читать и поддерживать , я бы порекомендовал Masala Parser (я один из его создателей).

 import {C,Streams} from '@masala/parser'

const illegalCharset = ' @\u00A0\n\t';
const extendedIllegalCharset = illegalCharset + '.';


// Assume 'nicolas@internal.masala.co.uk'
export function simpleEmail() {

    return C.charNotIn(illegalCharset).rep() // 'nicolas'
        .then(C.char('@'))
        .then(subDns())  //'internal.masala.co.'
        .then(C.charNotIn(extendedIllegalCharset).rep()) //'uk'
        .eos(); // Must be end of the char stream
}

// x@internal.masala.co.uk => extract 'internal.masala.co.'
function  subDns() {
    return C.charNotIn(extendedIllegalCharset).rep().then(C.char('.')).rep()
}

function validateEmail(email:string) {
    console.log(email + ': ' + (simpleEmail().parse(Streams.ofString(email)).isAccepted()));
}


validateEmail('nicolas@internal.masala.co.uk'); // True
validateEmail('nz@co.'); // False, trailing "."
  

Если вы хотите принять самую уродливую версию электронной почты, вы можете добавить кавычки в первой части:

 
function inQuote() {
    return C.char('"')
        .then(C.notChar('"').rep())
        .then(C.char('"'))
}

function allEmail() {

    return inQuote().or(C.charNotIn(illegalCharset))
        .rep() // repeat (inQuote or anyCharacter)
        .then(C.char('@'))
        .then(subDns())
        .then(C.charNotIn(extendedIllegalCharset).rep())
        .eos() // Must be end of the character stream
        // Create a structure
        .map(function (characters) { return ({ email: characters.join('') }); });
}
  

'"nicolas""love-quotes"@masala.co.uk' официально действителен, но должен ли он быть в вашей системе?

По крайней мере, с Масалой вы даете себе шанс понять это. И так на следующий год, коллега.

Я добавил свой Regex - я решил для себя более мелкие проблемы, такие как символы других языков или заглавные буквы

 ^[a-zA-Z0-9][a-zA-Z0-9-_\.]+@([a-zA-Z]|[a-zA-Z0-9]?[a-zA-Z0-9-]+[a-zA-Z0-9])\.[a-zA-Z0-9]{2,10}(?:\.[a-zA-Z]{2,10})?$
  

Используйте браузер / среду выполнения для обработки синтаксического анализа ввода, добавляя протокол и передавая его в API URL , перехватывая любые ошибки и проверяя получающиеся в результате username и hostname свойства результата. Он будет обрабатывать в основном все преобразования и возможности ( punycode наборов символов и т. Д.). Это только устанавливает, что входные данные могут быть разборными, а не действительными - это возможно только путем проверки, получает ли машина назначения сообщения с таким псевдонимом. Это дает точную (хотя и разумную) догадку, и может быть расширено, чтобы быть более конкретным и реалистичным, если вам удобно как поддерживать его, так и рисковать недействительными отклонениями. (Обратите внимание, что он не пытается адресовать адреса IPv4 или IPv6, просто широкий спектр сценариев, ориентированных на клиента, с использованием домена.)

   

Это самый простой и наиболее общий пример, который я могу придумать. Пожалуйста, отредактируйте его в тех случаях, когда его можно сделать более точным, сохранив при этом его простоту и разумную общепринятую достоверность.

Также см. MDN URL-документы URL-адрес , window.URL и Nodejs для URL API.

для проверки электронной почты вы можете создать собственную функцию и использовать синтаксис регулярных выражений для проверки электронной почты:

 function validateEmail(email){
        var reg = /^([A-Za-z0-9_\-\.])+\@([A-Za-z0-9_\-\.])+\.([A-Za-z]{2,4})$/;

       //your custom code here to check your email address 

}
  

Они будут работать с наиболее часто используемыми электронными письмами ( они точно соответствуют правилам каждого ).

<Сильный> Gmail
/^[a-z]((?!\.\.)([a-z\.])){4,28}[a-z0-9]@google.com$/i

<Сильный> Yahoo
/^[a-z]((?!\.\.)([\w\.])){3,30}[\w]@yahoo.com$/i

<Сильный> Outlook / <сильный> Hotmail
/[a-z]((?!\.\.)([\w\.])){0,62}[\w]@(outlook.com|hotmail.com)$/i

Знаете ли вы, что \w уже включает в себя \d и _ ? Пожалуйста, посмотрите на эти сайты: Список TLD ; действительные / недействительные адреса ; регулярное выражение для адреса электронной почты RFC822

@ Тото верно, я не знаю, как я потерял его там, я фактически использовал это регулярное выражение в моей работе с базой данных: \, еще раз спасибо.

Вы можете попробовать RegExp

 function isValidEmail( value ) {
	return /^[\w\-\.\+]+\@[a-zA-Z0-9\.\-]+\.[a-zA-z0-9]{2,5}$/.test( value );
}

console.log( isValidEmail("mymail@mydomain.com") )  

В моем случае я хочу избежать ~ и # именно поэтому я использую другое решение Нажмите здесь Для получения дополнительной информации

 function validEmail(email){
  const regex = /^((?!\.)[\w-_.]*[^.])(@\w+)(\.\w+(\.\w+)?[^.\W])$/;
  return regex.test(email);
}
  

 function validEmail(email){
  const regex = /^((?!\.)[\w-_.]*[^.])(@\w+)(\.\w+(\.\w+)?[^.\W])$/;
  return regex.test(email);
}

const emails = [
'pio_pio@factory.com',
'~pio_pio@factory.com',
'pio_~pio@factory.com',
'pio_#pio@factory.com',
'pio_pio@#factory.com',
'pio_pio@factory.c#om',
'pio_pio@factory.c*om',
'pio^_pio@factory.com'
]

for(const email of emails){
  document.write(email+' : '+validEmail(email)+'</br>');
}