Валидация как разбор с принятием или отклонением
Прежде чем приложение доверит документ, оно должно ответить на более узкий вопрос: хорошо ли сформирован этот текст для заявленного формата? Валидация в этой семье означает синтаксические и структурные проверки—может ли парсер, ориентированный на стандарты, обработать ввод без ошибок,—а не полную сертификацию бизнес-правил или схемы (ес только определение «валидности» формата уже не включает схему).
Инструменты Valid разделяют эту задачу для HTML, XML, SVG, JSON, YAML и CSV. Начните с Valid JSON, если отлаживаете API-нагрузки; та же идея применима к разметке и табличному тексту в перечисленных ниже инструментах.
Что означает «валидный» по форматам
Форматы по-разному определяют глубину «валидности»:
- JSON — грамматика ECMA-404 / RFC 8259: согласованные скобки, ключи в кавычках, без завершающих запятых, допустимые формы чисел. Стандартного шага «JSON Schema» внутри простой parse-валидации нет.
- YAML — успешная загрузка YAML 1.1/1.2: структура отступов, разрешённые теги и стили скаляров. YAML может выражать типы и якоря, недоступные JSON; успешная загрузка не то же самое, что «безопасно загружать недоверенный YAML» в каждой среде выполнения.
- XML — well-formed (согласованные теги, допустимые имена, правила сущностей). Валидность схемы (XSD/DTD) — отдельный, более строгий слой.
- HTML — живые правила HTML-парсинга отличаются от XHTML. Валидаторы могут отмечать незакрытые элементы, неправильно размещённые теги или устаревшие конструкции в зависимости от профиля соответствия движка.
- SVG — графический словарь на базе XML. Well-formed XML необходим; валидный SVG также подразумевает корректную вложенность элементов и атрибутов для пространства имён SVG, хотя лёгкие инструменты часто сначала фокусируются на parse/well-formed проверках.
- CSV — строки полей, разделённых разделителем (часто запятая), с правилами кавычек (семейство RFC 4180). «Валидный» обычно означает согласованное число столбцов, корректное экранирование кавычек и читаемую кодировку—не то, что значения ячеек соответствуют бизнес-схеме.
Понимание нужного слоя предотвращает ложную уверенность: well-formed XML может нарушать отраслевую XSD; parseable JSON может всё ещё не содержать обязательных полей.
Подинструменты в этой семье
- Valid HTML — проверка HTML-разметки на типичные проблемы уровня парсера в страницах и фрагментах.
- Valid XML — проверка well-formed XML-документов и фрагментов.
- Valid SVG — проверка SVG-исходника как структурированной графической разметки.
- Valid JSON — принятие или отклонение JSON-текста по стандартным грамматическим правилам.
- Valid YAML — разбор YAML и вывод ошибок загрузки/структуры.
- Valid CSV — проверка разделённого табличного текста на структурную согласованность.
Выбирайте инструмент, соответствующий Content-Type или расширению файла, которое у вас есть. Не валидируйте YAML JSON-парсером или HTML только XML-чекером, если намеренно не требуете более строгий диалект (например XHTML).
Зачем помогает валидация в браузере
Локальная валидация сокращает цикл обратной связи при создании фикстур, правке фрагментов CMS или проверке скопированного тела ответа. Вы видите построчные ошибки до коммита файлов или деплоя конфигов. Удержание документа в браузере также избегает загрузки чувствительных черновиков на удалённый lint-сервис—хотя буфер обмена и демонстрация экрана всё равно раскрывают содержимое.
Валидация здесь дополняет unit-тесты: тесты по-прежнему должны проверять канонические фикстуры в CI теми же библиотеками, что и продакшен-парсеры. Онлайн-проверки — для исследования и triage; CI — для регрессии.
Формы ошибок, которые стоит узнавать
JSON. Неожиданный токен, незакрытая строка, завершающая запятая, одинарные кавычки, NaN. Редакторы, принимающие JSONC, проходят локально и падают в строгих продакшен-парсерах.
YAML. Табы vs пробелы, неверный отступ под ключом, неоднозначные строки без кавычек (булеанизация on/off в YAML 1.1) и дублирующиеся ключи в зависимости от настроек loader.
XML/SVG. Несовпадающие закрывающие теги, сырой < в тексте, неопределённые префиксы, несколько элементов верхнего уровня или недопустимые управляющие символы. SVG-файлы, задуманные как HTML-встроенные фрагменты, могут не пройти как самостоятельные XML-документы.
HTML. Перекрывающиеся теги, устаревшие атрибуты и ошибки void-элементов. HTML-парсеры часто восстанавливаются; валидатор, сообщающий о проблемах, может описать дерево, которое браузер всё равно отрисует—считайте предупреждения сигналами качества, не всегда жёсткими сбоями runtime.
CSV. Неэкранированные кавычки, встроенные переводы строк в полях без quoting, смешанные разделители (запятая vs точка с запятой) и «рваные» строки с плавающим числом столбцов.
Валидация против трансформации
Валидаторы отвечают да/нет (и где сбой). Форматтеры и конвертеры меняют байты. Документ может быть невалидным и «выглядеть нормально» в снисходительном HTML-парсере браузера, или быть валидным JSON, но неверным для вашей API-схемы. Типичный pipeline:
- Проверить синтаксис для заявленного формата.
- Опционально проверить по схеме (JSON Schema, XSD и т. д.) в коде приложения.
- Только затем трансформировать, объединять или сохранять.
Пропуск шага 1 тратит время на загадочные ошибки трансформации, которые с самого начала были parse-сбоями.
Заметки по безопасности по форматам
- XML: billion laughs / расширение сущностей и атаки внешних сущностей (XXE) важны, когда парсеры разрешают DTD или сущности. Предпочитайте парсеры с отключёнными внешними сущностями для недоверенного ввода.
- YAML: некоторые loader могут конструировать произвольные объекты (теги вроде
!!python/object). Предпочитайте safe-load API для недоверенного YAML. - HTML/SVG: атрибуты script и обработчиков событий — поверхность XSS, когда разметка встраивается в страницы. Валидация ≠ санитизация.
- CSV: injection формул в клиентах таблиц (
=CMD(...)) актуален, когда CSV открывают в Excel; структурная валидность это не нейтрализует. - JSON: обычно безопаснее парсить, чем перечисленные выше форматы, но огромные payload могут вызвать memory DoS; ограничивайте размер на серверах.
Практические сценарии
- Вставьте тело ошибки API в Valid JSON, прежде чем обвинять логику приложения.
- Проверьте фрагмент конфигурации Kubernetes или CI с Valid YAML, если отступы выглядят подозрительно.
- Подтвердите экспорт из таблицы с Valid CSV перед написанием импортёра.
- Проверьте вручную отредактированные иконки с Valid SVG перед bundling.
Ограничения
Эти инструменты не заменяют доменные схемы, аудиты доступности или полные наборы HTML-конформности (например каждую проверку WHATWG). Они не доказывают, что XML удовлетворяет конкретной XSD, JSON — OpenAPI, или столбцы CSV соответствуют DDL базы данных. Они также не санитизируют активный контент. Используйте их как первые ворота: сначала структура, затем смысл.
Связанные инструменты
После успешной JSON-валидации используйте Pretty-print JSON для оформления или From JSON to XML для древовидной проекции. Валидация говорит, съедобен ли документ; другие семьи решают, что готовить.