Формат файла.

← →
guav © (2006-10-03 18:31) [0]

Требуется изобрести формат файла.
в файл должна войти большая BMP картинка и немного других данных (в основном, массивы координат из пар Double).

Самый ленивый способ - хранить другие данные в формате dfm, картинку писать перед или после этого dfm или как ещё одно свойство этого dfm. Но мне это решение не очень нравится, т.к. оно привязано к VCL.
Данные можно записать в текстовой форме (XML) или бинарной. Вопрос также какой лучше взять общий "контейнер" для двух сущностей "картинка" или "другие данные". Просто писать подряд ? Zip ? Файл ресурсов ?

В общем, вопрос, если бы вам потом пришлось работать с моими данными с каким бы форматом вы бы были менее огорчены столкнуться ?

← →
MeF Dei Corvi © (2006-10-03 18:34) [1]

Не вижу проблемы. Требуется изобрести - сделай. Судя по тому, что там будет картинка, формат будет бинарный.

← →
TUser © (2006-10-03 18:34) [2]

У тебя нет ограничений - выбирай любой способ, лишь бы работало. Имхо.

← →
Kolan © (2006-10-03 18:36) [3]

Может *.doc?

← →
Gero © (2006-10-03 18:41) [4]

Просто записать подряд в бинарный файл. Зачем еще xml приплетать?

← →
guav © (2006-10-03 18:41) [5]

> У тебя нет ограничений - выбирай любой способ, лишь бы работало.
> Имхо.

Я понимаю.
Но вот такой формат предыдущей проги.

// формат файла старой программы выявлен опытным путём. // это - массив записей, по записи на каждую точку, // последняя запись дублируется. Запись слеующего вида: type TObjRecord = packed record PtName: array[0..15] of Char; GeoX, GeoY: Double; Junk: array[0..7] of Byte; end; // , где PtName - подпись, лишние элементы - пробелы. // GeoX, GeoY - координата. // Junk - заполняется иногда "мусором", // иногда нулями, при открытии файла в Pmag1.exe // видимо игнорируется, при сохранении пишет // в элементы 0..3 нули, в 4..7 - что-то очень // похожее на указатель.

Оказался неудобным и заставил долго экспериментировать с ней, чтобы его выяснить.

Не хочу повторять ошибок.

← →
Virgo_Style © (2006-10-03 18:42) [6]

вероятно, в лоб - <допольнительные данные><поток>.
поток - bmp или jpg. Если допустим jpg - то посмотрел бы в сторону тэгов, или как из у jpeg"а зовут - нельзя ли там создать свой собственный служебный массив.

← →
Ученик чародея. (2006-10-03 18:44) [7]

> guav © (03.10.06 18:31)
> Требуется изобрести формат файла.
> в файл должна войти большая BMP картинка и немного других
> данных (в основном, массивы координат из пар Double).
>
> Самый ленивый способ - хранить другие данные в формате dfm,
> картинку писать перед или после этого dfm или как ещё одно
> свойство этого dfm. Но мне это решение не очень нравится,
> т.к. оно привязано к VCL.
> Данные можно записать в текстовой форме (XML) или бинарной.
> Вопрос также какой лучше взять общий "контейнер" для двух
> сущностей "картинка" или "другие данные". Просто писать
> подряд ? Zip ? Файл ресурсов ?

Zip и тематические подкаталоги внутри. Возможно в корне zip xml файл с описанием.

Abbrevia(Delphi компонент) работает с zip.

← →
Gero © (2006-10-03 18:44) [8]

Формат достаточно документировать, и ничего выяснять не надо будет.

← →
MeF Dei Corvi © (2006-10-03 18:44) [9]

> чтобы его выяснить.

Что значит выяснить формат, если он жетко задан тобой же?

← →
Ученик чародея. (2006-10-03 18:44) [10]

В общем так почти все файлы ресурсов игрушек сделаны. расширение файла конечно лучше свое придумать.

← →
Gero © (2006-10-03 18:45) [11]

> [7] Ученик чародея. (03.10.06 18:44)

Зачем такой огород городить?

← →
guav © (2006-10-03 18:45) [12]

> [4] Gero © (03.10.06 18:41)

> Просто записать подряд в бинарный файл. Зачем еще xml приплетать?

Это просто для одной версии, но неудобно если в программе периодически появляются абсолютно новые сущности.

