что такое структурированный файл
Что такое структурированный файл
В этом разделе обсуждается использование функций READPRN, WRITEPRN и APPENDPRN для работы со структурированными файлами. Структурированный файл данных — файл с фиксированным числом значений на строке. Например, если экспортировать прямоугольную область из электронной таблицы в текстовый файл, возникающие в результате строки и столбцы чисел сформируют структурированный файл.
Считывание матрицы с помощью функции READPRN
Предположим, что имеется ASCII-файл, содержащий данные, показанные ниже. Эти данные могут быть взяты из электронной таблицы или из любого другого источника.
Рисунок 4 показывает документ Mathcad, который считывает эти данные в матрицу.
Функция READPRN читает весь файл данных, определяет число строк и столбцов, и создает матрицу из этих данных.
Предупреждение: Каждая строка в файле данных должна содержать одинаковое число значений. Если оставить промежутки там, где Mathcad ожидает значение, функция READPRN не сможет прочитать файл. Mathcad определяет конец одного и начало следующего значения, ища пробелы или запятые.
Иногда каждый столбец значений в файле данных представляет отдельную переменную. Рисунок 5 показывает, как использовать верхние индексы, чтобы создать вектор из каждого столбца в файле данных.
Рисунок 4: Считывание таблицы данных в матрицу.
Рисунок 5: Присваивание различным переменным значений из разных столбцов в файле данных.
Рисунок 6: Запись данных в структурированный файл данных.
Запись данных при помощи функций WRITEPRN и APPENDPRN
Рисунок 6 показывает, как использовать функцию WRITEPRN, чтобы записать данные в структурированный файл данных.
Когда Mathcad обрабатывает документ из Рисунка 6, создается файл данных, содержащий следующие значения:
В отличие от WRITE функция WRITEPRN записывает данные в виде столбцов. Обратите внимание, что, поскольку для PRNPRECISION установлено значение четыре, числа записаны с четырьмя знаками после запятой. Поскольку значение PRNCOLWIDTH равно восьми, каждый столбец имеет ширину в восемь символов. Так как PRNPRECISION и PRNCOLWIDTH могут изменяться независимо, нужно не упустить из виду, что ширина столбца должна быть такой, чтобы разместились все необходимые цифры вместе с пробелом, разделяющим отдельные значения.
Рисунок 7: Документ, который создаёт файл данных со столбцами шириной в 10 символов, содержащий числа с 5 значащими цифрами.
Используя функцию augment, можно объединять отдельные переменные в массивы, и записывать их все в файл данных. Рисунок 8 показывает, как это делать.
Рисунок 8: Запись нескольких векторов, объединённых вместе.
Преимущества использования READPRN и WRITEPRN
Использование READPRN, как правило, предпочтительнее использования READ. Когда данные структурированы в столбцы, READPRN переводит данные в Mathcad в легкодоступной форме.
Если некоторые строки в файле данных имеют большее количество значений, чем другие, данные могут быть потеряны. Используйте текстовый редактор, чтобы заменить пропущенные значения на нули перед использованием READPRN.
Функция READ используется для файлов, в которых значения одной переменной разбросаны по нескольким строкам. Таковы файлы, созданные WRITE, которая располагает столько чисел на строке, сколько строка может вместить.
Помните: используйте нижний индекс, являющийся дискретным аргументом, чтобы читать с помощью READ; не используйте нижний индекс, чтобы читать с помощью READPRN.
Обычно WRITEPRN производит более читаемые файлы, чем WRITE, поскольку данные в них аккуратно расположены в строках и столбцах. С другой стороны, WRITE производит меньшие файлы, чем WRITEPRN, потому что ей не нужно добавлять пробелы для выравнивания данных.
Используйте WRITE вместо WRITEPRN, когда требуется напихать так много значений, сколько возможно, в малый файл данных.
Исправляем ошибки: Нашли опечатку? Выделите ее мышкой и нажмите Ctrl+Enter
Работа с файлами
10.1.2. Двоичные файлы
Создание двоичных файлов с помощью функции fopen отличается от создания текстовых файлов только указанием режима обмена – «rb» (двоичный для чтения), «rb+» (двоичный для чтения и записи), «wb» (двоичный для записи), «wb+» (двоичный для записи и чтения):
Обычно для обмена с двоичными файлами используются функции fread и fwrite :
Считывание данных из двоичного файла осуществляется с помощью функции fread с таким же набором параметров:
Двоичные файлы допускают не только последовательный обмен данными. Так как размеры порций данных и их количество, участвующее в очередном обмене, диктуются программистом, а не смыслом информации, хранящейся в файле, то имеется возможность пропустить часть данных или вернуться повторно к ранее обработанной информации. Контроль за текущей позицией доступных данных в файле осуществляет система с помощью указателя, находящегося в блоке управления файлом. С помощью функции fseek программист имеет возможность переместить этот указатель:
Пример 2. Рассмотрим программу, которая создает двоичный файл для записи с именем c_bin и записывает в него 4*10 порций данных в машинном формате (строки, целые и вещественные числа). После записи данных файл закрывается и вновь открывается для чтения. Для демонстрации прямого доступа к данным информация из файла считывается в обратном порядке – с конца. Контроль записываемой и считываемой информации обеспечивается дублированием данных на экране дисплея.
Использованные в этом примере операторы:
могут быть заменены обращением к единственной функции freopen, которая повторно открывает ранее открытый файл:
Основное правило, которого надо придерживаться при обмене с двоичными файлами звучит примерно так – как данные записывались в файл, так они должны и читаться.
10.1.3. Структурированные файлы
Инициализация структурированного файла выполняется точно таким же способом, как и подготовка к работе двоичного файла.
Результат работы этой программы ничем не отличается от предыдущего примера.
Правильная организация файлов или наше спасение в наших руках
Я не открою Америку, если скажу, что способ организации файлов в современных ФС мягко говоря не совсем удобен для конечного пользователя. И действительно: иерархическая модель представления данных на основе файлов и каталогов, не менявшаяся уже несколько десятков лет, просто не способна соответствовать современным потребностям в хранении большого количества разнородного контента. И если с музыкальной информацией все более-менее хорошо, благодаря таким медиа-библиотекам, как iTunes или Amarok, то с файлами остальных форматов ситуация до сих пор остается очень печальной.
Суть проблемы
Я уверен, на компьютере каждого человека, читающего этот топик, наверняка есть хоть один из следующих каталогов: soft, разобрать, временно, всякая всячина, trash, интересное. Обычно в папке софт находится несколько тысяч архивов и экзешников с говорящими названиями «setup.exe» или «589346.zip»; папка «Мои документы» засрана кучей файлов, многие из которых вообще к документам не относятся, а файлы из каталога «Разобрать» так и остаются не разобранными…
При этом, когда у нас возникает потребность отыскать «тот самый дистрибутив visual studio, который я скачивал пару месяцев назад», то гораздо проще за несколько секунд найти ссылку на установщик в гугле, чем долго и тщетно пытаться искать его на своем компьютере. Стандартные утилиты поиска так же не спасают, т.к. для бинарных файлов они могут ориентироваться только на название файла, да жалкую горстку дополнительных атрибутов.
Хочу заметить, что данная проблема в юзабилити файловых систем вовсе не является надуманной: достаточно вглянуть на этот топик, вызвавший достаточно бурное обсуждение.
Также можно ознакомиться с соответствующей главой из книги «Алан Купер об интерфейсе. Основы проектирования взаимодействия».
Варианты решения
Что же с этим делать? К счастью, благодаря вебу, все мы хорошо знакомы с простым, но очень эффективным способом организации информации. Да да, я говорю о тегах.
Delicous.com, digg.com, last.fm, да взять хоть хабрахабр — все эти веб-сервисы научили нас грамотно пользоваться метками. Потратив один раз чуть чуть своего времени на тегирование любого элемента своей коллекции, как мы уже никогда не потеряем его из виду. Такие вещи, как «смежные теги» или «облако тегов» позволят найти нам нужный контент, даже если мы не очень хорошо помним, какими тегами его отметили.
Хорошо, но если такую простую и удобную идею до сих пор не внедрили производители операционных систем, то куда же смотрят разработчики сторонних приложений?!
Я полагал, что существует как минимум несколько альтернатив, позволяющих создавать базу данных, на основе тегирования файлов, ведь это так просто для реализации!
К моему разочарованию я обнаружил, что подсуетились лишь программисты под Mac OS: 7 File Tagging Applications for OS X (разумеется, почти все они платные).
Ни для windows, и, тем более, ни для Linux ничего подобного я не нашел. Хотя, возможно, я просто плохо искал — в таком случае очень прошу указать в комментариях ссылки на такой софт.
Существующие средства
/.nautilus/extensions/python и дать ему права на исполнение. На практике, в моей Ubuntu 8.10 этот скрипт вызывает крэш приложения, при вызове меню. Говорят, что в ранних версиях убунты все работает нормально.
Также нельзя не упомянуть замечательный проект dhtfs.
DHTFS также проповедует идеологию ФС, основанной на тегах, написан на python и имеет даже краткую пользовательскую документацию! Но есть один минус — это cli-приложение.
СОДЕРЖАНИЕ
Обзор
Структурированные документы обычно ориентированы на маркировку вещей, которые могут использоваться для различных целей обработки, а не просто для форматирования. Например, явное обозначение «названия главы» или «выделения» гораздо более полезно для систем для слабовидящих, чем просто «Helvetica bold 24» или «курсив». Точно так же значимая маркировка многих элементов на листе технической информации обеспечивает лучшую интеграцию с базами данных, поисковыми системами, онлайн-каталогами и т. Д.
Структурированные документы обычно поддерживают по крайней мере иерархические структуры, например списки, а не просто элементы списка; разделы, а не только заголовки разделов; и так далее. Это резко контрастирует с системами, ориентированными на форматирование. Высокопроизводительные системы также поддерживают несколько независимых и / или перекрывающихся наборов компонентов.
Структурная семантика
При написании структурированных документов основное внимание уделяется кодированию логической структуры документа, при этом меньше или даже не делается явной работы, посвященной его представлению людям с помощью печатных страниц или экранов (в некоторых случаях такое использование даже не ожидается). Структурированные документы могут быть легко обработаны компьютерными системами для извлечения и представления производных форм документа. Например, в большинстве статей Википедии оглавление автоматически создается из различных тегов заголовков в теле документа. Поскольку преобразование Оксфордского словаря английского языка в SGML явно различало множество различных значений, которые придают использованию курсива в печатной версии, инструменты поиска могут извлекать записи на основе этимологии, цитат и многих других интересных особенностей. Когда HTML предоставляет структурную, а не просто форматирующую информацию, слабовидящим пользователям может быть легко предоставлен более удобный интерфейс для чтения. Когда туристические компании предоставляют маршруты в виде структурированных документов, а не просто отображения, пользовательские инструменты могут легко извлечь необходимые факты и передать их в календарь или другие приложения.
, и абзац;
Одна из наиболее привлекательных особенностей структурированных документов заключается в том, что их можно повторно использовать во многих контекстах и по-разному представлять на мобильных телефонах, экранах телевизоров, синтезаторах речи и любом другом устройстве, которое можно запрограммировать для их обработки.
Другая семантика
Тексту может быть придано другое значение, которое не является «структурным» в том же смысле, что и более крупные объекты, но все же считается «структурой документа», потому что оно выражает утверждения относительно объема и природы или онтологии частей документа, а не инструкции по его оформлению. В приведенном выше фрагменте HTML этот элемент означает, что заключенный текст является выразительным. В визуальном плане это обычно выделяется жирным шрифтом, например : но речевой интерфейс, скорее всего, будет использовать голосовую интонацию. Термин семантическая разметка исключает разметку, которая напрямую не выражает никакого значения, кроме инструкции для визуального отображения (хотя интеллектуальный агент может быть в состоянии различить структурное значение, скрывающееся за тегом). Тег «strong» является «описательным» или «структурным» в том смысле, что он предназначен для обозначения абстрактного, квазилингвистического свойства его содержания, а не для описания соответствующего представления на каком-то конкретном носителе.
Контекст и намерение
В принципе, то, что составляет «структуру» или «неструктуру», может варьироваться. В книге, посвященной типографике, пометка «курсивом» или «полужирным шрифтом» вполне может быть ключевым моментом. Например, при обсуждении того, когда использовать определенные стили, вероятно, потребуется привести примеры и контрпримеры, которые больше не будут иметь смысла, если рендеринг не синхронизирован с прозой. Точно так же конкретное издание документа может представлять интерес не только своим содержанием, но и типографской практикой, и в этом случае описание этой практики не только желательно, но и необходимо. Однако эта проблема характерна не только для структуры документа; он также возникает в грамматике при обсуждении грамматики и во многих других случаях.
Метаинформация, возможности файловых систем и децентрализованные сети будущего
Дополнительные возможности
Жесткие и символьные ссылки
Начнем с жестких и символьных ссылок, известных пользователям Linux. На самом деле они есть и в Windows (NTFS), но практически нет инструментов для работы с ними.
Расширенные атрибуты и файловые потоки
Метаинформация
Теперь перейдем к собственно метаинформации как таковой.
В широком смысле, все файлы по способу их использования делятся на следующие категории
текст (включая гипертекст)
программы (то, что компьютер способен выполнить)
прочие двоичные данные (трехмерные модели, базы данных любого вида, геоданные, телеметрия, биомедицинские данные и т.д.)
контейнеры общего вида (архивы, образы, сложные документы, содержащие все перечисленные типы)
Отдельно следует отметить деление метаинформации на машинную, общую и пользовательскую.
Неотъемлемые машинноориентированные свойства файла: размер, ширина и высота изображения, количество цветов, количество страниц в документе, длительность аудио или видео, кодек и т.п. Изменение этих параметров возможно только с глубоким изменением самого контента (таким как перекодирование в другой формат или редактирование)
Общие человекоориентированные свойства. Это например название, имя автора, издательство, год издания, аннотация, картинка-превью. Эти свойства хотя и можно изменить без изменения самого контента, но никакого смысла в этом нет (кроме, возможно, исправления опечаток).
Локальные пользовательские свойства: сюда можно отнести личный рейтинг, комментарии и теги, выставляемые конкретным пользователем файла. Предполагается, что пользователи могут свободно менять эти свойства для личных целей.
Поддержка подобной классификации на уровне ФС была бы чрезвычайно полезной для самых разных целей.
Примеры метаинформации
Примеры тегов, встроенных в различные форматы
Vorbis Comments (audio)
Метаинформация в файле данных: медиаконтент
В качестве примера можно привести структуру IDv1 формата mp3;
Номер трека в альбоме или 0
Жанр (индекс, строка)
Скорость (стиль, тип) музыки (чем больше число, тем «активней» музыка)
Метаинформация в базе данных: Libgen
MD5 ключ (хеш электронной книги)
Название периодического издания (с номером и годом)
Число страниц, указанное в книге
Фактическое число страниц в файле
Код тематического классификатора
Первоисточник файла (название интернет-библиотеки или коллекции)
Выпуск в рамках первоисточника
Dewey Decimal Classification
Идентификатор библиотеки Конгресса
Идентификатор цифрового объекта DOI
Идентификатор в GoogleBooks
DPI, число точек на дюйм с скане
Произведена разрезка отсканированного разворота на страницы
Имеется электронное оглавление
Книга с OCR (текстовым) слоем
Размер файла в байтах
Версия книги более высокого качества (MD5 ключ)
Видимость при поиске через сайт
Первоначальное имя файла с локальным путем (при добавлении из существующей коллекции)
Книга присутствует в локальном хранилище пользователя
Время добавления записи
Время последней модификации записи Обложка (имя файла-картинки)
Отдельные файлы метаинформации: торренты
Торрент формата v1 состоит из элементов
announce-list — список трекеров, если их несколько
creation date — дата создания
comment — текстовый комментарий к торренту
В версии 1 хеши (SHA1) соответсвуют не файлам, а «фрагментам», все файлы торрента «склеиваются» в один битовый поток (отсюда и название), который разбивается на фрагменты одинакового размера. Для каждого фрагмента считается SHA1, и эти хеши сохраняются в torrent файле. В версии 2 этот недостаток исправили, и стало возможным сохранять хеши уже для каждого файла, что позволяет искать в DHT конкретные файлы, а не торренты в целом; использовать одинаковые файлы из разных торрентов и т.д.
Бинарные хеши
Возможно, в будущем Сообщество придет к некоему консенсусу относительно единого хеша. Пока же их много. Например, в базе Libgen хранятся следующие хеши:
Advanced Intelligent Corruption Handler
SHA1 (используется в сетях Gnutella, Gnutella2, а также для создания торрент магнет-ссылки)
Tiger Tree Hash (используется в сетях Direct Connect и Gnutella)
Торрент файл, закодированный в base64
BitTorrent Info Hash (используется в сетях BitTorrent v1)
IPFS Content ID (идентификатор в сети IPFS)
Перцептивные хеши
Актуальность хешей
Теговые файловые системы
Общая идея
Каждый файл в такой системе будет ассоциироваться с одним или несколькими тегами. Чтобы найти то или иное множество файлов, нужно ввести или выбрать в файловом менеждере нужные теги (возможно, объединив их логическим выражением: И, ИЛИ, НЕ и т.д.)
Представьте, что у вас есть огромная коллекция фотографий, сделанных в разных странах, в разных местах (город, деревня, пляж, парк, музей. ), в разное время суток (рассвет, день, закат, ночь), с разными сюжетами (селфи, родственники, коллеги, природа, достопримечательности. ), в разные годы, и т.п. Теперь представьте, что вы хотите получить список фотографий, которые сделаны утром в центре Нью-Йорка, кроме тех, которые были сделаны до 2020 года.
Общая идея теговой ФС в том, что у файла есть облако тегов, которое может состоять из любого числа тегов, в том числе вложенных. Набирая или выбирая в некотором интерфейсе теги, вы получаете список файлов, удовлетворяющий этим тегам.
Как видно, теговая ФС гораздо ближе к реляционной БД, чем иерархическая. Неудивительно, что идеи реализации теговых ФС тесно переплетаются с идеями интеграции ФС и БД.
Краткий обзор реализаций
Папки или теги?
Иногда классическую иерархическую организацию противопоставляют теговой. Я считаю, что противопоставление этих двух систем не нужно. Иерархия и теги прекрасно дополняют друг друга. Файловая иерархия удобна именно тем, что она однозначна и выделяет главное. В 99% случаев главное можно определить. Для 1% нестандартных случаев остаются хардлинки и симлинки. Теги удобны для поиска. Когда мы набираем запрос в Гугле, мы по сути вводим именно теги. Разумеется, можно организовать и полнотекстовый поиск на компьютере, и наверное это было бы неплохо
Файл должен иметь уникальное имя в рамках своей папки, но несколько файлов в папке вполне могут иметь одинаковые теги и даже полностью совпадающий набор тегов. Папка это тоже в некотором роде тег. Можно рассматривать имя папки как «главный» тег, определяющий место файла в иерархической системе.
Собираем все вместе
Унифицированное хранение всех видов метаданных в расширенных атрибутах
Полноценная поддержка расширенных атрибутов файловыми менеджерами
СУБД, интегрированная в файловую систему, для индексации метаданных
Унифицированный формат файла представления метаданных
Хранение метаинформации в расширенных атрибутах
Итак, у нас есть расширенные атрибуты, и есть множество метаинформации о файлах. Во всех решениях метаинформация хранится или в имени, или в отдельной БД. А что если хранить метаинформацию в расширенных атрибутах? Преимущества:
Унификация доступа: информация привязана к файлу на уровне файловой системы, а не на уровне конкретной программы. Другие программы могут не иметь понятия о формате файла, но при этом корректно работать с его метаинформацией. Ровно это происходит с существующим минимумом метаинформации в современных ОС: размер и время создания файла никак не зависят от формата.
Возможность добавления метаинформации, не предусмотренной форматом файла.
Что для этого нужно? Поддержка атрибутов со стороны операционных систем (уже есть) и файловых менеджеров. Удобные средства занесения и редактирования атрибутов. Удобные средства поиска.
Хранение метаинформации в специальных файлах («метафайлах»)
Это новая абстракция: специальный файл, содержащий метаинформацию о другом файле или каталоге («метафайл»). Это одновременно и торрент, и библиотечная карточка, и обложка альбома или диска. Там есть все что нужно: и различные хеши файла, и картинка-превью, и оглавление, и краткая аннотация, и список тегов/ключевых слов, и информация об авторах/издателях, и дата создания, и ссылка на источник в интернете, откуда файл был скачан.
Это готовый объект для публикации в файлообменных сетях любого вида; теперь не нужно заполнять унылые формы на торрент-трекере, вся информация
Он получается простым кликом по файлу и выбором пункта в контекстном меню любого файлового менеджера
Такой файл, в отличие от торрента, содержит человекоориентированную информацию, и потому понятен: его всегда можно открыть и посмотреть, на что же он ссылается; его можно загуглить, просто выбрав соответствующую команду в контекстном меню файла.