Контроль целостности загруженных данных

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

Самая главная проверка — на наличие данных. Если ссылка на данные не сработала, или скачан файл длиной 0 байт, проверка не пройдена. Хорошая новость в том, что этого почти никогда не случается.

В информационных технологиях загруженный файл проверяется на соответствие оригиналу через хэш-сумму: обычно MD5 или SHA. Потому что любая из трёх систем в цепочке скачивания может быть ненадёжной: исходный файл на сервере побился, во время передачи данных какие-то байты потерялись или скомпрометированы, во время записи на диск произошла ошибка. Смотрим на сайт, откуда скачали файл данных: если повезло, там указана хэш-сумма в виде очень большого числа в шестнадцатеричной записи и её алгоритм. Обычно это md5 или sha1, и под линуксом или маком им соответствуют команды в терминале (просто md5 имя файла). Под Windows я советую расширение HashCheck, которое выводит хэш-суммы в панели свойств файла. Впрочем, на государственных порталах хэш-сумма не написана, и провести такую проверку не получится.

Если файл загружен без ошибок, следующий шаг — узнать его кодировку. Кодировка — это способ преобразования букв в числа (а файлы хранят именно числа, а не буквы). От кодировки зависит, увидите ли вы в файле русские слова. Все форматы открытых данных текстовые, и методические рекомендации требуют универсальной кодировки UTF-8. Однако поскольку большую часть таблиц готовят в операционной системе Windows, их могут случайно сохранить в специфичной для Windows кодировке 1251. Проверить кодировку просто: откройте в простом текстовом редакторе и загляните в меню вид → кодировка. Например, в редакторе Notepad++, который упоминают в некоторых инструкциях, есть меню «Кодировка», в котором можно подобрать правильную кодировку и преобразовать файл в UTF-8. Разумеется, если вы нашли файл не в UTF-8, сообщите публикатору об этой проблеме в данных.

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

Формат CSV самый непредсказуемый: столбцы могут разделять как запятые, так и точки с запятой или табуляция; значения идут в кавычках и без них; заголовок таблицы может отсутствовать; разделитель целой и дробной части в числах бывает и точкой, и запятой. И, конечно, могут быть неожиданные разрывы строк. Для автоматической проверки Институт Открытых Данных создал сервис csvlint.io: достаточно загрузить туда файл, нажать кнопку «Validate», немного подождать, и получите список ошибок — правда, на английском языке. Он умеет проверять данные на соответствие схеме в формате JSON Table Schema, но маловероятно, что вы найдёте её в файле структуры набора открытых данных. Также есть немало программ для проверки: chkcsv, flat file checker, csv validator, openrefine и другие. Введите «проверка csv» в гугл, и получите их все.

XML проверить проще всего, когда есть файл его схемы DTD или XSD. В линуксах и маках есть команда терминала xmllint, но в принципе достаточно открыть файл любым браузером, и он покажет ошибки. Причём, в случае схемы в формате XSD, у файла проверят не только наличие полей, но и соответствие типов данных. Впрочем, если под видом XML вам выдали файл Microsoft Excel, никакие валидации не помогут проверить данные внутри этого файла, несмотря на формальную корректность «обёртки».

Для формата JSON, можно проверить файл на соответствие формату: что внутри только один объект, что строки заключены в двойные кавычки, и так далее. Для этого есть масса сервисов: например, jsonlint, или валидатор на сайте codebeautify.org (там есть разные валидаторы, в том числе для xml). Валидатор позволит узнать, целиком ли вы скачали файл, и не произошла ли ошибка при его создании у публикатора.

Проверить содержимое файла JSON получится, если у него опубликована структура в формате JSON Schema. Как мы упоминали, формат ещё в статусе черновика, и не так широко известен, как XML Schema, поэтому его редко прикладывают к наборам открытых данных. Но если вам повезло, снова есть сервисы: jsonschemalint.com или jsonschemavalidator.net. Опять же, незачем записывать названия со слов, достаточно ввести в гугле «проверка json».

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

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