С xml парсером работать несложно, а данных немного, почему бы не приплести ?

← →
MeF Dei Corvi © (2006-10-03 18:47) [13]

> С xml парсером работать несложно

С потоками ввода работать сложнее?

← →
guav © (2006-10-03 18:48) [14]

> Что значит выяснить формат, если он жетко задан тобой же?

Новый - да.
Старый - связан со старыми программами для которых и автор и исходники утеряны, воти пришлось ковырять.

← →
Virgo_Style © (2006-10-03 18:49) [15]

guav © (03.10.06 18:45) [12]
Это просто для одной версии, но неудобно если в программе периодически появляются абсолютно новые сущности.

Если так, то что-то вроде
<Имя блока><размер><содержимое блока> <Имя блока><размер><содержимое блока> <Имя блока><размер><содержимое блока>
imho.

← →
Kolan © (2006-10-03 18:50) [16]

Мое имхо - только популярные форматы, если это возможно.

← →
guav © (2006-10-03 18:50) [17]

> Zip и тематические подкаталоги внутри. Возможно в корне
> zip xml файл с описанием.

Идея эта мне нравится. Без тематических каталогов можно обойтись, т.к. всего две сущности - картинка и другие данные. Но останавливает это:

> Зачем такой огород городить?

← →
ferr © (2006-10-03 18:52) [18]

я бы пользовал xml, и только.

← →
guav © (2006-10-03 18:53) [19]

> [16] Kolan © (03.10.06 18:50)

> Мое имхо - только популярные форматы, если это возможно.

что значит "только популярные форматы" ?
данные - специфичные для программы.
форма представления - об этом и вопрос.

← →
guav © (2006-10-03 18:54) [20]

> я бы пользовал xml, и только.

Нужно хранить ещё и BMP. Или предлагаешь её тоже в xml ?

← →
Gero © (2006-10-03 18:57) [21]

> [20] guav © (03.10.06 18:54)

Конечно можно.

← →
ferr © (2006-10-03 18:58) [22]

> Нужно хранить ещё и BMP.

это уже хуже)
> Или предлагаешь её тоже в xml ?

зависит от размеров BMP.

← →
Kolan © (2006-10-03 18:59) [23]

> "только популярные форматы" ?

Можешь сделать на Xml, который знаешь ты и еще тысячи людей, сделай. А своё изобретать - рыть себе яму в будующем.

Пример: попросили открыть файл вида:

1200 2015 1232 5443 -5433 -4552 2456

Что это за числа? Какие сдесь данные?

Точки в виде:
X
Y

Или:
X
Y
Z

Вот что такое "изобретенный" формат.

← →
guav © (2006-10-03 19:01) [24]

> Конечно можно.

Ну да. Но, опять таки, нужно ли ?
Вот ты предлагаешь ни xml ни dfm а воообще бинарные данные подряд. Этот подход имеет свои преимущества.

Меня интересуют различные мнения. Можете считать это опросом.

← →
guav © (2006-10-03 19:03) [25]

> [23] Kolan © (03.10.06 18:59)

Вот... я тоже с таким столкнулся.. в общем ты меня понял.
Собственно это и побудило создать ветку, а не делать как в данный момент на ум пришло.

← →
Agent13 © (2006-10-03 19:07) [26]

Кстати, по поводу зип-архива - по этому пути пошёл даже Microsoft. Ведь файлы, созданные Microsoft Office 2007 - docx, xlsx, pptx и т.д. представляют собой не что иное как зип-архив, в котором сожержится несколько xml-файлов. Так что есть на кого равняться :)

← →
Джо-со-смарта (2006-10-03 19:07) [27]

Я бы выбрал 2 файла, картинка и данные - отдельно. Данные - в текстовом виде. Собственно, у меня таких "форматов" несколько, используются пару лет. Недостатков не обнаружил :-)

← →
ferr © (2006-10-03 19:09) [28]

> от... я тоже с таким столкнулся.. в общем ты меня понял.

После того как пару раз приходилось незапланированно масштабировать данные, почти все данные теперь у меня хранятся в xml).
> Ведь файлы, созданные Microsoft Office 2007 - docx, xlsx,
> pptx и т.д. представляют собой не что иное как зип-архив,
> в котором сожержится несколько xml-файлов

Мамма мия) Они всегда найдут как сделать тоже самое в разы медленнее...

