Методичні матеріали «Формати даних» розроблені з метою ознайомлення відповідальних осіб з ключовими поняттями про формати запису даних – бінарні і текстові, структурні і табличні, мови программування та практичного застосування їх у роботі. Дається поняття людиночитаності і машиночитаності формату.
Вимірюючи явища світу, людина не може покладатися на свою пам’ять. Тому отримані дані належним чином записують. Записи даних – байдуже, на глиняній табличці чи в базі даних – мають спільні властивості. Втім, недотримання порядку записування даних може зробити дані незрозумілими не лише іншій людині, а й самому автору запису.
Оскільки дані – не просто числа, а числа, пов’язані з певними вимірами певного об’єкта реальності, найприроднішим способом організації такої інформації є список. Вимірюючи певний об’єкт, людина складає список його вимірів (довжина, ширина, вага) зі значеннями. Якщо об’єктів декілька, утворюється список списків, який зручно оформлювати у таблицю, де перший стовпчик є списком об’єктів, а подальші відповідають кожній з вимірюваних властивостей.
В письмовій формі дані найчастіше записують у форматі таблиць і систем пов’язаних між собою таблиць – від багатосотсторінкових довідників до рукописних амбарних книжок. Тому не дивно, що першим практичним додатком, що сприяв поширенню персональних комп’ютерів, був VisiCalc – електронна таблиця, яка мала всі основні риси тих електронних таблиць, що досі лишаються найпопулярнішим засобом організації і обробки даних на персональному компьютері.
Електрона таблиця не є панацеєю, але виступає «швейцарським армійським ножем» роботи з даними: в неї досить зручно вводити зібрані дані, з неї досить зручно зчитувати дані, в ній можна виконувати операції з обробки даних. Хоча сучасні електронні таблиці дозволяють працювати з багатьма таблицями і виконувати досить складні операції із вміщеними в них даними, для справді великих наборів внутрішньо пов’язаних даних і операцій з ними використовуються системи керування базами даних, такі як MySQL, Postgress, Microsoft Access, тощо.
Крім того, для багатьох задач роботи з даними існують спеціалізовані програми, наприклад, обліково-бухгалтерські, геоінформаційні тощо.
Бази даних і спеціалізовані програми можуть імпортувати –експортувати частини (фрагменти) даних як таблиці, але використовують і складніші способи їх запису, що дозволяють зберігати їхню структуру.
З точки зору простого користувача, кожна програма працює зі своїми специфічними форматами файлів, які часто навіть називають за іменами програм (частіше чуємо «надішліть мені в Ворді» а не «надішліть мені в докікс» чи «надішліть мені в офісопенексімел»). «Просунутий» користувач знає, що деякі програми вміють відкривати файли інших програм, і записувати файли інших програм з більшим чи меншим успіхом. Таким чином, можна казати про типи форматів файлів (електронна таблиця, документ офісного редактора, растрове зображення тощо). Файли одного типу більш – менш подібні за можливостями між собою. Але для кращого розуміння варто зазирнути цим форматам файлів, образно кажучи, під капот.
Бінарні і текстові файли.
Типовий комп’ютер працює з двома станами – нулем (струму немає) і одиницею (струм є).
Послідовності цих станів являють собою двійкові числа. Якщо файл складається просто з нулів та одиниць, такий файл називається бінарним. Бінарні файли можуть бути як послідовностями команд процесора – програмами, так і файлами даних програм, наприклад формат Microsoft Excel .xls (основний формат до версії 2007 року) є бінарним. Бінарними є практично всі файли відео, зображень і звуку.
З іншого боку, ще з часів розробки телеграфії існує практика кодування символів (літер, цифр, тощо) числами, зокрема двійковими. Файл, що складається з потоку кодованих символів, називається текстовим.
Таблиці кодування.
Існує велика кількість таблиць кодування текстових файлів. Найстандартнішою з них є ASCII, вона містить лише числа, літери латинської абетки і деякі спеціальні символи.
В нашому регіоні поширена таблиця кодування з символами кирилиці, відома як Windows-1251 чи CP-1251, до 127 символу збігається з ASCII. Проте в ній неможливо використати, наприклад, латинські літери з діакритикою типу ç чи å або математичні символи типу ⋽ чи ∀. Тому безпечніше тримати текстові дані в іншій таблиці кодування – Unicode, яка містить символи всіх живих і багатьох мертвих писемностей, а також багато спецсимволів – від математичних позначок до смайликів. Її різновид UTF-8, крім того, сумісний з ASCII (перші 127 символів співпадають), що зробило його «основним кодуванням 21 століття». Саме це кодування вважається кодуванням за замовчуванням, наприклад, в родині мов XML. Існують інші різновиди юнікода, вони мають таку саме таблицю символів, але використовують інші підходи до побудови кодів і несумісні з ASCII.
Для перекодування між різними таблицями кодувань застосовуються спеціальні програми, наприклад, recode чи iconv та online-сервіси, типу 2cyr.com/decode, орієнтованого, в тому числі, на перекодування в читабельний вигляд кількаразово неправильно перекодованих текстів.
Людино - і машиночитані дані.
В довкола комп’ютерному світі ми часто стикаємося із поняттями «людиночитаності» та «машиночитаності» формату. Їхні значення не зовсім такі, як це зрозуміло інтуїтивно, зокрема «людиночитаний» не означає «легко читаний людиною».
Машиночитаним називають формат стандартною комп’ютерною мовою, що може бути зчитаний автоматично браузером чи іншою комп’ютерною системою. Документи офісних редакторів документів та PDF-файли легко читані людиною, але, як правило, складні для машинної інтерпретації. Такі формати як XML, JSON, CSV із заголовками колонок є машиночитаними форматами. HTML, як структурна мова розмічування, за правильного застосування в поєднанні з мікроформатами, може бути одночасно людино – і машиночитаним форматом. За належного використання засобів структурування, документи текстових редакторів теж можуть бути машиночитанми.
Людиночитаними називають такі формати, які можна відкрити за допомогою простого текстового редактора, типу блокнота Windows і щось там розібрати або відредагувати. Тобто, цілком читабельний текст у зображенні не є ані машиночитаним, ані людиночитаним. Текстові файли мають перед бінарними дві переваги – вони «людиночитані» і менш прив’язані до конкретної програми. Це означає, що вони можуть бути відредаговані будь-яким текстовим редактором (не варто плутати текстові редактори типу блокнота Windows чи складного EMACSа з редакторами документів типу Word, Pages чи Writer – це принципово різні програми) або навіть скриптом, а не лише тією програмою, якою їх створено. Як літерами на папері можна написати звіт, роман, формулу, таблицю, тощо, так і всередині текстового файла можна створювати найрізноманітніші структури – від вихідного коду різних мов програмування, текстів та даних із застосуванням числених мов розмічування, зокрема, HTML, до цілих файлових систем із бінарними файлами всередині.
З іншого боку, бінарні файли значно компактніші за текстові. Проте і їх можна привести до компактнішого стану, використовуючи алгоритми компресії, що може відбуватися як на рівні одного файла чи групи файлів (так працюють програми-архіватори типу ZIP, RAR, 7Z, bzip2 тощо), так і на рівні файлової системи чи протоколу передачі. Алгоритми компресії стискають текстові файли дуже ефективно, тому на поточний момент значна кількість широковживаних форматів файлів є надбудовами над текстовим файлом або над стисненим каталогом, що містить текстові і бінарні файли різних форматів.
Файли – каталоги.
Файли багатьох широковживаних сучасних форматів є саме стисненими (як правило, 7Z) каталогами, що дозволяє використовувати досить елегантні методи часткового експорту даних. Наприклад, для експорту зображень з Word’івського DOC(X), Open/LibreOffice ODT або електронної книжки EPUB досить розархівувати їх (створивши копію з розширенням 7Z, або просто за допомогою команди unzip -d куди_розпакувати файл DOC(X)) і взяти файли зображень з каталогів word/media в DOC(X), Pictures в ODT або media в EPUB. Можна відредагувати ці зображення і знову стиснути каталог, перейменувавши з 7Z на відповідний формат – все працюватиме.
Одже, розглянемо деякі формати текстових файлів, що використовуються для запису даних.
Значення з роздільниками CSV.
Найпростіше записати дані у файл, відокремлюючи значення якимось роздільником. Це може бути пробіл, новий рядок, табулятор тощо, але найбільшого поширення набуло використання коми.
Формат, де поля значень розділено комами, називається CSV – Comma Separated Values, це найрозповсюдженіший формат для збереження табличних даних у текстовий файл. Записати CSV дозволяє не лише список значень, але й просту таблицю, починаючи кожен рядок таблиці з нового рядка. Перший рядок може містити заголовки стовпчиків таблиці. В CSV неоднакова кількість полів даних (комірок таблиці) у кожному записі (рядку) вважається помилкою і такий файл не обробляється. Поле даних може охоплюватися подвійними лапками ("), наприклад, для включення в нього коми або символу нового рядка, що не є роздільниками.
Спостереження за цінами на черешні з початку цього розділу у форматі CSV можуть виглядати наступним чином:
Продавець, Ціна, Якість (бал)
"Пані в 1 ряді", 35, 4
"Пан в кашкеті", 35, 3
"Пан з акцентом", 40, 5
"Бабуся при виході", 30, 3
Фактично, це табличка, і після імпорту до електронної таблиці це виглядатиме приблизно так:
|
|
|
|
---|---|---|---|
|
А
|
В
|
С
|
1 | Продавець
|
Ціна
|
Якість (бал)
|
2 | Пані в 1 ряду
|
35 | 4
|
3 | Пан в кашкеті
|
35 | 3 |
4 | Пан з акцентом
|
40 | 5 |
5 | Бабуся при виході
|
30 | 3 |
CSV таблиці та кодування текстових файлів.
Поширене бачення CSV як де-факто стандарту запису табличних даних. Справді, дані в такому форматі імпортують і експортують чи не всі електронні таблиці та бази даних. Не менш важливо, що в CSV можна зберегти лише самі дані – без формул, макросів тощо, які не є даними, а методами їх обробки, і які тою чи іншою мірою інкорпорують файли електронних таблиць. Але є важливе «але» – кодування. Якщо дані є чистими, проблем немає, але якщо текстові комірки містять кирилицю, латинську діакритику тощо CSV файл може бути зламаний. Тобто, всі файли CSV треба кодувати у UTF-8 – найпотужніший підтримуваний стандарт кодування текстових файлів. Але Microsoft Excel не дає можливості вибирати кодування для CSV-файлів, кодуючи їх у стандартне системне восьмибітне кодування, для українізованої Windows, це буде Windows-1251 (позбудеться латиниці з діакритикою), а для американської – Windows-1252 (позбудеться кирилиці).
Для вирішення цієї проблеми можливі кілька підходів:
1.Зберігати не в CSV, а в унікодовий текст (роздільником буде табулятор) і переробляти отримані файли на CSV заміною табуляторів на компьютері.
2.Встановити відповідне розширення (add-in).
3.Використовувати Google Spreadsheets чи Open/LibreOffice Calc.
Важливо пам’ятати, що Calc показуватиме діалог вибору кодування під час збереження в CSV, якщо відкритий файл є файлом електронної таблиці, якщо відкрити ним CSV у певному кодуванні, він зберігатиме CSV в тому ж кодуванні.
Структуровані дані XML.
Текстовий файл може містити структури, складніші за просту таблицю. Для цього використовується розмічування відкривними і закривними символами чи послідовностями символів, подібне до використання дужок в записі математичних прикладів. Вкладання таких елементів може кодувати ієрархічні структури даних. Вихідний код багатьох мов програмування організований саме так, але щодо використовуваних з цією метою символів та деталей синтаксису існує багато варіантів. Зокрема, в якості обмежувачів можуть використовуватися звичайні (), фігурні {}, прямокутні [] дужки тощо.
XML.
Екстремальний приклад дужок дає родина мов розмічування SGML/XML, найпоширенішим прикладом якої є мова веб-сторінок HTML. В цих мовах дужки називаються тегами, які разом з охоплюваним ними вмістом становлять елементи. Відкривний тег може містити атрибути – пари «ім’я-значення». Теги виглядають як <ім'я-елемента ім'я-атрибута="значення"> Вміст, що може містити інші елементи. Весь документ мовами цієї родини являє собою кореневий елемент, що містить всі інші елементи – тобто, є деревом.
Описова потужність XML дуже велика, і ті самі дані можна записати у XML багатьма способами. Приклад з черешнями може виглядати так:
<?xml version="1.0" encoding="UTF-8" ?>
<mrkt>
<cherries seller="Пані в 1 ряду" price="35" score="4"/>
<cherries seller="Пан в кашкеті" price="35" score="3"/>
<cherries seller="Пан з акцентом" price="40" score="5"/>
<cherries seller="Бабуся при виході" price="30" score="3"/>
</mrkt>
а може і так,
<?xml version="1.0" encoding="UTF-8" ?>
<cherries>
<seller>
<id>Пані в 1 ряду</id>
<price>35</price>
<score>4</score>
</seller>
<seller>
<id>Пан в кашкеті</id>
<price>35</price>
<score>3</score>
</seller>
<seller>
<id>Пан з акцентом</id>
<price>5</price>
<score>40</score>
</seller>
<seller>
<id>Бабуся при виході</id>
<price>30</price>
<score>3</score>
</seller>
</cherries>
і ще в багато різноманітних способів.
Деталі того, як саме організовано дерево даних, і де – в атрибутах чи у вмісті дочірніх елементах – містяться значення, залежать від моделі явища, способів використання файла даних, смаку розробника формату кодування тощо.
Строго форматовані XML файли (прикладів вище це стосується) можна імпортувати до електронних таблиць. Але це стосується не будь-яких формально правильних XML файлів, тож до такого імпорту треба ставитися уважно і контролювати, чи всі потрібні дані потрапили до таблиці. Наприклад, якщо у нас частина даних у атрибутах, а частина – у вмісті елементів, проблем не уникнути.
Дані у HTML.
Важливо пам’ятати, що мова веб-сторінок HTML, принаймні в одному з двох своїх синтаксисів, є різновидом XML (а в другому дуже до нього близька). Наприклад, наш приклад про черешні у HTML таблиці виглядатиме так:
<table> <tr> <th>Продавець</th> <th>Ціна</th> <th>Якість (бал)</th> </tr> <tr> <td>Пані в 1 ряді</td> <td>35</td> <td>4</td> </tr> <tr> <td>Пан в кашкеті</td> <td>35</td> <td>3</td> </tr> <tr> <td>Пан з акцентом</td> <td>40</td> <td>5</td> </tr> <tr> <td>Бабуся при виході</td> <td>30</td> <td>3</td> </tr> </table> |
|
|
---|---|---|
|
|
|
Складно не помітити, що XML громіздкий і важкочитаний формат. Аналогічні структури даних можна записати і лаконічніше, і (людино) читабельніше, використовуючи простіший синтаксис.
YAML і формат JSON.
Мова YAML (рекурсивний акронім YAML Ain’t Markup Language – «YAML не є мовою розмітки») призначена для запису структурованих даних, однаково придатних для сприйняття людиною і зчитування машиною. Її створено з урахуванням сумних аспектів досвіду впровадження мов родини XML як мову саме збереження даних, а не розмічування тексту.
Наприклад, на згаданий приклад нею може виглядати так (роздільниками виступають рядки, ієрархію задано відступами):
черешні:
- продавець: "Пані в 1 ряді"
ціна: 35
якість: 4
- продавець: "Пан в кашкеті"
ціна: 35
якість: 3
- продавець: "Пан з акцентом"
ціна: 40
якість: 5
- продавець: "Бабуся при виході"
ціна: 30
якість: 3
...
або так (роздільниками виступають дужки, прямокутні для списків, фігурні для списків пар «параметр-значення»):
---
черешні: [{продавець: "Пані в 1 ряді", ціна: 35, якість: 4}, {продавець:
"Пан в кашкеті", ціна: 35, якість: 3}, {продавець: "Пан з акцентом",
ціна: 40, якість: 5}, {продавець: "Бабуся при виході", ціна: 30, якість: 3}].
YAML має багато цікавих можливостей, але більш поширеним засобом запису даних стала його синтаксична підмножина, що одночасно є синтаксичною підмножиною JavaScript, JSON. Саме так, JSON можна прочитати як парсером YAML, так і парсером JavaScript. Для перетворення другого прикладу YAML на JSON досить охопити його фігурними дужками і взяти кожен текстовий елемент в лапки. JSON не чутливий до відступів, тому після форматування для читабельності й краси ми отримаємо це:
{
"черешні": [
{
"продавець": "Пані в 1 ряді",
"ціна": "35",
"якість": "4"
},
{
"продавець": "Пан в кашкеті",
"ціна": "35",
"якість": "3"
},
{
"продавець": "Пан з акцентом",
"ціна": "40",
"якість": "5"
},
{
"продавець": "Бабуся при виході",
"ціна": "30",
"якість": "3"
}
]
}
Форматування і валідування.
Машиночитані формати даних дуже чутливі до синтаксичних помилок. Тому для перевірки форматування використовуються спеціальні інструменти – валідатори.
Валідатори JSON
jsonformatter.curiousconcept.com – валідатор і форматтер.
Валідатори YAML
codebeautify.org/yaml-validator – валідатор;
yaml-online-parser.appspot.com – валідатор і конвертер у JSON та Python;
codebeautify.org/yaml-to-json-xml-csv – валідатор і конвертер у JSON, XML та CSV.
Якщо не бути програмувальником чи не співпрацювати з програмувальником, дані в структурованих форматах – XML, JSON, YAML – для аналізу за допомогою електронної таблиці перетворюють на CSV й імпортують.
Для конвертування можна використати, наприклад, онлайн-інструмент http://www.convertcsv.com/json-to-csv.htm, що дозволяє конвертувати із табличного формату (CSV) у структуровані формати (XML, JSON, YAML, GeoJSON, KML, SQL) і навпаки, транспонувати табличні дані (міняти місцями рядки і колонки) та інше. Також для перетворення форматів можна використати програму Open Refine.