Непредвиденная ошибка валидации

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

Ошибка валидации, что это такое?

Для написания страниц используется HTML – стандартизированный язык разметки, применяемый в веб-разработке. HTML, как любой другой язык, имеет специфические особенности синтаксиса, грамматики и т. д. Если во время написания кода правила не учитываются, то после запуска сайта будут появляться различные виды проблем. Если HTML-код ресурса не соответствует стандарту W3C, то он является невалидным, о чем мы писали выше.

Почему ошибки валидации сайта оказывают влияние на ранжирование, восприятие?

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

Как проверить ошибки валидации?

Для этой работы используется либо технический аудит сайта, либо валидаторы, которые ищут проблемы автоматически. Одним из самых популярных является сервис The W3C Markup Validation Service, выполняющий сканирование с оглядкой на World Wide Web Consortium (W3C). Рассматриваемый валидатор предлагает три способа, с помощью которых можно осуществить проверку сайта:

• ввод URL-адреса страниц, которые необходимо просканировать;
• загрузка файла страницы;
• ввод части HTML-кода, нуждающегося в проверке.

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

Существуют другие сервисы, позволяющие выполнить проверку валидности кода:

• Dr. Watson. Проверяет скорость загрузки страниц, орфографию, ссылки, а также исходный код;
• InternetSupervision.com. Отслеживает производительность сайта, проверяет доступность HTML.

Плагины для браузеров, которые помогут найти ошибки в коде

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

• HTML Validator для браузера Firefox;
• HTML Validator for Chrome;
• Validate HTML для Firefox.

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

Как исправить ошибку валидации?

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

• частичная индексация;
• медленная загрузка;
• баги, возникающие во время непосредственной коммуникации пользователя с ресурсом.

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

Технический и SEO-аудит

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

В заключение

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

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

Как открыть Пушкинскую карту

Государство дарит всем желающим молодым людям возможность получать билеты в театры и музеи бесплатно. Акция имеет ограничения, билетов можно заказать на сумму до 3 т.р. Эти деньги будут на карте до конца текущего года. После чего государство снова пополнит карту для покупки билетов на культурные мероприятия на пять тысяч. Для регистрации необходимо скачать на телефон программу Госуслуги.Культура. И войти в учётную запись со своими данными от аккаунта Госуслуг.

На экране приложения в этот момент будет расположена одна кнопка – заказать карту. Её можно получить в виде приложения на телефоне и пользоваться через телефон. Или заказать в Почта Банке в традиционном виде, пластиковую. Выпуск, продление и оплата за использование отсутствуют. На карте есть кэшбэк – 10% с каждой покупки билета. Приобретать их можно на сайте и в мобильном приложении Культура, где была выпущена карта.

Читайте также: как купить билет на концерт по Пушкниской карте.

Причины ошибки регистрации Пушкинской карты

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

Например, знаете ли вы, что подавать заявку на Пушкинскую карту могут люди, которым уже исполнилось 14 лет или человек, который ещё не достиг 22-летнего возраста. Если 23 года исполняется после 1 сентября, вы можете рассчитывать на получение карты. Также если после 1 сентября 2021 года вам исполнилось 14 лет, вы имеете право получить Пушкинскую карту.

Остальная молодёжь, которая не попадает в возрастную категорию культурной программы не может получить средства на покупку билетов. Есть ещё один важный момент, который может быть причиной непредвиденной ошибки валидации при регистрации Пушкинской карты. Учётная запись на портале Госуслуги должна быть только подтверждённой. Если у аккаунта будет другой статус, большая вероятность повторной ошибки при подаче заявки на выпуск карты Пушкинской.

Подтвердить аккаунт доступно через мобильные приложения Сбербанка, Почта Банка, Тинькофф. В одном из них пользователь должен открыть счёт или заказать карту. Для этой операции потребуются личные данные: паспорт, СНИЛС, контакты и прочее. Поэтому у банка уже есть цифровые копии ваших документов. И они могут поручиться за то, что вы реальный человек. Подтверждение аккаунта для Госуслуг на сайтах банков является бесплатной процедурой.

Это интересно: как снять деньги с Пушкинской карты на карту Сбербанка.

Что делать, если Пушкинская карта не выпускается

Необходимо окончательно убедиться, что на пути к регистрации карты для вас нет ограничений – вам уже исполнилось 14 лет, вы имеете подтверждённую учётную запись на Госуслугах. А также вы предоставили необходимые документы, чтобы получить Пушкинскую карту.

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

