Как сделать невалидный файл валидным
Обновлено: 06.07.2024
На первый взгляд, кажется, что валидация необходима, ведь речь идет о сокращении количества ляпов разработчиков и написании «правильного» кода. На деле все обстоит гораздо сложнее и вокруг валидации до сих пор ведутся горячие споры об ее актуальности. Чтобы объективно раскрыть этот вопрос далее рассмотрим плюсы и минусы такой проверки.
Плюсы валидации
Хотя HTML-код имеет достаточно простую иерархическую структуру, при разрастании объема документа в коде легко запутаться, следовательно, просто и совершить ошибку. Браузеры, несмотря на явно неверный код, в любом случае постараются отобразить веб-страницу. Но поскольку не существует единого регламента о том, как же должен быть показан «кривой» документ, каждый браузер пытается сделать это по-своему. А это в свою очередь приводит к тому, что один и тот же документ может выглядеть по-разному в популярных браузерах. Исправление явных промахов и систематизация кода приводит, как правило, к стабильному результату.
Тенденции
Времена, когда производители браузеров добавляли уникальные возможности в свой продукт вопреки всем стандартам, начинают уходить в прошлое. Каждая новая версия браузера все больше поддерживает спецификации и отображает документы с минимальными ошибками или вообще без них. Разработчики сайтов, также придерживающихся канонов веб-стандартов, таким образом соответствуют современным тенденциям развития веб-технологий.
Не стоит забывать и об XML (eXtensible Markup Language, расширяемый язык разметки). Этот язык становится стандартом де-факто для хранения данных и обмена информацией между разными приложениями. Синтаксис XML более жесткий, чем HTML и не прощает малейших ошибок. В каком-то смысле XML похож на языки программирования, в которых программа не будет скомпилирована, пока код не отлажен. HTML является первой ступенькой к изучению XML, поэтому приучая себя писать код по всем правилам, будет легче перейти к следующему этапу развития HTML.
Мода на валидацию
Как это не удивительно, но среди веб-разработчиков тоже существует своя мода. Текущая мода — создавать валидные документы и вывешивать специальный значок в виде картинки, что сайт соответствует спецификации HTML. Подобная тенденция затронула даже заказчиков сайтов и при написании технического задания на разработку сайта некоторые из них специально оговаривают, чтобы сайт был выполнен по веб-стандартам.
Косвенные преимущества
Следование стандартам во многом дает множество выгод, которые проявляются в мелочах и становятся заметными при достижении определенной критической массы. В частности, объем кода становится меньше, компактнее и читабельнее. Соответственно, для пользователей повышается скорость загрузки сайта в целом.
Минусы валидации
Сайты, конечно же, делают для того, чтобы их посещали люди. Именно посетители выступают мерилом работы сайта, а их интересует информация и способ ее получения. Пользователь желает, чтобы сайт корректно отображался в его любимом браузере, быстро загружался и содержал те материалы, которые ему нужны. Заметьте, в этом списке нет ничего про код документа и его валидность, посетителей это просто не интересует. Поэтому совершенно невалидный сайт, но выполненный с душой, наполненный интересными материалами привлечет к себе больше посетителей, чем пустой ресурс, но сделанный по всем «правилам».
Браузеры
Разработчики браузеров не всегда следуют спецификации и в некоторых случаях трактуют код не по заданным правилам, а по-своему. В конечном итоге это приводит к тому, что веб-страница, которая правильно (т.е. так, как и задумывали разработчики) отображается в одном браузере, выводится с ошибками в другом. Следование спецификации в подобных случаях, скорее всего, отпугнет пользователей некоторых браузеров. К примеру, Internet Explorer (IE) в настоящее время занимает лидирующее положение среди браузеров, но при этом поддерживает спецификацию HTML и CSS хуже, чем Firefox и Opera. Очевидно, что пользователи IE при посещении сайта выполненного по всем стандартам, но не учитывающего специфику этого браузера, увидят неприглядную картину.
Заказчикам сайта, а также их разработчикам подобная ситуация не по нраву, поэтому стоя перед выбором: стандарты или браузер, они в большинстве своем выбирают браузер.
Резюме
При помощи JavaScript можно проводить валидацию (проверку данных) форм HTML.
Функцию можно вызывать при возникновении события отправки данных формы:
JavaScript может проверять ввод чисел
Часто JavaScript используется для проверки введенных чисел. Попробуйте сами:
Введите число от 1 до 10
Автоматическая проверка HTML форм
Проверка HTML форм также может проводиться браузером автоматически.
В следующем примере, если поле формы (fname) пусто, атрибут required запрещает отправку данных формы:
Внимание! Автоматическая проверка HTML форм не работает в Internet Explorer 9 и более ранних его версиях.
Проверка данных
Проверка данных проводится для того, чтобы гарантировать, что пользователь ввел корректные, полезные данные без ошибок.
- Заполнил ли пользователь все необходимые поля?
- Корректны ли введенные данные?
- Не ввел ли пользователь текст в поля для цифр?
Таким образом, цель проверки данных заключается в обеспечении корректного пользовательского ввода.
Проверка может осуществляться разными способами и реализовываться разными путями.
Проверка на стороне сервера осуществляется веб-сервером после получения им введенных данных.
Проверка на стороне клиента осуществляется браузером до отсылки введенных данных на сервер.
Ограничивающая проверка HTML
В HTML5 была добавлена новая концепция HTML проверки, название которой можно было бы перевести как "ограничивающая проверка" (англ. Constraint Validation).
Ограничивающая проверка HTML основывается на:
- HTML атрибутах элемента ввода,
- CSS псевдоселекторах,
- свойствах и методах DOM
Атрибуты ограничивающей проверки элемента ввода
| Атрибут | Описание |
|---|---|
| disabled | Определяет, что элемент ввода отключен |
| max | Определяет максимальное значение в элементе ввода |
| min | Определяет минимальное значение в элементе ввода |
| pattern | Определяет шаблон значений в элементе ввода |
| required | Определяет, что элемент ввода обязателен для заполнения |
| type | Определяет тип элемента ввода |
CSS псевдоселекторы ограничивающей проверки
| Селектор | Описание |
|---|---|
| :disabled | Выбирает элемент ввода с атрибутом "disabled" |
| :invalid | Выбирает элемент ввода с некорректным значением |
| :optional | Выбирает элемент ввода без атрибута "required" |
| :required | Выбирает элемент ввода с атрибутом "required" |
| :valid | Выбирает элемент ввода с корректным значением |
О том, что такое псевдоклассы см. раздел CSS псевдоклассы.
Методы DOM ограничивающей проверки
| Метод | Описание |
|---|---|
| checkValidity() | Возвращает true, если элемент ввода содержит корректные данные |
| setCustomValidity() | Устанавливает свойство validationMessage для элемента ввода |
Свойства DOM ограничивающей проверки
Свойства валидности
Свойство validity элемента ввода содержит некий набор свойств, определяющих состояние валидности данных:
Пример №1. Свойство rangeOverflow.
Пример №2. Свойство rangeUnderflow.
XML ( англ. eXtensible Markup Language) — расширяемый язык разметки, предназначенный для хранения и передачи данных.
Простейший XML-документ выглядит следующим образом:
Первая строка — это XML декларация. Здесь определяется версия XML (1.0) и кодировка файла. На следующей строке описывается корневой элемент документа <book> (открывающий тег). Следующие 4 строки описывают дочерние элементы корневого элемента ( title , author , year , price ). Последняя строка определяет конец корневого элемента </book> (закрывающий тег).
Документ XML состоит из элементов (elements). Элемент начинается открывающим тегом (start-tag) в угловых скобках, затем идет содержимое (content) элемента, после него записывается закрывающий тег (end-teg) в угловых скобках.
Информация, заключенная между тегами, называется содержимым или значением элемента: <author>Erik T. Ray</author> . Т.е. элемент author принимает значение Erik T. Ray . Элементы могут вообще не принимать значения.
Элементы могут содержать атрибуты, так, например, открывающий тег <title lang="en"> имеет атрибут lang , который принимает значение en . Значения атрибутов заключаются в кавычки (двойные или ординарные).
Некоторые элементы, не содержащие значений, допустимо записывать без закрывающего тега. В таком случае символ / ставится в конце открывающего тега:
Структура XML¶
XML документ должен содержать корневой элемент. Этот элемент является «родительским» для всех других элементов.
Все элементы в XML документе формируют иерархическое дерево. Это дерево начинается с корневого элемента и разветвляется на более низкие уровни элементов.
Все элементы могут иметь подэлементы (дочерние элементы):
Правила синтаксиса (Валидность)¶
Структура XML документа должна соответствовать определенным правилам. XML документ отвечающий этим правилам называется валидным (англ. Valid — правильный) или синтаксически верным. Соответственно, если документ не отвечает правилам, он является невалидным .
Основные правила синтаксиса XML:
- Теги XML регистрозависимы — теги XML являются регистрозависимыми. Так, тег <Letter> не то же самое, что тег <letter> .
Открывающий и закрывающий теги должны определяться в одном регистре:
- XML элементы должны соблюдать корректную вложенность:
- У XML документа должен быть корневой элемент — XML документ должен содержать один элемент, который будет родительским для всех других элементов. Он называется корневым элементом.
- Значения XML атрибутов должны заключаться в кавычки:
Сущности¶
Некоторые символы в XML имеют особые значения и являются служебными. Если вы поместите, например, символ < внутри XML элемента, то будет сгенерирована ошибка, так как парсер интерпретирует его, как начало нового элемента.
В примере ниже будет сгенерирована ошибка, так как в значении "ООО<Мосавтогруз>" атрибута НаимОрг содержатся символы < и > .
Также ошибка будет сгенерирована и в слудющем примере, если название организации взять в обычные кавычки (английские двойные):
Чтобы ошибки не возникали, нужно заменить символ < на его сущность. В XML существует 5 предопределенных сущностей:
| Сущность | Символ | Значение |
|---|---|---|
| < | < | меньше, чем |
| > | > | больше, чем |
| & | & | амперсанд |
| ' | ' | апостроф |
| " | " | кавычки |
Только символы < и & строго запрещены в XML. Символ > допустим, но лучше его всегда заменять на сущность.
Таким образом, корректными будут следующие формы записей:
В последнем примере английские двойные кавычки заменены на французские кавычки («ёлочки»), которые не являются служебными символами.
Поиск информации в XML файлах (XPath)¶
XPath ( англ. XML Path Language) — язык запросов к элементам XML-документа. XPath расширяет возможности работы с XML.
XML имеет древовидную структуру. В документе всегда имеется корневой элемент (инструкция <?xml version=”1.0”?> к дереву отношения не имеет). У элемента дерева всегда существуют потомки и предки, кроме корневого элемента, у которого предков нет, а также тупиковых элементов (листьев дерева), у которых нет потомков. Каждый элемент дерева находится на определенном уровне вложенности (далее — «уровень»). У элементов на одном уровне бывают предыдущие и следующие элементы.
Это очень похоже на организацию каталогов в файловой системе, и строки XPath, фактически, — пути к «файлам» — элементам. Рассмотрим пример списка книг:
XPath запрос /bookstore/book/price вернет следующий результат:
Сокращенная форма этого запроса выглядит так: //price .
В приведенной ниже таблице представлены некоторые выражения XPath и результат их работы:
Кодировки¶
И еще один важный момент, который стоит рассмотреть — кодировки. Существует множество кодировок, о них подробнее можно прочитать в статье Набор символов.
Самыми распространенными кириллическими кодировками являются Windows-1251 и UTF-8 . Последняя является одним из стандартов, но большая часть ФНС отчетности имеет кодировку Windows-1251 .
В XML файле кодировка объявляется в декларации:
Часто можно столкнуться с ситуацией, когда текстовый редаткор некорректно распознает кодировку и отображает кракозябры. В такой случае, необходимо выбрать кодировку вручную, для этого выполните:
| Программа | Кодировка |
|---|---|
| Notepad++ | «Документ → Кодировка» |
| Geany | «Документ → Установить кодировку» |
| Firefox | «Вид → Кодировка» |
| Chrome | «Настройка → Дополнительные инструменты → Кодировка» |
В большинстве случаев при работе с русскоязычными файлами помогает переключение кодировки на Windows-1251 или UTF-8 . Если все равно не удается прочитать содержимое XML документа, стоит открыть его в Mozilla Firefox, он отлично распознает кодировки.
Если ничего не помогает, вполне возможно, что файл был поврежден.
XSD схема¶
XML Schema — язык описания структуры XML-документа, его также называют XSD. Как большинство языков описания XML, XML Schema была задумана для определения правил, которым должен подчиняться документ. Но, в отличие от других языков, XML Schema была разработана так, чтобы её можно было использовать в создании программного обеспечения для обработки документов XML.
После проверки документа на соответствие XML Schema читающая программа может создать модель данных документа, которая включает:
- словарь (названия элементов и атрибутов);
- модель содержания (отношения между элементами и атрибутами и их структура);
- типы данных.
Каждый элемент в этой модели ассоциируется с определённым типом данных, позволяя строить в памяти объект, соответствующий структуре XML-документа. Языкам объектно-ориентированного программирования гораздо легче иметь дело с таким объектом, чем с текстовым файлом.
В данной главе приведены некоторые практические приемы работы с XML-файлами.
Исправление невалидных XML-файлов¶
Если по каким-то причинам между тегами оказывается символ < или лбой другой управляющий символ (подробнее смотрите Таблица I.1 — Сущности ), то при синтаксическом анализе XML-файла возникнет ошибка «Невалидный XML».
Исправляется данная проблема просто — данные символы необходимо заменить на их сущности (подробнее смотрите раздел Сущности ). Сделать это можно, воспользовавшись любым нормальным текстовым редактором с функцией поиска и замены с использованием регулярных выражений.
Также можно воспользоваться скриптом xml_healer.py , который автоматически заменяет управляющие символы на их сущности и удаляет лишние символы после закрывающего родительского тега. Подробная инструкция по работе со скриптом приведена в главе IV. Скрипт для замены служебных символов в XML .
Удаление лишних блоков(абзацев) из XML по заданному условию¶
Теги в структуре XML образуют многострочные блоки. Иногда возникает необходимость удалить ряд целых блоков по заданному условию. В качестве примера будет рассмотрена ситуация с отчетом по НДС .
Из-за несовершенства некоторых программ, периодически возникают проблемы при передаче файлов в контролирующие органы.
Суть проблемы¶
Отрывок книги продаж выглядит следующим образом:
А нижеприведенный блок в Книге продаж необязателен:
Если есть сделки с иностранными контрагентами, у которых нет ИНН/КПП, следовательно, сведения о покупателе не заполняются. Но из-за логической ошибки в программе бухгалтерского учета, выгрузка сформированного отчета была невозможна, так как программа ошибочно требовала указать ИНН/КПП для всех контрагентов.
Чтобы обойти эту ошибку пришлось вместо ИНН указать регистрационный номер контрагента в стране регистрации, а вместо КПП указать девять нулей.
Но при попытке отравить выгруженный отчет в контролирующий орган, возникала обратная ошибка. Так как ИНН и КПП были фиктивными, то при проверке отчета не выполнялись контрольные соотношения.
Проверка файла отчета программой Tester
ИНН и КПП это не произвольный набор чисел, они содержат определенные контрольные соотношения.
Решение проблемы¶
Так как файл содержал свыше 15000 строк и большое количество сделок, надо было автоматизировать данный процесс.
Надо было удалить порядка 700 строк, полностью содержащих блоки (причем с разными псевдо-ИНН):
Большинство программ умеет искать и заменять максимум одну строку на другую. В данном случае надо было искать и заменять блок текста из трех строк.
С этим успешно справилась программа UVFilesCorrector. Интерфейс программы прост до невозможности. В нижней части на вкладке Файлы выбираем нужный нам файл.
В верхнем поле Список замен необходимо нажать на пустое поле и создаем правило для замены. В данном случае оно выглядело так:
На скриншоте видно не все выражение, в поле Что найти: в режиме Шаблон (регулярное выражение) введено:
Десять точек в ИННЮЛ=". " являются регулярным выражением и означают, что на их месте может стоять любой символ. В итоге получилось, что под замену попадали все блоки, имеющие нулевые КПП. Комбинация символов \r\n также является регулярным выражением и означает перенос строки.
Всего у организации было 14 контрагентов, с которыми в общей сумме было заключено 266 сделок. Следовательно, после нажатия на кнопку Заменить получилось 266 замены.
Буквально за один простой шаг по заданному условию было удалено свыше 700 строк. Проверка Tester’ом ошибок не выявила и файл был успешно отправлен в контролирующий орган.
Работа с файлами отчетов Росстата¶
Файлы отчетов Росстата формируются в одну строку, что создает определенные сложности при просмотре в обычных тектовых редакторах.
В отличии, например, от файлов отчетов ФНС.
С файлами Росстата лучше работать с помощью программы XMLPad.
XMLPad имеет несколько режимов отображения:
- Стандартный режим (Source) отображения и редактирования кода.
В левой панели отображается структура XML-файла. Значения элементов можно отреактировать напрямую, либо через левую нижнюю панель.
Читайте также: