Ответ 1
Регулярное выражение представляет собой пользовательскую комбинацию:
- RFC 2234 ABNF
- RFC 2396 Общий синтаксис URI (обремененный RFC 3986)
- RFC 2616 Протокол передачи гипертекста - HTTP/1.1
- Формат сообщений в формате RFC 2822
- RFC 3987 IRI
- RFC 3986 Общий синтаксис URI
Я написал регулярное выражение при создании Web Forms 2.0 и RFC 5322 не существовало. Если вы посмотрите на порядок, в котором были написаны RFC, вы заметите, что определение IRI и URI изменилось после того, как был создан формат сообщений Интернета. Это означает, что RFC 2822 не поддерживает текущие определения IRI. К сожалению, это была не простая задача только подстановки определений, поэтому мне пришлось выбирать, какие определения использовать из RFC. Я также сделал выбор о том, что удалить (например, поддержка комментариев).
Регулярное выражение не полностью написано вручную. Хотя я вручную записывал каждый раздел регулярного выражения, я написал сценарий "клей". Каждое определение из RFC хранится в переменной с составными определениями, использующими переменные, которые хранят более простые определения (@Walf: вот почему так много подшаблонов и орлов).
Чтобы усложнить этот вопрос, версия регулярного выражения, которая используется в плагине проверки jQuery, еще более изменена, чтобы учитывать различия между допустимыми адресами и ожиданием пользователя действительного адреса. Я не помню, какие изменения я сделал. Я пообещал Jörn Zaefferer (автора плагина проверки), что я бы написал новый script для генерации регулярного выражения. Новый script позволит вам указать параметры того, что вы делаете и не хотите поддерживать (требуемые TLD, конкретные TLD, IPv6, комментарии, устаревшие ошибки, цитируемые локальные имена и т.д.). Это было 5 лет назад. Я начал его один раз, но так и не закончил. Возможно, однажды я это сделаю. До сих пор я размещен на GitHub: https://github.com/scottgonzalez/regex-builder
Если вы хотите регулярное выражение для проверки адресов электронной почты, я бы предложил следующее regex, которое включено в спецификацию HTML5:
/^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-][email protected][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])?)*$/
Если вы используете regex-builder и отключите все параметры, вы получите что-то подобное. Но прошло около года с тех пор, как я посмотрел на него, поэтому я не помню, каковы различия.
Я также хотел бы отметить, что ссылка в оригинальном вопросе специально упоминает RFC 822. Хотя это здорово, что RFC 822 продвинул нас из Arpanet в интернет-ARPA, это не совсем актуально. За последние три десятилетия Интернет сделал несколько успехов, и этот RFC был заменен дважды. Я бы хотел увидеть новую работу, соответствующую последним стандартам.
UPDATE:
Друг спросил меня, почему регулярное выражение HTML5 не поддерживает UTF-8. Я никогда не спрашивал об этом Хикси, но я полагаю, что это причина: хотя некоторые TLD начали поддерживать IDN (международные доменные имена) в 2000 году, а RFC 3987 (IRI) был написан в 2005 году, когда RFC 5322 был написан в 2008 году он перечисляет только символы в диапазонах 33-90 и 94-126 как допустимые dtext (символы разрешены для использования в литературе домена). HTML5 основан на RFC 5322, и в результате нет поддержки UTF-8. Кажется странным, что RFC 5322 не учитывает IDN, но ничего не стоит того, что даже в 2008 году IDN не использовались на практике. Только в 2010 году ICANN утвердила первый набор IDN. Однако даже сегодня, если вы хотите использовать IDN, вам в значительной степени нужно полностью уничтожить доменное имя с помощью Punycode, если вы действительно хотите, чтобы такие вещи, как электронная почта и DNS, работали глобально.
ОБНОВЛЕНИЕ 2:
Обновлено регулярное выражение HTML5 в соответствии с обновленной спецификацией, которая изменила ограничения длины ярлыков от 255 символов до 63 символов, как указано в RFC 1034, раздел 3.5.