Проверка корректности информации, введенной в форму с помощью JavaScript

Java Script проверка E-mail введенного в форму

Проверке формальной правильности адреса надо уделять особое внимание.
Типичный e-mail адрес выглядит так: vasya@mail.ru

Сформулируем формальные требования к электронному адресу:

  1. Адрес должен содержать специальный символ «@», который отделяет имя пользователя почтовой системы от доменного имени;
  2. Адрес не должен содержать символов «п робелов», «,», «:», «;», «!», «#», «%», «*», «(«, «)», «=», «+», «<", ">«, «[«, «]/», «»», «‘», «/», «\» и «|»;
  3. Адрес должен состоять только из латинских символов;
  4. Так как в Интернете не существует компьютеров имеющих доменные имена первого уровня, то после символа «@» должна быть как минимум одна «.»;
  5. После последней точки должно быть не менее 2-х и не более 4-х символов, причем наличие цифр не допускается;
  6. Между последней точкой и символом «@» должно быть не менее 2-х символов
  7. Слева от «@» должно быть не менее четырех символов.

Форум тестировщиков

Проверка поля ввода email.

piersto 23 авг 2011

Freiman 23 авг 2011

Romantik 23 авг 2011

Часть адреса до символа @ (логин) может включать любые из этих символов:

  • Английские буквы верхнего и нижнего регистра (a–z, A–Z)
  • Цифры от 0 до 9
  • Символы ! # $ % & ‘ * + — / = ? ^ _ `
  • Символ . (точка) при условии, что он не первый и не последний, а также, если он не повторяется больше одного раза подряд (например, John..Doe@example.com)
  • Общая длина логина может быть вплоть до 64 символов.

    Часть адреса после символа @ (домен) может включать любые из этих символов:

    • Английские буквы нижнего регистра (a–z)
    • Цифры от 0 до 9
    • Символ — (тире)
    • Символ . (точка)

    Части домена, разделенные точкой не должны начинаться с цифры или тире и не должны заканчиватся тире, а также они должны иметь длину от 1 до 63 символов. Общая длина домена должна иметь максимум 253 символа. Доменная часть может быть IP-адресом, заключенным в квадратные скобки (например, jsmith@[192.168.2.1]).

    Romantik 24 авг 2011

    OldGrymza 29 авг 2011

    LeshaL 30 авг 2011

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

    Интересно, сколько раз надо написать одно и тоже.
    RFC — стандарт. Если вы пишете почтовый сервер — будьте добры, соблюдать все это.
    Если ваша веб-програмулька не понимает всех возможных вариантов почтовых адресов — то это ХОРОШО!
    В этом случае ваша программа не протеворечит этому стандарту. Но в ней будет меньше кода, и меньше ошибок, от исправления которых не станет лучше ни одному живому существу на планете.

    Да и это нафиг никому не нужно, поддерживать все эти возможные адреса. И если найдется идиот с ненормальным адресом в 64 символа (или сколько их там) на домене второго уровня — то пусть он идет лесом мимо вашей программы со своим адресом.

    Если вы не тестируете почтовый сервер (ну и возможно клиент тоже) — то использование всяких экзотических емэйлов — (а) трата времени и (б) создание ненужных записей в трэкере. Если бы я был программистом и ко мне бы пришли и сказали «first.(«)middle.last(«)@[IPv6. 12.34.56.78]» — не работает, согласно RFC, давай чинить. Я бы послал куда подальше.

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

    PS: кстати [IPv6. 12.34.56.78] — нихрена невалидный Ipv6 адрес — очередной булшит

    Какие символы разрешены в адресе электронной почты?

    Я не спрашиваю о полной проверке электронной почты.

    Я просто хочу знать, какие символы разрешены в user-name и server частях электронного адреса. Это может быть упрощено, возможно, адреса электронной почты могут принимать другие формы, но мне все равно. Я прошу только об этой простой форме: user-name@server (например, wild.wezyr@best-server-ever.com) и разрешенные символы в обеих частях.

    RFC 822 также охватывает адреса электронной почты, но в основном это касается его структуры:

    И, как обычно, в Википедии есть хорошая статья на адресах электронной почты:

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

    • латинские буквы в верхнем и нижнем регистре A до Z и A до Z ;
    • цифры 0 до 9 ;
    • специальные символы !#$%&’*+-/=?^_`

    ;

  • dot . при условии, что он не является первым или последним символом, если не указан, и при условии, что он не появляется последовательно, если не указано (например, John..Doe@example.com не разрешено, но «John..Doe»@example.com разрешено);
  • и символы «(),:;<>@[\] допускаются с ограничениями (они разрешены только внутри строки с кавычками, как описано в параграфе ниже, и, кроме того, обратной косой чертой или двойной кавычкой должно предшествовать обратная косая черта);
  • комментарии допускаются с круглыми скобками на обоих концах локальной части; например john.smith(comment)@example.com и (comment)john.smith@example.com эквивалентны john.smith@example.com .
  • В дополнение к символам ASCII, с 2012 года вы можете использовать международные символы выше U+007F , закодированы как UTF-8.

    Часть domain определена следующим образом:

    В стандартах Интернета (Запрос комментариев) для протоколов указано, что метки имени хоста компонента могут содержать только буквы ASCII A через Z (без учета регистра), цифры 0 — 9 , и дефис ( — ). Исходная спецификация имен хостов в RFC 952, указала, что метки не могут начинаться с цифры или дефисом и не должны заканчиваться дефисом. Однако последующая спецификация (RFC 1123) позволила названиям имен хостов начинаться с цифр. Никакие другие символы, знаки препинания или пробелы не допускаются.

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

    Чтобы избежать ложноположительных отказов от фактических адресов электронной почты в текущем и будущем мире и из любой точки мира, вам нужно знать, по крайней мере, концепцию высокого уровня RFC 3490, «Интернационализация доменных имен в приложениях (IDNA)». Я знаю людей в США, и часто это не так, но это уже в широко распространенном и быстро растущем использовании во всем мире (главным образом, неанглийских доминированных частях).

    Суть в том, что теперь вы можете использовать адреса, такие как mason @日本.com и wildwezyr@fahrvergnügen.net. Нет, это еще не совместимо со всем, что было там (как многие жаловались выше, даже простые адреса qmail-стиля + идентификаторы часто ошибочно отвергаются). Но есть RFC, там есть спецификация, теперь она поддерживается IETF и ICANN, и, что еще важнее, есть большое и все большее число реализаций, поддерживающих это улучшение, которые в настоящее время находятся в эксплуатации.

    Я мало знал об этом развитии, пока не вернулся в Японию, и начал видеть адреса электронной почты, такие как hei @や る.ca и URL Amazon, как это:

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

    Поэтому я не говорю, что это не хлопот, но полный список символов, разрешенных в рамках каких-либо/любых/нет условий, является (почти) всеми символами на всех языках. Если вы хотите «принять все допустимые адреса электронной почты (и многие недопустимые тоже)», тогда вам нужно принять IDN, что в принципе делает подход на основе символов бесполезным (извините), если вы не первый конвертировать интернационализированные адреса электронной почты в Punycode.

    После этого вы можете следовать (большей части) рекомендаций выше.

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

    • Верхние и строчные английские буквы (a-z, A-Z)
    • Цифры от 0 до 9
    • Персонажи! # $% и ‘* + -/=? ^ _ `
  • Персонаж. (точка, период, полная остановка) при условии, что он не является первым или последним символом и также предусматривает, что он не появляется два или более раза подряд.
  • Кроме того, разрешены цитируемые строки (например, «John Doe» @example.com), что позволяет символам, которые в противном случае были бы запрещены, однако они не встречаются в обычной практике. RFC 5321 также предупреждает, что «хост, который ожидает получать почту, ДОЛЖЕН избегать определения почтовых ящиков, в которых Локальная часть требует (или использует) форму» Котировочная строка «.

    Формат адреса электронной почты: local-part@domain-part (максимум 64 @255 символов, не более 256).

    local-part и domain-part могут иметь различный набор разрешенных символов, но это не все, так как для него существует больше правил.

    В общем, локальная часть может иметь эти символы ASCII:

    • строчные латинские буквы: abcdefghijklmnopqrstuvwxyz ,
    • прописные латинские буквы: abcdefghijklmnopqrstuvwxyz ,
    • цифры: 0123456789 ,
    • специальные символы: !#$%&’*+-/=?^_`

    ,

  • dot: . (не первый или последний символ или не повторяется, если не указано),
  • пространственные пунктуации, такие как: «(),:;<>@[\] (с некоторыми ограничениями),
  • comments: () (разрешены в круглых скобках, например (comment)john.smith@example.com ).
    • строчные латинские буквы: abcdefghijklmnopqrstuvwxyz ,
    • прописные латинские буквы: abcdefghijklmnopqrstuvwxyz ,
    • цифры: 0123456789 ,
    • дефис: — (не первый или последний символ),
    • может содержать IP-адрес, окруженный квадратными скобками: jsmith@[192.168.2.1] или jsmith@[IPv6:2001:db8::1] .

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

    • prettyandsimple@example.com
    • very.common@example.com
    • disposable.style.email.with+symbol@example.com
    • other.email-with-dash@example.com
    • x@example.com (однобуквенная локальная часть)
    • «much.more unusual»@example.com
    • «very.unusual.@.unusual.com»@example.com
    • «very.(),:;<>[]\».VERY.\»very@\ \»very\».unusual»@strange.example.com
    • example-indeed@strange-example.com
    • admin@mailserver1 (локальное имя домена без домена верхнего уровня)
    • #!$%&’*+-/=?^_`<>|

    .a»@example.org

  • » «@example.org (пробел между кавычками)
  • example@localhost (отправлено с localhost)
  • example@s.solutions (см. Список доменов верхнего уровня Интернета)
  • user@com
  • user@localserver
  • user@[IPv6:2001:db8::1]
  • И эти примеры недействительны:

    • Abc.example.com (символ @ )
    • A@b@c@example.com (только один @ разрешен для внешних кавычек)
    • a»b(c)d,e:f;gi[j\k]l@example.com (ни один из специальных символов в этой локальной части не разрешен для внешних кавычек)
    • just»not»right@example.com (цитируемые строки должны быть разделены точками или единственным элементом, составляющим локальную часть)
    • this is»not\allowed@example.com (пробелы, кавычки и обратные косые черты могут существовать только в том случае, если в цитированных строках и предшествует обратная косая черта)
    • this\ still\»not\allowed@example.com (даже если с экранированной (предшествует обратная косая черта) пробелы, кавычки и обратные косые черты должны содержаться в кавычках)
    • john..doe@example.com (двойная точка до @ ); (с оговоркой: Gmail позволяет это через)
    • john.doe@example..com (двойная точка после @ )
    • действительный адрес с ведущим пространством
    • действительный адрес с конечным пространством

    Perl RFC2822 regex для проверки электронной почты:

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

    • RFC 5322 (разделы 3.2.3 и 3.4.1, устаревшие RFC 2822), RFC 5321, RFC 3696,
    • RFC 6531 (разрешенные символы).
    • Верхние и строчные английские буквы (a-z, A-Z)
    • Цифры от 0 до 9
    • Персонажи! # $% и ‘* + -/=? ^ _ `
  • Персонаж. (точка, период, полная остановка) при условии, что он не является первым или последним символом и также предусматривает, что он не появляется два или более раза подряд.
  • Google делает интересную вещь с адресами gmail.com. Адреса gmail.com допускают только буквы (a-z), числа и периоды (которые игнорируются).

    например, pikachu@gmail.com — это то же самое, что и pi.kachu@gmail.com, и оба адреса электронной почты будут отправлены в тот же почтовый ящик. PIKACHU@gmail.com также доставляется в тот же почтовый ящик.

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

    Ссылка на wikipedia — это хорошая ссылка на то, что обычно разрешает адреса электронной почты. http://en.wikipedia.org/wiki/Email_address

    Проверить наличие @и. а затем отправьте электронное письмо для подтверждения.

    Я все еще не могу использовать свой адрес электронной почты .name на 20% сайтов в Интернете, потому что кто-то испортил их проверку по электронной почте или потому, что он предшествует действию новых адресов.

    Короткий ответ: есть 2 ответа. Существует один стандарт того, что вы должны делать. т.е. поведение, которое является мудрым и не позволит вам избавиться от неприятностей. Существует еще один (гораздо более широкий) стандарт поведения, который вы должны принять, не создавая проблем. Эта двойственность работает для отправки и приема электронной почты, но имеет широкое применение в жизни.

    Для хорошего руководства по адресам, которые вы создаете; см. http://www.remote.org/jochen/mail/info/chars.html

    Чтобы отфильтровать действительные электронные письма, просто перейдите на что-нибудь приемлемое, чтобы увидеть следующий шаг. Или начните читать кучу RFC, осторожно, вот драконы.

    Хорошо читать в вопрос.

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

    латинские буквы в верхнем и нижнем регистре A до Z и A до Z ;

    специальные символы !#$%&’*+-/=?^_`

    dot . , при условии, что он не является первым или последним символом, если не указан, и при условии, что он не появляется последовательно, если не указано (например, John..Doe@example.com не разрешено, но «John..Doe»@example.com разрешено);

    и символы «(),:;<>@[\] допускаются с ограничениями (они разрешены только внутри строки с кавычками, как описано в параграфе ниже, и, кроме того, обратной косой чертой или двойной кавычкой должно предшествовать обратная косая черта);

    комментарии допускаются с круглыми скобками на обоих концах локальной части; например john.smith(comment)@example.com и (comment)john.smith@example.com оба эквивалентны john.smith@example.com .

    В дополнение к вышеуказанным символам ASCII международные символы выше U + 007F, закодированные как UTF-8, разрешены RFC 6531, хотя почтовые системы могут ограничивать использование символов при назначении локальных частей.

    Кавычка может существовать как объект, разделенный точками в локальной части, или может существовать, когда крайние кавычки являются внешними символами локальной части (например, abc.»defghi».xyz@example.com или «abcdefghixyz»@example.com )., abc»defghi»xyz@example.com не является, ни abc\»def\»ghi@example.com ). Цитированные строки и символы, однако, обычно не используются. RFC 5321 также предупреждает, что «хост, который ожидает получать почту, ДОЛЖЕН избегать определения почтовых ящиков, где Локальная часть требует (или использует) строка формы».

    Локальная часть postmaster обрабатывается специально — она ​​нечувствительна к регистру и должна быть отправлена ​​администратору электронной почты домена. Технически все остальные локальные части чувствительны к регистру, поэтому jsmith@example.com и jsmith@example.com указывают разные почтовые ящики; однако многие организации рассматривают прописные и строчные буквы как эквивалентные.

    Несмотря на широкий спектр специальных символов, которые являются технически обоснованными; организации, почтовые службы, почтовые серверы и почтовые клиенты на практике часто не принимают их всех. Например, Windows Live Hotmail разрешает создание адресов электронной почты с использованием буквенно-цифровых символов, точек ( . ), подчеркивания ( _ ) и дефиса ( — ). Общие рекомендации — избегать использования некоторых специальных символов, чтобы избежать риска отклоненных писем.

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

    IETF RFC 3696 является авторитетом в этом вопросе, и с ним следует ознакомиться в разделе 3. Ограничения на адреса электронной почты на странице 5:

    Современные адреса электронной почты состоят из «локальной части», отделенной от «доменная часть» (полное доменное имя) с помощью знака at ( «@» ). Синтаксис части домена соответствует таковой в предыдущем раздел. Проблемы, указанные в этом разделе, касаются фильтрации и списки имен применяются к именам доменов, используемым в контексте электронной почты, как Что ж. Имя домена также может быть заменено IP-адресом в квадратные скобки, но эта форма сильно обескуражена, за исключением тестирования и устранения неполадок.

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

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

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

    Символ обратной косой черты также может использоваться для процитирования, например,

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

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

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

    period ( «.» ) также может появляться, но не может использоваться для запуска или завершения локальная часть, а также не может появиться два или более последовательных периода. Иными словами, любой графический (печатный) символ ASCII, кроме знак «at» ( «@» ), обратная косая черта, двойная кавычка, запятая или квадратные скобки могут появляться без кавычек. Если какой-либо из этих исключенных символы должны появляться, они должны быть указаны. Формы, такие как

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

    Как и другие, я отправляю регулярное выражение, которое работает как для PHP, так и для JavaScript для проверки адресов электронной почты:

    Тренды в дизайне email-рассылок в 2017 году

    Колонка дизайн-студии AIC

    Команда дизайн-студии AIC изучила исследования аналитиков и мнения специалистов email-маркетинга и написала для vc.ru колонку с трендами в дизайне email-рассылок в 2017 году.

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

    Тренды 2016 года, которые будут жить в 2017 году

    1. Адаптивный дизайн

    Смартфоны победили десктоп. Согласно исследованиям Litmus, 55% писем открывают на мобильных устройствах. В 2017 году тенденция сохранится, поэтому самое время проверить свои рассылки на адаптивность. Руководствуйтесь основными принципами:

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

    Телефония. Используйте возможности смартфонов: добавьте призыв к действию «позвонить» или «заказать звонок».

    Разные CTA для мобильных и десктопа

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

    Адаптивное меню

    На что обращать внимание

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

    2. Интерактивность

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

    Интерактивные элементы работают на CSS3, а спроектированы могут быть, например, в Adobe Experience Design или Sparkbox. Задача таких инструментов — помочь сосредоточиться на контенте, а не на вёрстке.

    На что обращать внимание

    Сегодня существует множество почтовых клиентов — десктопные приложения (например, Microsoft Outlook, AOL, Thunderbird), веб-сервисы (Gmail, Mail.Ru Group), мобильные клиенты. В зависимости от того, какие технологии они используют, ваши дизайнерские изыскания в виде CSS-анимации будут работать или не работать в разных клиентах. Стоит предусматривать упрощенные варианты отдельных блоков и прописывать их в media queries.

    К слову, в сентябре 2016-го Gmail, наконец, объявил о том, что клиент начинает поддерживать адаптивную верстку писем. Это большой шаг для индустрии почтовых клиентов в целом — переход на адаптивную верстку рассылок станет еще более массовым явлением.

    Анимированные изображения — ещё один способ «оживить» рассылки. У них есть одно важное преимущество — простота производства. В то же время гифки способны наглядно продемонстрировать продукт в действии — поэтому, несмотря на то, что поклонники CSS предрекают скорейшую гибель GIF-анимации, та будет жить и процветать еще долго.

    На что обращать внимание

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

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

    4. Векторные изображения

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

    На что обращать внимание

    Пара полезных JS-библиотек для работы с SVG-анимацией: SnapSVG и GreenSock GSAP.

    5. Покупка в письме

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

    Тренды в email-рассылках 2017 года

    Будущее контент-маркетинга за видео — пишет газета The Guardian. По прогнозам Cisco, к следующему году видео охватит 69% всего интернет-трафика. Оно выйдет за пределы YouTube и будет активно применять в email-маркетинге.

    Компании, уже внедрившие видео в свои рассылки, отмечают их эффективность:

    • Кликабельность увеличивается на 55%.
    • Пользователя тратят на просмотр письма на 44% времени больше, чем обычно.
    • На 41% увеличиваются расшаривания и публикации в социальных сетях.
    • Конверсия растёт на 24%, ROI — на 20%.
    • Средний чек увеличивается на 14%.

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

    На деле вставить видео в рассылку нетрудно — большинство сервисов поддерживает вставку роликов по ссылке (тот же Mailchimp). Видео может быть и фоном для отдельных элементов или всего макета сразу. Для этого есть онлайн-редактор Mailigen.

    2. Галереи изображений

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

    3. Гибридная верстка рассылок

    Технология hybrid coding вместо того, чтобы полагаться на media queries, помогает создавать макеты, адаптивные по умолчанию. Технология совмещает принципы статичной и «резиновой» верстки, что позволяет ей корректно подстраиваться под размеры экрана даже у пользователей Microsoft Outlook.

    4. Яркие цветовые схемы

    Общие тенденции веб-дизайна найдут отражение в рассылках. Дуплекс потеснит полноцветные изображения (мы писали об этом стиле в блоге), а общее оформление писем станет ярким — как в «Мемфисе».

    Насыщенные цвета помогают лучше структурировать контент.

    5. Типографика и навигация

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

    А если письмо получается объёмным, включите в начало содержание. Его можно оформить таблицей с якорными ссылками на отдельные элементы. Это улучшит навигацию и позволит читателям изучить именно тот контент, который им наиболее интересен.

    На что обращать внимание

    Текст — главный инструмент в рассылках. Согласно исследованиям, 43% пользователей не используют просмотр изображений в почтовых программах. Чтобы выделить ключевые сообщения, применяйте стили для текста — цвет, начертание и размер кегля. Сам текст набирайте веб-шрифтами или подгружайте нужные с Google Web Fonts.

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

    6. Интеграция с социальными сетями

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

    Исследование Litmus показало: интеграция с Twitter увеличивает вовлечение. Пользователи твитят с хештегом компании, чтобы увидеть свои посты в рассылке.

    7. Мини-игры в рассылках

    Рассылки всё больше становятся похожи на веб в принципе — все веб-технологии, к которым мы привыкли, постепенно кочуют внутрь писем.

    Мы всё уже привыкли к тому, что рассылки стали интерактивными — опросы, товарные карточки, просто анимированные элементы. В скором времени от email-маркетинга стоит ожидать более смелых экспериментов по вовлечению пользователей — например, в письма будут интегрировать небольшие игры — например, с механикой point-and-click.

    Почему рассылки не умрут в 2017 году

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

    — Пол Бакхейт, программист и ведущий разработчик Google

    Смерть email-маркетингу предрекали много раз — от SMS, социальных сетей и даже приложений для совместной работы. Однако маркетологи продолжают использовать рассылки. Эксперты дают этому три объяснения:

    • Персонализация. Электронная почта — это канал коммуникации, где содержимое можно адаптировать для каждого получателя в отдельности.
    • Окупаемость. Рассылки — один из самых доступных инструментов маркетинга. ROI может достигать 4300%.
    • Измеримость. Эффективность рассылок легко измерить, при этом письма можно оптимизировать и улучшать результаты с каждой отправкой.

    Используйте тенденции в дизайне email-рассылок в своей контент-стратегии и помните, что дизайн — это только половина успеха.

    Правила дизайна и вёрстки email рассылок

    Ширина общего макета, включая рамки, отступы и тени не должна превышать 660px. И, конечно, ширина большого баннера не должна превышать ширины письма.

    Шрифты нужно использовать только стандартные, которые отображаются на всех устройствах: Arial, Verdana, Trebuchet, Courier, Courier New, Tahoma, Georgia, Times, Times New Roman.

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

    • Flash-анимация
    • Java Script
    • Формы
    • Эффекты наведения (:hover)

    Блоки не должны мешать друг другу при вёрстке, слои не накладываются друг на друга, это относится как к разным блокам, так и к однотипным. Блок при блочной адаптации не должен превышать 320px по ширине (вместе с отступами).

    Хранение файлов

    Для каждого нового проекта на сервере создаётся новая папка, в которую загружаются картинки. Пути к картинкам указываются абсолютными.

    Для этих экранов размер иконок .png должен быть в 2 раза большим, чем на самом деле будет отображаться. Т.е. если нам надо вывести иконку размером 70×20, на сервер надо загрузить ее в размере 140×40. И уменьшить ее, указав в коде атрибут width=»70«.

    Подробная статья о вёрстке email рассылок в нашем блоге: HTML вёрстка писем — полная инструкция

    Используется DOCTYPE HTML 4.01 Transitional:

    Что касается кодировки, это utf-8:

    Всё письмо целиком оборачивается в table с шириной в 100%, минимальной шириной и каким-либо фоном (белый, если не нужен другой):

    Далее идёт таблица с шириной макета письма в 660 пикселей (может быть от 600 до 700px):

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

    При ширине экрана больше 660 пикселей, ширина таблицы фиксирована. А если ширина экрана или окна меньше 660 пикселей, ширина таблицы равна 100% и адаптируется под экран.

    Значение атрибутов CELLPADDING и CELLSPACING следует установить как «0», и не используйте никаких значений атрибута BORDER, кроме «0» у table, так как не все почтовые клиенты корректно интерпретируют другие значения.

    Вертикальные и горизонтальные отступы

    Для создания вертикальных отступов используют такой блок:

    По сути это пустой блок с заданной высотой, и другими свойствами для своеобразных почтовиков. Значение свойства font-size меньше height на 2px.

    Для создания горизонтальных отступов можно использовать столбцы таблицы с заданной шириной:

    Для вставки текста используют такую конструкцию:

    По тому же принципу вставляем ссылку:

    Некоторые веб-интерфейсы и почтовые клиенты (особенно мобильные), если находят нечто похожее на номер телефона, заменяют его ссылкой, при этом используют цвета по умолчанию. Чтобы этого избежать, есть два варианта: либо сделать так, чтобы номер не распознавался как номер телефона, либо сразу сделать его ссылкой. В первом случае разделяем отдельные части, используя span. Во втором — прописать ссылку вида:

    Изображения и фон

    Изображение вставляем так:

    Изображение помещаем в блочный элемент с заданным свойством line-height, которое равно высоте изображения. В теге img задаём высоту, ширину, нулевую рамку и стиль (display: block;).

    Если изображение должно подстраиваться под ширину письма, то пишем так:

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

    Обратите внимание — фон задаём именно для td и сразу двумя способами.

    Адаптация (перемещение) блоков

    Для этого используем такую конструкцию:

    Всё дело в блоках со свойством inline-block. В момент, когда блокам не хватает ширины, правый переносится вниз.

    Вёрстка под MS Outlook

    Если вы хотите добавить что-то, что будет понимать только Outlook, используйте комментарии вида:

    В наших письмах они используются для организации таблицы у плавающих блоков (т.к. Outlook не понимает display: inline-block). А так же для фиксации общей ширины письма.

    Популярное в базе знаний:

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

    Через наш сервис можно подписаться на уведомления из постмастера Mail.ru. .

    Основные требования к дизайну и вёрстке email, чтобы письмо корректно отображалось в почтовых клиентах.

    Простая, понятная и иллюстрированная инструкция по использованию utm-меток в ссылках. Зачем нужны, как проставлять, как пользоваться, какие лучшие практики

    Из чего же сделан наш емейл-маркетинг.

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

    Практичный email маркетинг

    №70 Вёрстка рассылок глазами email маркетолога

    В прошлый раз мы рассматривали очередной сегмент подписной базы — «почти лучшие» . Сегодня займёмся вёрсткой email рассылок.

    Впрочем, в пучины div-ов и span-ов заныривать глубоко не будем
    (для желающих есть полезный блог Артура Коха или ещё вот такая
    статья на Хабре ). А коснёмся основных моментов, которые нужно знать маркетологу, чтобы разработать внятный email шаблон и начать им пользоваться.

    Требования к вёрстке рассылок

    Предположим, у вас на руках появился макет шаблона для рассылки в одном из графических форматов (обычно в PSD), выполненный с соблюдением всех принципов дизайна email .

    Прежде чем приступать к вёрстке, сформулируем для себя основные требования, которых стоит придерживаться:

    • Вёрстка должна корректно отображаться
    в разных почтовиках

    Это требование аналогично кроссбраузерности веб-страниц: свёрстанное письмо должно одинаково хорошо выглядеть в ящиках всех распространённых почтовых сервисов/клиентов.

    Для отечественной аудитории это как правило: Mail, Yandex, Gmail, Rambler и Outlook (разных годов выпуска).

    Чтобы выяснить это точнее, можно провести небольшое исследование собственной базы — с помощью таблицы Excel или встроенных возможностей рассылочных сервисов:

    100% идеального отображения везде вряд ли удастся достичь, но если у вас база b2b и половина подписчиков использует Outlook, нужно уделить ему особенное внимание при вёрстке.

    В целом, стоит стремиться к качественному отображению вёрстки в основных почтовиках, и приемлемому — во всех остальных (например, в такой относительной экзотике, как Thunderbird или The Bat!).

    • Вёрстка должна корректно отображаться
    на мобильных устройствах

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

    Ширина контентной части 600px решает большинство вопросов с ноутбуками и планшетами. Но для смартфонов письмо должно уметь становиться более компактным:

    Увлекаться медиазапросами, чтобы перетасовывать и выборочно скрывать контентные блоки, пожалуй, не стоит — не все почтовики это переваривают. Для среднестатистической email рассылки вполне хватает «резиновой» вёрстки, которая подгоняет ширину изображений и текстов под размер экрана.

    • Вёрстка должна корректно отображаться без картинок

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

    Поэтому при вёрстке email необходимо учитывать, как будет смотреться письмо без изображений.

    Как минимум, для значимых картинок нужно прописывать alt-текст. Неплохо при этом использовать стили для «подложек» изображений:

    Незначимые картинки в незагруженном виде можно полностью скрывать,
    а крупные — масштабировать:

    Наконец, верстать письмо сплошными картинками — дурной тон.
    Конечно, так проще передать все красивости дизайна, но тогда нужно быть готовым и к такому повороту:

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

    • Вёрстка должна быть выполнена независимыми блоками

    Это требование вытекает из особенностей работы с шаблоном рассылки, как с конструктором, каждый «кубик» которого можно передвинуть или удалить.

    Некорректно выполненная вёрстка не позволяет этого, чрезмерно «склеивая кубики» между собой. Тогда сдвиг одного «кубика» потащит за собой и другие части шаблона:

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

    Для удобства каждый обособленный блок вёрстки снабжается соответствующими примечаниями в коде, обозначающими его
    начало и конец:

    Тогда редактировать шаблон, перетасовывая, дублируя и вычищая блоки, будет несложно.

    Теперь, когда общие представления о вёрстке рассылок сложились,
    пора приступать к делу. Если вам знакомы html/css и вы располагаете достаточным количеством времени (для первого опыта смело закладывайте часов 10), можете дерзнуть и заняться кодом самостоятельно.

    Во всех прочих случаях рекомендую обратиться к верстальщику.
    Благо вёрстка рассылок сейчас не такая редкость, как несколько лет назад, и за 10-15$ в час вы найдёте себе подходящего специалиста:

    Подготовьте небольшое техническое задание, в котором опишите все перечисленные выше требования — «кроссплатформенность», адаптивность и т.п. — и передайте его в работу верстальщику.

    Хорошо, если верстальщик дополнит результат мануалом
    (например, таким ), где опишет все нюансы работы со своим кодом:
    блоки, редактирование, адаптация. Использовать шаблон в таком случае будет гораздо легче.

    Вёрстка и рассылочные сервисы

    Поскольку для рассылок как правило используются рассылочные сервисы , понадобится внедрить в них свёрстанный шаблон.

    Основные способы сделать это:

    • Вставить шаблон html-кодом

    Многие сервисы поддерживают такую возможность:

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

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

    • Вставить шаблон в html-редактор

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

    Можно вставлять картинки с alt, прописывать ссылки с title, менять форматирование текстов (шрифт, размер, цвет) с помощью соответствующих инструментов редактора.

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

    Однако во многом эту проблему снимают Drag&Drop редакторы , которыми всё чаще обзаводятся рассылочные сервисы. Это аналоги html-редакторов, но с возможностью оперировать сразу целыми блоками контента и менять в них основные настройки: выравнивание, отступы, количество столбцов и т.д.

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

    Если вы предполагаете пользоваться Drag&Drop изначально, предупредите об этом верстальщика. Возможно, ему сразу нужно поставить задачу сверстать шаблон под редактор конкретного сервиса.

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

    Для тестирования стоит завести ящики во всех перечисленных почтовиках: Mail, Yandex, Gmail… Хорошо бы иметь в своём распоряжении пару смартфонов с iOS и Android (привлечь к тесту коллег и друзей).

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

    Упростить задачу может специальный тестировочный сервис
    Litmus.com , который покажет, как смотрится вёрстка в разных ящиках
    в едином отчёте:

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

    Скорее всего, с первого раза шаблон не выдержит испытание всеми почтовыми клиентами. На какие-то недостатки можно закрыть глаза (особенно в таких «вредных» штуках, как Outlook), серьёзные огрехи исправить.

    Тестировать шаблон необходимо «до победного». Очень важно, чтобы вёрстка была выполнена качественно. Тогда и письма, собранные на основе шаблона, автоматически будут удовлетворять тем же требованиям.

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

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

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

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

    [В следующий раз поговорим об аналитике email рассылок —
    для чего и как учитывать прирост базы подписчиков → ]

    P.S. Вы находите материалы Email-practice полезными?
    Тогда читайте мою книгу «E-mail маркетинг для интернет-магазина» !

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

    Смотрите так же:  Компенсация питания в школе