Используйте для связи следующие контакты:

• Страница в ВКонтакте — https://vk.com/pochtabank;
• Одноклассники — https://ok.ru/pochtabank;
• Телефон: +7 495 532 13 00.

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

Подробнее: Что такое Гоголевкая карта и когда она выйдет.

Как купить билет по Пушкинской карте

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

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

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

Видеоинструкция

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

Просмотров 1.3к. Опубликовано 19.12.2022
Обновлено 19.12.2022

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

Кто и как может открыть Пушкинскую карту

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

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

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

В чем причина ошибки валидации при регистрации

Зарегистрировать Пушкинскую карту может каждый пользователь, подходящий по условиям. А условий регистрации всего лишь два – возраст и наличие верифицированного аккаунта на портале Госуслуг. Аккаунт должен быть подтвержден, а возраст не должен быть меньше 14 лет и старше 22 лет. Правда, если человеку исполняется в сентябре 14 лет или 23 года, он тоже проходит по программе.

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

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

Подтвердить личный профиль можно как с помощью обращение в МФЦ, так и через мобильные приложения любого банка, в котором у пользователя есть карта, счет или какой-либо иной другой продукт, для оформления которого пользователь давал банку личные данные (СНИСЛ, паспорт и т.д.).

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

Для того, чтобы связаться с Почта Банком и службой поддержки, можно перейти на страницу ВКонтакте (https://vk.com/pochtabank), такую же страницу в социальной сети Одноклассники (https://ok.ru/pochtabank) или позвонить по телефону — +7 495 532 13 00.

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

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

Приобретение билета по Пушкинской карте

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

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

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

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

Заключение

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

Ошибки валидации – это ошибки в коде страниц сайта, при этом ошибки на главной странице и на внутренних страницах сайта могут отличаться друг от друга. Сайт считается валидным, если у него отсутствуют ошибки в коде страниц сайта. Ошибки могут появляться в ходе разработки сайта, например, когда неверно закрыты html-теги или не закрыты вовсе, когда используются устаревшие теги, не задан тип документа (<!DOCTYPE html>), некорректно организована вложенность элементов и другие. Часть ошибок могут быть видимыми, и пользователь сможет заметить их при посещении страниц сайта, часть ошибок может быть скрытой от глаз.

Наиболее популярный и зарекомендовавший себя валидатор, на наш взгляд, – validator.w3.org, он сканирует сайт на наличие ошибок в соответствии с принятыми Консорциумом Всемирной паутины стандартами. Данный валидатор имеет 3 способа проверки на ошибки: ввести URL конкретной страницы вашего сайта, загрузить файл страницы сайта и ввести часть кода сайта, которую необходимо проверить.

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

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

Также существуют плагины для браузеров для поиска ошибок на страницах сайта.

http://users.skynet.be/mgueury/mozilla/ – плагин для Mozilla

https://chrome.google.com/webstore/detail/html-tidy-browser-extensi/gljdonhfjnfdklljmfaabfpjlonflfnm – плагин для Chrome

https://addons.opera.com/en/extensions/details/validator/ – плагин для Opera

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

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

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

Давайте проанализируем, сколько ошибок присутствует в коде страниц у крупных ресурсов.

Яндекс:

Google:

ОАО «РЖД»:

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

Кстати, проверка сайта на ошибки, которые действительно влияют на продвижение, проходит в рамках SEO-аудита. Если сомневаетесь, что можете адекватно оценить свой сайт на наличие ошибок, обращайтесь. 

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

Валидация сайта

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

Если простыми словами, то валидация сайта — это проверка кода сайта на техническое соответствие и ошибки. Ну например, вы забыли использовать закрывающий тег — /html.  В последнем HTML5, визуально ничего не поменяется. Однако, это ошибка кода.

При написании кода, возможны и другие ошибки. И опять-таки, современный язык гипер разметки «стерпит» многое. Например, «забытие» закрывающего тега /head. И снова вы не увидите разницу. Но она есть))

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

В чем опасность?

Ну казалось-бы, ну и что тут такого? Да, нужно сказать, что зачастую такие ошибки не видимы. Точнее, невидимы человеком. А ведь страницы нашего сайта могут посетить не только люди, но и поисковые пауки, которые полностью просматривают сайт. И каждую ошибку, которую они находят на сайте, они передают на сервера поисковиков, таких как Яндекс или Гугл.

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

Да, надо признать, определенная пессимизация сайта из-за ошибок валидации, это довольно редкое явление. Но это вполне возможно, а значит, над валидацией обязательно нужно работать. А что для этого нужно сделать? Понятное дело, вначале ошибки нужно найти.

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

Валидатор Markup Validation Service.

Этот сервис проверяет правильность кодов HTML и XHTML, которые являются основой большей части страниц при создании практически любого сайта и определяют его внутреннюю структуру. На этот сервис валидатора можно попасть, если пройти по ссылке http://validator.w3.org

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

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

Вот именно с него и надо начинать.

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

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

Но также может быть и такой нежелательный вариант:

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

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

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

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

1. данный сервис валидатора работает прекрасно и может очень быстро провести проверку сайта.
2. Ну и небольшое, но очень приятное дополнение: валидация сайта производиться бесплатно.
3. Сейчас можно перейти к следующему этапу: это проверка кода CSS.

Валидатор CSS Validation Service

В общем это вторая функция вышеописанного сервиса, но она «заточена» не для проверки кода HTML и XHTML, а конкретно для проверки правильности кода стиля CSS, расположенного на внешней таблице. А чтобы попасть на страницу сервиса, надо пройти по ссылке http://jigsaw.w3.org/css-validator.

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

В общем-то вся работа на валидаторе CSS абсолютно идентична проверке на чистоту кода. Поэтому, приводить отдельную картинку адресной строки валидатора нет необходимости. Просто чуть ниже кратко рассмотрим непосредственно порядок самой проверки и всё.

Для этого надо в адресной строке записать URL таблицы CSS, типа «http://мой сайт/style.css» и после этого нажать кнопку с русской надписью «Проверить». Соответственно, этот валидатор тоже несколько секунд «попыхтит» и выдаст искомый результат:

Это значит, что таблица CSS написана правильно и никаких ошибок в ней не обнаружено.

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

Вполне может быть, что случиться и такой вариант:

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

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

Краткое резюме.

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

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

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

Добавлено 19.04.2018г.

Распространенные ошибки валидности при проверке html кода

Решил дополнить статью ошибками HTML кода, которые часто встречаются на сайтах. Во всяком случае у меня их было много)). Сами ошибки валидатор подсвечивает желтым цветом.

1) Error: Character reference was not terminated by a semicolon.

Ошибка: символ не был прерван точкой с запятой — соответственно надо добавить.

2) Warning: Section lacks heading. Consider using h2-h6 elements to add identifying headings to all sections.

Предупреждение: Раздел не имеет заголовка. Рассмотрите возможность использования элементов h2-h6 для добавления идентифицирующих заголовков ко всем разделам. Тут все понятно, надо добавить хотя бы один подзаголовок. Это даже не ошибка, а рекомендация.

3) Error: Element noindex not allowed as child of element p in this context.

Ошибка: элемент noindex не разрешен как дочерний элемент элемента p в этом контексте. (Подавление дальнейших ошибок из этого поддерева.)
Решение простое, надо закомментировать тег ноиндекс, вид будет таким:

4) Error: The center element is obsolete.

Ошибка: тег «center» устарел — надо заменить, если речь про img то можно использовать атрибут align. Если что-то другое центрировали, то заменить на div.

5) An img element must have an alt attribute, except under certain

Ошибка: Элемент img должен иметь атрибут alt -тут все понятно, надо добавить атрибут альт, даже если он будет незаполненный, то ошибка уйдет.

6) The width attribute on the td element is obsolete. Use CSS instead.

Ошибка: Атрибут «width» на элементе «td» устарел

7) The type attribute is unnecessary for javascript resources

Ошибка: атрибут type не нужен для ресурсов javascript. Решение просто удаляем все лишнее и оставляем только тег «script».

The align attribute on the img element is obsolete.

Ошибка: Атрибут align для элемента img устарел. Сделайте выравнивание изображений дивами.

Ошибка: Неправильное использование тега «li»: отсутствует тег «ul», «ol» . Нужно проверить вложенность элементов списка.

10) End tag for «div» omitted, but OMITTAG NO was specified

Ошибка: Не хватает закрывающего тега div. Решение — добавляем элемент

11) End tag for element «div» which is not open

Ошибка: закрывающий тег div лишний. Соответственно удаляем.

Жду ваших комментариев, а у вас на сайтах валидный код?

Валидация

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

Описанное здесь поведение валидаций и отображение ошибок реализовано в библиотеке «React UI Validations», по возможности используйте эту библиотеку в продукте.

Принципы

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

Виды валидации

Существует три вида валидаций: мгновенная, по потере фокуса и по отправке формы.

Чем раньше интерфейс сообщает об ошибке, тем лучше — пользователю проще вернуться и исправить ошибку.

Валидация по потере фокуса

Когда использовать

Этот вид валидации подходит для большинства случаев.

Как работает

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

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

Валидация при отправке формы

Когда использовать

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

Как работает

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

Блокирование кнопки отправки

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

Сообщения об ошибках

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

Тултипы

Как работают

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

Единообразие поведения и внешнего вида

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

Красные тексты на странице

Как работают

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

Как только пользователь начал исправлять значение, красная подсветка поля исчезает, и цвет текста ошибки меняется на черный — #222.

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

На более сложных формах выводите сообщение об ошибке в тултипе.

Валидация зависимых полей

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

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

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

Пример

Теперь по нажатию кнопки «Отправить» все будет хорошо.

Для более верной работы сайта (магазина, в данном случае), проверяем на наличие ошибок в коде с помощью валидатора https://validator.w3.org/.

Например в статьях на этом сайте есть целых 15 ошибок кода.

Посмотреть их можно здесь.

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

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

Ошибки валидации JoomShopping

У меня ошибки содержались в модулях «Обратный звонок» и в «Фильтре по магазину».

1. Ошибка The type attribute for the style element is not needed and should be omitted

<style type="text/css">

Это устаревший код, сегодня достаточно писать

<style>

2. Ошибка The type attribute is unnecessary for JavaScript resources

<script type="text/javascript">

Тоже устарел, Вместо него везде можно смело писать

<script >

3. Ошибка в «Обратном звонке»

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

Тогда в дефолтном шаблоне модуля ищем:

<form action="<?php echo JRoute::_( '', true, $params->get('usesecure')); ?>" method="post" name="feedback_form" class="form_items">

Конкретно нас интересует:

<?php echo JRoute::_( '', true, $params->get('usesecure')); ?>

Вместо этого можно написать:

<?php echo JRoute::_(/lubaja-nascha-staija); ?>

Я пишу:

<?=$_SERVER['PHP_SELF'];?>

Теперь заказав звонок, клиент магазина останется на странице с тем же товаром (вдруг он его еще не рассмотрел?).

4. Ошибки в модуле фильра товаров JoomShopping

В папке:

modulesmod_jshopping_unijax_filtertmpldefault

Открываем файлы:

vendor.php
manufacturer.php
label.php
delivery_time.php
characteristic.php
category.php
availability.php

И с помощью «Найти-Заменить» в Notepad++ во всех файлах сразу меняем:

value=""></option>

на:

value="">&nbsp;</option>

5. The itemprop attribute was specified, but the element is not a property of any item

В файле шаблона Joomla index.php

Ищем:

<html lang="<?php echo $this->language; ?>" dir="<?php echo $this->direction; ?>">

И делаем:

<html lang="<?php echo $this->language; ?>" dir="<?php echo $this->direction; ?>" itemscope itemtype="http://schema.org/WebPage">

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

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

Эту задачу решает Bean Validation. Он интегрирован со Spring и Spring Boot. Hibernate Validator считается эталонной реализацией Bean Validation.

Основы валидации Bean

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

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

Настройка

Добавьте следующие зависимости в проект:

<dependency>
    <groupId>javax.validation</groupId>
    <artifactId>validation-api</artifactId>
    <version>1.1.0.Final</version>
</dependency>
<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>5.4.1.Final</version>
</dependency>

dependencies {
    compile group: 'javax.validation', name: 'validation-api', version: '1.1.0.Final'
    compile group: 'org.hibernate', name: 'hibernate-validator', version: '5.4.1.Final'
}

Валидация в Spring MVC Controller

Сначала данные попадают в контроллер. У входящего HTTP-запроса возможно проверить следующие параметры:

• тело запроса
• переменные пути (например, id в /foos/{id})
• параметры запроса

Рассмотрим каждый из них подробнее.

Валидация тела запроса

Тело запроса POST и PUT обычно содержит данные в формате JSON. Spring автоматически сопоставляет входящий JSON с объектом Java.

Проверяем соответствует ли входящий Java объект нашим требованиям.

class Input {

     @Min(1)
     @Max(10)
     private int numberBetweenOneAndTen;

     @Pattern(regexp = "^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}$")
     private String ipAddress;

     // ...
}

• Поле numberBetweenOneAndTen должно быть от 1 до 10, включительно.
• Поле ipAddress должно содержать строку в формате IP-адреса.

Контроллер REST принимает объект Input и выполняет проверку:

@RestController
class ValidateRequestBodyController {

  @PostMapping("/validateBody")
  public ResponseEntity<String> validateBody(@Valid @RequestBody Input input) {
    return ResponseEntity.ok("valid");
  }

}

Достаточно добавить в параметр input аннотацию @Valid, чтобы сообщить спрингу передать объект Валидатору, прежде чем делать с ним что-либо еще.

Если класс содержит поле с другим классом, который тоже необходимо проверить — это поле необходимо пометить аннотацией Valid.

Исключение MethodArgumentNotValidException выбрасывается, когда объект не проходит проверку. По умолчанию, Spring переведет это исключение в HTTP статус 400.

Проверка переменных пути и параметров запроса

Проверка переменных пути и параметров запроса работает по-другому.

Не проверяются сложные Java-объекты, так как path-переменные и параметры запроса являются примитивными типами, такими как int, или их аналогами: Integer или String.

Вместо аннотации поля класса, как описано выше, добавляют аннотацию ограничения (в данном случае @Min) непосредственно к параметру метода в контроллере Spring:

@Validated
@RestController
class ValidateParametersController {

  @GetMapping("/validatePathVariable/{id}")
  ResponseEntity<String> validatePathVariable(
      @PathVariable("id") @Min(5) int id
  ) {
    return ResponseEntity.ok("valid");
  }

  @GetMapping("/validateRequestParameter")
  ResponseEntity<String> validateRequestParameter(
      @RequestParam("param") @Min(5) int param
  ) { 
    return ResponseEntity.ok("valid");
  }
}

Обратите внимание, что необходимо добавить @Validated Spring в контроллер на уровне класса, чтобы сказать Spring проверять ограничения на параметрах метода.

В этом случае аннотация @Validated устанавливается на уровне класса, даже если она присутствует на методах.

В отличии валидации тела запроса, при неудачной проверки параметра вместо метода MethodArgumentNotValidException будет выброшен ConstraintViolationException. По умолчанию последует ответ со статусом HTTP 500 (Internal Server Error), так как Spring не регистрирует обработчик для этого исключения.

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

@RestController
@Validated
class ValidateParametersController {

  // request mapping method omitted

  @ExceptionHandler(ConstraintViolationException.class)
  @ResponseStatus(HttpStatus.BAD_REQUEST)
  public ResponseEntity<String> handleConstraintViolationException(ConstraintViolationException e) {
    return new ResponseEntity<>("not valid due to validation error: " + e.getMessage(), HttpStatus.BAD_REQUEST);
  }

}

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

Валидация в сервисном слое

Можно проверять данные на любых компонентах Spring. Для этого используется комбинация аннотаций @Validated и @Valid.

@Service
@Validated
class ValidatingService{

    void validateInput(@Valid Input input){
      // do something
    }

}

Аннотация @Validated устанавливается только на уровне класса, так что не ставьте ее на метод в данном случае.

Валидация сущностей JPA

Persistence Layer это последняя линия проверки данных. По умолчанию Spring Data использует Hibernate, который поддерживает Bean Validation из коробки.

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

Допустим, необходимо хранить объекты нашего класса Input в базе данных. Сначала добавляем нужную JPA аннотацию @Entity, а так же поле id:

@Entity
public class Input {

  @Id
  @GeneratedValue
  private Long id;

  @Min(1)
  @Max(10)
  private int numberBetweenOneAndTen;

  @Pattern(regexp = "^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}$")
  private String ipAddress;

  // ...

}

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

Bean Validation запускается Hibernate только после того как EntityManager вызовет flush.

Чтобы отключить Bean Validation в репозиториях Spring, достаточно установить свойство Spring Boot spring.jpa.properties.javax.persistence.validation.mode равным null.

Валидация конфигурации приложения

Spring Boot аннотация @ConfigurationProperties используется для связывания свойств из application.properties с Java объектом.

