Санкционировать электронную почту в языке сценариев JavaScript, который принимал бы все латинские символы

Вопрос

Как санкционировать e-mail, который принимал бы все латинские символы?

  • Из-за латинских символов я имею в виду ударные буквы, ñ, ç, и все использованные языками как испанец, португальский язык, итальянец... латино-американцы.

Контекст

  • Цель состоит в том, чтобы показывать значок рядом с текстом по мере того, как пользователь идет tipeando Ваш адрес mail.
  • Мне не интересно принимать все действительные случаи. Это было решение рисунка вмещать только самые частые mails. А именно, буквы (включая акцент и сходные) и символы ._%+-.
  • Я могу использовать код других шрифтов, всякий раз когда они были популярными (ej: jQuery).

Код

document.getElementById('email').addEventListener('input', function() {
    campo = event.target;
    valido = document.getElementById('emailOK');
        
    emailRegex = /^[-\w.%+]{1,64}@(?:[A-Z0-9-]{1,63}\.){1,125}[A-Z]{2,63}$/i;
    //Se muestra un texto a modo de ejemplo, luego va a ser un icono
    if (emailRegex.test(campo.value)) {
      valido.innerText = "válido";
    } else {
      valido.innerText = "incorrecto";
    }
});
<p>
    Email:
    <input id="email">
    <span id="emailOK"></span>
</p>

Случаи

Я использую regex

/^[-\w.%+]{1,64}@(?:[A-Z0-9-]{1,63}\.){1,125}[A-Z]{2,63}$/i

Что функционирует совершенно в случаях как

abcde.fghi@gmail.com
nombre-apellido@do-mi-nio.info

Но не удайся с акцентом и другими латинскими буквами

germán@bla.com
yo@mi-compañía.com
estação@brasil.com.br
90
задан 29.09.2018, 21:08
5 ответов

С этим регулярным выражением ты можешь санкционировать любой почтовый адрес elecrónico, что содержал символы Unicode:

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

Если ты это тестируешь в консоли языка сценариев JavaScript:

> emailRegex.test("abcde.fghi@gmail.com");
< true
> emailRegex.test("germán@bla.com");
< true

Шрифт


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

