Возникла необходимость разработать формат некоторого файла данных, являющегося результатом работы программы. Конечно, это не так уж и сложно, просто я задумался над тем, что наверняка существуют какие-то общие правила или принципы разработки новых форматов файлов. Если кто-нибудь с этим сталкивался, расскажите, пожалуйста, в двух словах или дайте ссылку на статью, в которой такой вопрос рассматривается (на РСДН'е я ничего такого не нашел).
Здравствуйте, Аноним, Вы писали:
А>Возникла необходимость разработать формат некоторого файла данных, являющегося результатом работы программы.
ИМХО если требуется наглядность (проще говоря возможность просмотреть результаты), то лучше использовать какой-нибудь существующий формат, который можно просмотреть различными программами. А если удобство работы со структурой, т.е. если результат — какая-либо структура, тогда запихивать в класс и серилизировать. Но в этом случае придется писать что-то типа просмотрщика для данного формата.
Re[2]: Разработка формата файла
От:
Аноним
Дата:
02.01.04 12:10
Оценка:
Здравствуйте, Flea, Вы писали:
F>Здравствуйте, Аноним, Вы писали:
А>>Возникла необходимость разработать формат некоторого файла данных, являющегося результатом работы программы. F>ИМХО если требуется наглядность (проще говоря возможность просмотреть результаты), то лучше использовать какой-нибудь существующий формат, который можно просмотреть различными программами. А если удобство работы со структурой, т.е. если результат — какая-либо структура, тогда запихивать в класс и серилизировать. Но в этом случае придется писать что-то типа просмотрщика для данного формата.
Заданный мной вопрос скорее теоретический, чем практический. То есть я в принципе представляю, как решить эту задачу (тем более, что делал это и раньше). Просто сейчас что-то стукнуло в голову, и мне захотелось узнать, как это делается по науке — как правильно работать с версией файла, заголовком и пр. Причем вопрос касается именно создания собственного формата файла (если конкретно, то для хранения триангуляции, построенной на заданном множестве точек).
Здравствуйте, Аноним, Вы писали:
А>Возникла необходимость разработать формат некоторого файла данных, являющегося результатом работы программы. Конечно, это не так уж и сложно, просто я задумался над тем, что наверняка существуют какие-то общие правила или принципы разработки новых форматов файлов. Если кто-нибудь с этим сталкивался, расскажите, пожалуйста, в двух словах или дайте ссылку на статью, в которой такой вопрос рассматривается (на РСДН'е я ничего такого не нашел).
Позволю себе несколько мыслей вслух
Итак, свой формат файла:
1. Должен соответствовать поставленной задаче. Т.е. в случае, когда главным вопросом является быстродействие — должен обеспечивать быстрый доступ к данным внутри себя. И т.п.
2. Должен обеспечивать уникальную идентификацию. Т.е. содержать в себе некие квантификаторы, идентифицирующие не только данный формат файла, но и версию ПО, с помощью которого был этот файл создан. Наличие такого квантификатора позволяет абстрагироваться от способа представления/хранения имени файла в различных ОС (например, в Windows строковые имена C:\sample.txt и C:\Sample.txt идентифицируют один и тот-же файл, в *nix — разные). Идентификацию лишь по расширению (*.txt, *.xls и пр.) считаю порочной, т.к. нет тикаких гарантий, что в дальнейшем это расширение не использует M$ в своих целях
3. Должен обеспечивать доступ к информации версии и времени. Как частично писалось в пункте 2 — должен предоставлять наружу версию ПО, с помощью которого сделан и (опционально) дату создания.
4. Должен быть форматом с четко развитой структурой хранения данных. Это без комментариев
5. Как следствие пункта 4 — структурность хранимых данных обязывает вводить однозначную идентификацию типа структуры, хранимой в файле. Это позволит в дальнейшем расширить формат файла, буде такая надобность возникнет.
6. Может содержать избыточные данные для использования алгоритмом коррекции ошибок. Это тоже оставлю без комментариев.
7. Должен быть гибким. Например, таким, чтобы даже в случае повреждения 50% информации, хранимой в файле, остальные 50% читались и обрабатывались.
Формат должен определять заголовок файла.
Заголовок должен демострировать 2 вещи.
1) То что файл именно нужного формата.
2) То что файл не повреждён.
Пример хорошего заголовка
"\x40\x80\xBF\xFF\n\r\n\0"
Во-первых он достаточно длинный, что бы не совпасть случайно с заголовком другого формата файлов.
Во-вторых если на платформе записывающей и читающей файл разный порядок байт в слове это сразу станет заметно.
В-третьих если файл был обработан как текстовый и в результате были тотально заменены символы переноса строки, или срезаны 8е биты, то это также станет заметно. Формат должен быть расширяемый.
То есть формат не должен зависеть от данных. Любая структура должна иметь явно определённый размер. Более того, считается хорошим тоном если в структурах есть идентификаторы типа содержащихся в них данных
если их можно менять независимо друг от друга
если их порядок не имеет значения
если содержание структуры не зависит от её положения в файле.
То есть например. Имеем структуру Человек у неё есть вложенные структуры Имя, Фамилия, Отчество. Если старая версия программы не поддерживает свойства Отчество она должна изменить Имя и Фамилию, а Отчество просто переписать побайтово как есть, не имея ни малейшего понятия что внутри. Более новая версия программы прочтёт этот файл корректно. Формат должен поддерживать сжатие
Причём опционально. Желательно что б алгоритмы были легко реаизуемые, как LZ***. Формат должен поддерживать восстановление.
Именно поэтому структуры в файле (вообщето их тегами обычно называют) должны бють независимыми, с идентификаторами, а в заголовке должно быть минимум информации. Если данные графические то желательно иметь в файле миникартинку (32х32 — 128х128) для предпросмотра.
Здравствуйте, Аноним, Вы писали:
А>Возникла необходимость разработать формат некоторого файла данных, являющегося результатом работы программы. Конечно, это не так уж и сложно, просто я задумался над тем, что наверняка существуют какие-то общие правила или принципы разработки новых форматов файлов. Если кто-нибудь с этим сталкивался, расскажите, пожалуйста, в двух словах или дайте ссылку на статью, в которой такой вопрос рассматривается (на РСДН'е я ничего такого не нашел).
--
Может быть, для Вашей задачи подходят файлы в формате XML?
C уважением,
Геннадий Майко.
Re: Разработка формата файла
От:
Аноним
Дата:
04.01.04 13:19
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Возникла необходимость разработать формат некоторого файла данных, являющегося результатом работы программы.
<...>
Нужно делать как удобнее, но вот версия в начале должна быть. Никогда не забуду, как я однажды приплясывал, достигая совместимости с таким, "безверсионным" форматом.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Flea, Вы писали:
... А>Заданный мной вопрос скорее теоретический, чем практический. То есть я в принципе представляю, как решить эту задачу (тем более, что делал это и раньше). Просто сейчас что-то стукнуло в голову, и мне захотелось узнать, как это делается по науке — как правильно работать с версией файла, заголовком и пр. Причем вопрос касается именно создания собственного формата файла (если конкретно, то для хранения триангуляции, построенной на заданном множестве точек).
Обязательно нужно изобретать велосипед -- собственный формат, собственное API для парсинга таких файлов ... может подойдет XML, или CSV -- если данные без сложных связей? Кроме этого -- есть шанс, что ечто подобное уже изобретено и формат в т.ч. -- поищи в Инете ...
> Причем вопрос касается именно создания собственного формата файла (если > конкретно, то для хранения триангуляции, построенной на заданном > множестве точек).
Наверняка тахеометры и их программки уже умеют сохранять триангуляцию в
какой-то более-менее известный формат.
Электронный тахеометр объединяет в себе возможности электронного теодолита и
дальномера, снабжен устройством хранения и обработки данных и встроенным
программным обеспечением для решения различных прикладных задач.
Поскольку триангуляция применяется чаще всего в геодезии, то я предположил,
что соотв. коммерческие программки могут быть более полезны, чем создание
собственной.
Например, MapInfo: http://www.mapinfo.com/ http://www.esti-map.ru/mapinfo.htm
Posted via RSDN NNTP Server 1.8 beta
IMHO. смайлики добавить по вкусу.
Re[2]: Разработка формата файла
От:
Аноним
Дата:
19.01.04 15:08
Оценка:
Здравствуйте, adontz.
Браво!!! Можно посоветовать вопрошающему конкретный пример: формат ELF, COFF, и подобные.
Здравствуйте, Аноним, Вы писали:
А>Браво!!! Можно посоветовать вопрошающему конкретный пример: формат ELF, COFF, и подобные.
TIFF (без JPEG расширений, которыми его обосрали) позволяет редактировать теги независимо
PNG имеет хороший заголовок
RIFF имеет хорошую внутреннею структуризацию
Вообще рекомендую сходить к O'Relly and Associates GFF и поглядеть на чушие ошибки