Данные из application необходимы для стабильной работы приложения. Bean Validation поможет обнаружить ошибку в этих данных при старте приложения.

Допустим имеется следующий конфигурационный класс:

@Validated
@ConfigurationProperties(prefix="app.properties")
class AppProperties {

  @NotEmpty
  private String name;

  @Min(value = 7)
  @Max(value = 30)
  private Integer reportIntervalInDays;

  @Email
  private String reportEmailAddress;

  // getters and setters
}

При попытке запуска с недействительным адресом электронной почты получаем ошибку:

***************************
APPLICATION FAILED TO START
***************************

Description:

Binding to target org.springframework.boot.context.properties.bind.BindException:
  Failed to bind properties under 'app.properties' to
  io.reflectoring.validation.AppProperties failed:

    Property: app.properties.reportEmailAddress
    Value: manager.analysisapp.com
    Reason: must be a well-formed email address

Action:

Update your application's configuration

Стандартные ограничения

Библиотека javax.validation имеет множество аннотаций для валидации.

Каждая аннотация имеет следующие поля:

• message — указывает на ключ свойства в ValidationMessages.properties, который используется для отправки сообщения в случае нарушения ограничения.
• groups — позволяет определить, при каких обстоятельствах будет срабатывать эта проверка (о группах проверки поговорим позже).
• payload — позволяет определить полезную нагрузку, которая будет передаваться сс проверкой.
• @Constraint — указывает на реализацию интерфейса ConstraintValidator.

Рассмотрим популярные ограничения.

@NotNull и @Null

@NotNull — аннотированный элемент не должен быть null. Принимает любой тип.
@Null — аннотированный элемент должен быть null. Принимает любой тип.

@NotBlank и @NotEmpty

@NotBlank — аннотированный элемент не должен быть null и должен содержать хотя бы один непробельный символ. Принимает CharSequence.
@NotEmpty — аннотированный элемент **не** должен быть null или пустым. Поддерживаемые типы:

• CharSequence
• Collection. Оценивается размер коллекции
• Map. Оценивается размер мапы
• Array. Оценивается длина массива

@NotBlank применяется только к строкам и проверяет, что строка не пуста и не состоит только из пробелов.

@NotNull применяется к CharSequence, Collection, Map или Array и проверяет, что объект не равен null. Но при этом он может быть пуст.

@NotEmpty применяется к CharSequence, Collection, Map или Array и проверяет, что он не null имеет размер больше 0.

Аннотация @Size(min=6) пропустит строку состоящую из 6 пробелов и/или символов переноса строки, а @NotBlank не пропустит.

@Size

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

Поддерживаемые типы:

• CharSequence. Оценивается длина последовательности символов
• Collection. Оценивается размер коллекции
• Map. Оценивается размер мапы
• Array. Оценивается длина массива

Добавление пользовательского валидатора

Если имеющихся аннотаций ограничений недостаточно, то создайте новые.

В классе Input использовалось регулярное выражение для проверки того, что строка является IP адресом. Регулярное выражение не является полным: оно позволяет сокеты со значениями больше 255, таким образом «111.111.111.333» будет считаться действительным.

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

Сначала создаем пользовательскую аннотацию @IpAddress:

@Target({ FIELD })
@Retention(RUNTIME)
@Constraint(validatedBy = IpAddressValidator.class)
@Documented
public @interface IpAddress {

  String message() default "{IpAddress.invalid}";

  Class<?>[] groups() default { };

  Class<? extends Payload>[] payload() default { };

}

Реализация валидатора выглядит следующим образом:

class IpAddressValidator implements ConstraintValidator<IpAddress, String> {

  @Override
  public boolean isValid(String value, ConstraintValidatorContext context) {
    Pattern pattern = 
      Pattern.compile("^([0-9]{1,3}).([0-9]{1,3}).([0-9]{1,3}).([0-9]{1,3})$");
    Matcher matcher = pattern.matcher(value);
    try {
      if (!matcher.matches()) {
        return false;
      } else {
        for (int i = 1; i <= 4; i++) {
          int octet = Integer.valueOf(matcher.group(i));
          if (octet > 255) {
            return false;
          }
        }
        return true;
      }
    } catch (Exception e) {
      return false;
    }
  }
}

Теперь можно использовать аннотацию @IpAddress, как и любую другую аннотацию ограничения.

class InputWithCustomValidator {