/^(?:[^<>()[\].,;:\s@"]+(\.[^<>()[\].,;:\s@"]+)*|"[^\n"]+")@(?:[^<>()[\].,;:\s@"]+\.)+[^<>()[\]\.,;:\s@"]{2,63}$/i
89
ответ дан 03.12.2019, 23:22
  • 1
    Эса expresió n регулировать ví в ответе stackoverflow inglé s, y они возражали против то, что он принимает много электронных почт не ICANN как **@as, так как эта expresió n регулярный он не контролирует, что у домена должна была быть по крайней мере точка (домен), что имя пользователя не было больше 255 cará cteres, и т.д. Восток e-mail tambié n кажись, что это tragarí в: juan@{{192.168.1.52}} – Peregring-lk 25.11.2016, 16:49
  • 2
    @Peregring-lk Спасибо за добавление комментариев объясняя различие RFC vs ICANN. Мой вопрос когда бы то ни было apuntó когда санкционирует все возможные форматы e-mail (это невозможно), осветляя, что " был decisió n diseñ или вмещать só это mails má s часто посети ". В особенности, это первая одна validació n, который покрывает altí simo процентное содержание направлений. Но поскольку доказывается в ответе Braiam , só возможно проверять посылая mail. Тем не менее, этот regex sí он санкционирует, что была точка в собственности . – Mariano 23.02.2017, 05:12

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

  • Прописные буквы и строчные буквы английского алфавита.
  • Номера от 0 до 9
  • смоги содержать точку, но не в начало или повторяться.
  • смоги использовать символы:! # $ % и '* +-/=?^ _' {|} ~

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

  • Греческий алфавит.
  • Кириллические символы.
  • Японские символы.
  • Алфавит латинский язык с диакритическими.

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

червь.ca®rton@picnic.com

josé.patroñinio@hotdog.com

Видеть больше:

https://en.wikipedia.org/wiki/Email_address http://tools.ietf.org/html/rfc5322

Я представляю электронную почту с кириллическими символами, хуже еще, если то, что ты хочешь, состоит в том, чтобы хранить эти данные в BD, что тип SQL collation использовать!

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

function validarEmail(valor) {
  if (/^(([^<>()[\]\.,;:\s@\"]+(\.[^<>()[\]\.,;:\s@\"]+)*)|(\".+\"))@(([^<>()[\]\.,;:\s@\"]+\.)+[^<>()[\]\.,;:\s@\"]{2,})$/i.test(valor)){
   alert("La dirección de email " + valor + " es correcta!.");
  } else {
   alert("La dirección de email es incorrecta!.");
  }
}

например:

validarEmail("jorgésys.boc+al@hotflow.com");

Рукописный шрифт показал бы тебе, что адрес электронная почта правилен.


  • Обновление:

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

Традиционные адреса электронной почты ограничены символами английского алфавита и каких-то других специальных символов. Следующие - традиционные действительные адреса электронной почты:

  Abc@example.com                                (English, ASCII)
  Abc.123@example.com                            (English, ASCII)
  user+mailbox/department=shipping@example.com   (English, ASCII)
  !#$%&'*+-/=?^_`.{|}~@example.com               (English, ASCII)
  "Abc@def"@example.com                          (English, ASCII)
  "Fred Bloggs"@example.com                      (English, ASCII)
  "Joe.\\Blow"@example.com                       (English, ASCII)

Международная электронная почта, наоборот, использует символы кодифицированных Unicode как UTF-8, что позволяет кодировать текст адресов в большинстве систем написания мира.

Следующие - все международные действительные адреса электронной почты:

  用户@例子.广告                   (Chinese, Unicode)
  अजय@डाटा.भारत                    (Hindi, Unicode)
  квіточка@пошта.укр             (Ukrainian, Unicode)
  θσερ@εχαμπλε.ψομ               (Greek, Unicode)
  Dörte@Sörensen.example.com     (German, Unicode)
  аджай@экзампл.рус              (Russian, Unicode)
31
ответ дан 03.12.2019, 23:22
  • 1
    Спасибо за информацию. Действительно он подает меня. Хотя определенное достижение не должно покрывать весь RFC, а м и # 225; s хорошо случаи м и # 225; s ген и # 233; богатые, мне интересно оценивать это как opci и # 243; n: и #191; C и # 243; mo помогать и # 237; в это в языке сценариев JavaScript? – Mariano 01.12.2015, 23:23
  • 2
    Это точка полностью v и # 225; lido... Я верю в то, что если pens и # 225; s, который не быть должным, и # 237; чтобы быть санкционированным, быть должным и # 237; чтобы быть expl и # 237; я назначаю встречу в ответе. Этот тип довольно обоснованных ответов стоит мне для того, чтобы определить достижение. – Mariano 01.12.2015, 23:34

Я нашел статью здесь (на Английском языке), что говорит о каких-то заявлениях различные регулярные выражения, которые могут проверять адреса электронной почты, основанный на стандарте RFC. Есть много заявлений регулярных выражений, рекомендуемый различные и нет уникума совсем - en-una решение. Но это регулярное выражение - вероятно тот, который я пошел бы с, добавляя символы, сделанные ударение в список действительных символов также.

\A[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\z
17
ответ дан 03.12.2019, 23:22
  • 1
    И и #191; C и # 243; mo быть и # 237; в versi и # 243; n, что функционировал в языке сценариев JavaScript, и что принял акцент и dem и # 225; s латинские символы? – Mariano 01.12.2015, 23:36
  • 2
    Проблема - что электронная почта RFC-vá lido podrí чтобы быть ICANN-invá lido. А именно, что RFC это позволил, но не существовал ningú n поставщик, который позволял бы тебе иметь электронные почты с этими адресами. – Peregring-lk 25.11.2016, 16:50

Как санкционировать электронную почту, которая принимала бы все латинские символы?

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

Согласно RFC 5322, presidencia@gobierno.pais это "действительная" электронная почта, но: кто-то будет получать это? Сервер существует за доменом, который принимает почту? Это беспокойства, которые у тебя должны бы быть. То, чем ты состоишь в том, что ты делаешь, список адресатов, реестр, и т.д., должно быть, посылает почту подтверждения приема, чтобы это санкционировать. Осуществление будет зависеть от stack, который ты используешь (C#, PHP, Java?) и hací у тебя будет действительная почта, которую кто-то получает.

Ты можешь осуществлять что-то в стороне клиента, который по крайней мере говорит "это direción электронной почты", но это не был бы должен быть твой инструмент "утверждения", только обработай информацию, которого пользователь счета, что то, что он написал, #($ ^ %# $ ^ (#$^.com

14
ответ дан 03.12.2019, 23:22
  • 1
    Полностью договора, ее и #250; nica способ санкционировать - с server. И s и # 237; идея состоит в том, чтобы это был первый этап validaci и # 243; n ген и # 233; богатая, но не завися s и # 243; это в этом (в конце концов язык сценариев JavaScript podr и # 237; чтобы быть выведенным из строя). Очень правильная твой visi и # 243; n, y - форма, в которой я хочу осуществить это. – Mariano 03.12.2015, 05:51

Согласно RFC 6531 должны бы быть вынесенными больше символов в тех, которые мы привыкшие. Но серверы это ограничивают с предыдущими другими. Я не вижу решение с единственным рангом, который подразумевал бы вводить «все латинские символы». Несмотря на то, что кажется, что они идут вместе (как в этой таблице 0080 в 00FF), есть другие из-за в способе.

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

/[A-Za-z\u0021-\u007F\u00C0-\u00D6\u00D8-\u00f6\u00f8-\u00ff]+/g

Было бы возможно соединять с твоим regex, те, что уже они показали ранее или одна согласно RFC 2822, как эта, для того, чтобы он не исключил ранги, которые интересуют тебя (что есть много типов тильд) (шрифт):

^([^\x00-\x20\x22\x28\x29\x2c\x2e\x3a-\x3c\x3e\x40\x5b-\x5d\x7f-\xff]+|\x22([^\x0d\x22\x5c\x80-\xff]|\x5c[\x00-\x7f])*\x22)(\x2e([^\x00-\x20\x22\x28\x29\x2c\x2e\x3a-\x3c\x3e\x40\x5b-\x5d\x7f-\xff]+|\x22([^\x0d\x22\x5c\x80-\xff]|\x5c[\x00-\x7f])*\x22))*\x40([^\x00-\x20\x22\x28\x29\x2c\x2e\x3a-\x3c\x3e\x40\x5b-\x5d\x7f-\xff]+|\x5b([^\x0d\x5b-\x5d\x80-\xff]|\x5c[\x00-\x7f])*\x5d)(\x2e([^\x00-\x20\x22\x28\x29\x2c\x2e\x3a-\x3c\x3e\x40\x5b-\x5d\x7f-\xff]+|\x5b([^\x0d\x5b-\x5d\x80-\xff]|\x5c[\x00-\x7f])*\x5d))*$
10
ответ дан 03.12.2019, 23:22
  • 1
    Хороший ответ. Несомненно быть и # 237; в идеал приспосабливаться к RFC6531. Однако, я верю в то, что не быть и # 237; ни во что f и # 225; cil осуществлять это... Относительно первого regex, est и # 225; оставляя снаружи несколько символов ранга \u0021-\u007F (например они s и # 237; mbolos _%+-)... Относительно второго, оставь снаружи в ударные символы (как á = \u00E1 = \xc3\xa1). – Mariano 02.12.2015, 08:15
  • 2
    Необыкновенный. Первый regex, что я поместил эру для латинских символов, не они s и # 237; mbolos _%+- (я издал ее для в и # 241; adirlos). Относительно второй уже advert и # 237; которого он seg и # 250; n RFC 2822, которая pod и # 237; чтобы направлять основания для в и # 241; adirle первая или первая предварительных ответов. – dayer 02.12.2015, 11:11

Теги

Похожие вопросы