← →
Oldman © (2006-10-03 19:14) [29]

> Требуется изобрести формат файла.
> в файл должна войти большая BMP картинка и немного других
> данных (в основном, массивы координат из пар Double).

БСК!!! Читай [27]

← →
guav © (2006-10-03 19:14) [30]

> [27] Джо-со-смарта (03.10.06 19:07)

Тоже вариант. Но желательно одним куском. Дело в том что картинка читается из уже созданного BMP файла и никогда не редактируется. Но чтобы не потерять её, лучше запихнуть в файл.

> [26] Agent13 © (03.10.06 19:07)

И картинки, и объекты тоже, получается, в XML пихают ?
Если не трудно, пришли пожалуйста небольшой образец на Format("%s@%s.%s", ["guav", "ukr", "net"])

← →
Джо-со-смарта (2006-10-03 19:17) [31]

Удобно,, например, тем, что картинку можно обрабатывать отдельно, любым другим софтом.

← →
guav © (2006-10-03 19:24) [32]

> > Или предлагаешь её тоже в xml ?
>
> зависит от размеров BMP.

От сотен кил до нескольких мег.

> Удобно,, например, тем, что картинку можно обрабатывать
> отдельно, любым другим софтом.

Картинка уже есть отдельно и с ней ничего делать не надо.

Как бы результаты опроса:

данные:
текст Джо, Oldman
xml Kolan, Ученик чародея, ferr, Agent13
бинарник MeF Dei Corvi, Gero, Virgo_Style
dfm
всё равно TUser

котнейнер:
zip Ученик чародея, Agent13
просто подряд Gero, Virgo_Style
отдельно! Джо, Oldman

← →
Ученик чародея. (2006-10-03 19:26) [33]

> guav © (03.10.06 18:50) [17]
> > Zip и тематические подкаталоги внутри. Возможно в корне
>
> > zip xml файл с описанием.
>
> Идея эта мне нравится. Без тематических каталогов можно
> обойтись, т.к. всего две сущности - картинка и другие данные.
> Но останавливает это:
>
> > Зачем такой огород городить?

Тем что на Delphi это сделать проще, чем нарисовать иконку к своей программе, на иконку уйдет времени больше.

Так сделаны пакеты Jar - java программы.

← →
MeF Dei Corvi © (2006-10-03 19:30) [34]

> бинарник MeF Dei Corvi

Ну вообще я за картинку отдельно, данные отдельно. Так редактировать удобнее (данные в xml). При желании можно и в zip упаковать. В зависимости от задачи.

← →
Ломброзо © (2006-10-03 19:31) [35]

Покурите про медицинский стандарт DICOM - он как раз и разработан для хранения растровых изображений с координатами для выделения и подписывания каких-то областей

← →
ferr © (2006-10-03 19:32) [36]

Всё-таки я против того чтобы в xml толкать картинку. Она всё же слишком большая, будут очень ощутимые тормоза..
Моё мнение такое :
zip
{
image(s);
...
mainXML; // в нём название файла и другая координационная информация(если необходима)
}

← →
guav © (2006-10-03 19:40) [37]

> Тем что на Delphi это сделать проще, чем нарисовать иконку
> к своей программе, на иконку уйдет времени больше.

Иконка уже есть :-)
А расширение всё равно своё будет

Я не про сложность реалиации, а про сложность самой программы.

> [35] Ломброзо © (03.10.06 19:31)

Очень интересно, спасибо, покурю.

← →
Kerk © (2006-10-03 19:40) [38]

Я за zip
Вообще можно было б написать класс - аналог TIniFile, но работающий с zip-хранилищем

> И картинки, и объекты тоже, получается, в XML пихают ?
> Если не трудно, пришли пожалуйста небольшой образец на
> Format("%s@%s.%s", ["guav", "ukr", "net"])

Отослал. Но картинки они в xml не пихают :) Они лежат в нормальном виде в подкаталоге media. Объекты - в embeddings. Так что судя по всему в xml только текст и настройки.

AbiWord имеет свой формат документа, основанный на XML. Так вот картинки он хранит в самом XML в кодировке base64

Может кто-то и предлагал...

> guav © (03.10.06 18:31)

А может использовать структурированные хранилища? (Structured Storage)

← →
Ученик чародея. (2006-10-03 20:37) [42]