  @IpAddress
  private String ipAddress;

  // ...

}

Принудительный вызов валидации

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

class ProgrammaticallyValidatingService {

  void validateInput(Input input) {
    ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
    Validator validator = factory.getValidator();
    Set<ConstraintViolation<Input>> violations = validator.validate(input);
    if (!violations.isEmpty()) {
      throw new ConstraintViolationException(violations);
    }
  }

}

Тем не менее, Spring Boot предоставляет предварительно сконфигурированный экземпляр валидатора. Внедрив этот экземпляр в сервис не придется создавать его вручную.

@Service
class ProgrammaticallyValidatingService {

  private Validator validator;

  public ProgrammaticallyValidatingService(Validator validator) {
    this.validator = validator;
  }

  public void validateInputWithInjectedValidator(Input input) {
    Set<ConstraintViolation<Input>> violations = validator.validate(input);
    if (!violations.isEmpty()) {
      throw new ConstraintViolationException(violations);
    }
  }
}

Когда этот сервис внедряется Spring, в конструктор автоматически вставляется экземпляр валидатора.

Группы валидаций {#validation-groups}

Некоторые объекты участвуют в разных вариантах использования.

Возьмем типичные операции CRUD: при обновлении и создании, скорее всего, будет использоваться один и тот же класс. Тем не менее, некоторые валидации должны срабатывать при различных обстоятельствах:

• только перед созданием
• только перед обновлением
• или в обоих случаях

Функция Bean Validation, которая позволяет нам внедрять такие правила проверки, называется «Validation Groups».

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

Для нашего примера CRUD определим два маркерных интерфейса OnCreate и OnUpdate:

interface OnCreate {}

interface OnUpdate {}

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

class InputWithGroups {

  @Null(groups = OnCreate.class)
  @NotNull(groups = OnUpdate.class)
  private Long id;

  // ...

}

Это позволит убедиться, что id пуст при создании и заполнен при обновлении.

{{< admonition type=warning title=»» open=true >}}
Spring поддерживает группы проверки только с аннотацией @Validated
{{< /admonition >}}

@Service
@Validated
class ValidatingServiceWithGroups {

    @Validated(OnCreate.class)
    void validateForCreate(@Valid InputWithGroups input){
      // do something
    }

    @Validated(OnUpdate.class)
    void validateForUpdate(@Valid InputWithGroups input){
      // do something
    }

}

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

Использование групп проверки может легко стать анти-паттерном. При использовании групп валидации сущность должна знать правила валидации для всех случаев использования (групп), в которых она используется.

Возвращение структурных ответов на ошибки

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

Сначала нужно определить эту структуру данных. Назовем ее ValidationErrorResponse и она содержит список объектов Violation:

public class ValidationErrorResponse {

  private List<Violation> violations = new ArrayList<>();

  // ...
}

public class Violation {

  private final String fieldName;

  private final String message;

  // ...
}

Затем создадим глобальный ControllerAdvice, который обрабатывает все ConstraintViolationExventions, которые пробрасываются до уровня контроллера. Чтобы отлавливать ошибки валидации и для тел запросов, мы также будем работать с MethodArgumentNotValidExceptions:

@ControllerAdvice
class ErrorHandlingControllerAdvice {

  @ExceptionHandler(ConstraintViolationException.class)
  @ResponseStatus(HttpStatus.BAD_REQUEST)
  @ResponseBody
  ValidationErrorResponse onConstraintValidationException(
      ConstraintViolationException e) {
    ValidationErrorResponse error = new ValidationErrorResponse();
    for (ConstraintViolation violation : e.getConstraintViolations()) {
      error.getViolations().add(
        new Violation(violation.getPropertyPath().toString(), violation.getMessage()));
    }
    return error;
  }

  @ExceptionHandler(MethodArgumentNotValidException.class)
  @ResponseStatus(HttpStatus.BAD_REQUEST)
  @ResponseBody
  ValidationErrorResponse onMethodArgumentNotValidException(
      MethodArgumentNotValidException e) {
    ValidationErrorResponse error = new ValidationErrorResponse();
    for (FieldError fieldError : e.getBindingResult().getFieldErrors()) {
      error.getViolations().add(
        new Violation(fieldError.getField(), fieldError.getDefaultMessage()));
    }
    return error;
  }

}

Здесь информацию о нарушениях из исключений переводится в нашу структуру данных ValidationErrorResponse.

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