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

← →
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-файлов

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

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

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

> [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]

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

> > Или предлагаешь её тоже в 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

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

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

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

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

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

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

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

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

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

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

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

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

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