> guav © (03.10.06 19:40) [37]
> > Тем что на Delphi это сделать проще, чем нарисовать иконку
>
> > к своей программе, на иконку уйдет времени больше.
>
> Иконка уже есть :-)
> А расширение всё равно своё будет
>
> Я не про сложность реалиации, а про сложность самой программы.

Если сделать через классы с грамотным наследованием, то будет не сложнее чем изменение элемента массива.

PS
В файл формата можно еще пихать description.txt с описанием формата своих данных. Это уже будет ультимативная открытость формата :)

PS2
А я вот нечто подобное через ini файл вот делаю.

Ты, часом, не ozf свой писать удумал? :-)

Кстати, встенографировать в bmp свои double не хочешь? Типа, против хакеров. :))

вариантов куча:
1) Structured Storage - плавали, знаем - достаточно неплохо, если не выходить за базовые возможности
2) zip; а лучше - pak - тот же zip, только без сжатия, формат позволяет
3) SQLite - хранить в блобах

сейчас, кстати, я бы выбрал вариант 3 - уж очень много преимуществ имеет :)

кпк-шный книжный формат FB2 (Fiction Book 2) тоже хранит картинки (а заодно и форматированный текст) внутри XML-файла.

> [35] Ломброзо © (03.10.06 19:31)

> Покурите про медицинский стандарт DICOM

Попробовал посмотреть на http://medical.nema.org/dicom/2006/
Возможно он подошел бы, однако, размер описаний впечатляет.
Слишком долго его придётся курить.

> [43] Marser © (03.10.06 21:09)

> Ты, часом, не ozf свой писать удумал? :-)

1. Программа уже написана и работает, только сохранения нет.
2. Что такое ozf ?

> [44] TUser © (03.10.06 21:17)

> Кстати, встенографировать в bmp свои double не хочешь? Типа,
> против хакеров. :))

нет, такого не надо :)

> [41] Yanis © (03.10.06 20:06)

> [45] wicked © (03.10.06 21:17)

> Structured Storage

Какие преимущества у этого варианта перед зипом ?

> [45] wicked © (03.10.06 21:17)

> 2) zip; а лучше - pak - тот же zip, только без сжатия, формат
> позволяет

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

Хотя, возможно, я что-то путаю. Припоминаю, что в одной знакомой мне радиологической информационной системе координаты каких-то областей лежали таки в БД

> Virgo_Style © (03.10.06 18:42) [6]

действительно, если формат графики допускает тэги, то хранить в них все необходимые данные - самый удобный и быстрый вариант.

> Какие преимущества у этого варианта перед зипом ?

Это что то наподобии файловой системе в файле.
Ничего не запаковывается и не распаковывается, следовательно затрачивается меньше времени на доступ к инфе.
Поддерживается на уровне Windows, не юзаются сторонние библиотеки.
Можно использовать (кажется) во всех версиях Windows.
Не нужно разрабатывать фой формат файла =)

> 2. Что такое ozf ?

Про Ozi Explorer слыхал? Это программа для работы с картами, в частности для GPS. Так вот, его формат, ozf это, грубо говоря, то что ты описал.

> [50] Ломброзо © (03.10.06 22:17)

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

> [51] Слон © (03.10.06 23:57)

Изображения уже давно только BMP, поддержку других форматов никто не требовал.
В формате BMP нет специальных полей для комментариев (хотя можо попытаться писать в конце или между заголовками и пикселями).
В любом случае, вариант с тэгами мне не очень нравится. Пусть лучше или каринка отдельно, или не открывается в других программах напрямую.

> [52] Yanis © (04.10.06 09:54)

Ничего существенного не вижу:
В зипе тоже система с фалами и даже папками.
Зип тоже не обязательно паковать. Постоянный быстрый доступ к файлу не требуется.
Скорее, отсутствие встроенного в формат сжатия я бы рассматривал как недостаток.
Для зипа существуют библиотеки, в т.ч. с исходниками и не требующие внешних файлов, поэтому отсутствие поддержки на уровне windows не проблема.
Отталкивает от рассмотрения этого варианта то, что MS Office, ранее использовавший Structured Storage , теперь тоже перешел на зип.

> [53] Marser © (04.10.06 15:49)

Что-то мне не удалось найти описание формата, потому вопросы:
Ты работал с этим форматом ?
Если да, то:
Он открыт или работа через SDK ? Где посмотреть подробнее ?

Формат файла. Найти похожие ветки