плиток_по_горизонтали = ceil(ширина_изображения / ширина_плитки)
плиток_по_вертикали = ceil(высота_изображения / высота_плитки)
всего_плиток = плиток_по_горизонтали * плиток_по_вертикали
Изображения в каталоге запчастей ETKA
Доброго времени суток, уважаемые форумчане. Подскажите пожалуйста, кто-нибудь сталкивался с расшифровкой изображений из каталога запчастей ETKA? Изображения там сохранены в формате .tif, но ни одна прога у меня их не может открыть. Может кто-то из Вас делал подобное и знает алгоритм расшифровки.
Там спецформат. К родному tiff'у имеет мало отношения. Гуглите flexcat® SENSDOC®.
Это я понял что там спецформат. На сайт SENSDOC я тоже заходил, но оттуда нельзя скачать программу. Я ж поэтому и срашиваю можно ли как нибудь расшифровать эти изображения или хотя бы SENSDOC этот скачать?
Расшифровать можно. Все можно. Вопрос времени.
Скачать тоже можно. За деньги. Вопрос суммы.
Скачать тоже можно. За деньги. Вопрос суммы.
Lerkin а Вы лично не пробовали это расшифровать? Может у Вас есть какой то опыт в этом направлении?
Цитата: DesDeemon
Lerkin а Вы лично не пробовали это расшифровать? Может у Вас есть какой то опыт в этом направлении?
Я расшифровал все изображения в ЕТКА - файлы в формате png и gif.
Если интересно - пишите в личку.
Уважаемые форумчане, поскольку здесь не все помогают научиться бесплатно, то вопрос остается открытым. Кто-нибудь пробовал и/или может помочь расшифровать файлы изображений автокаталога ETKA?
tiff?фотошоп или самый простой способ просмотреть изображения в формате TIFF это скинуть все эти фотки в одну отдельную папку и ту да же закинуть одну любую фотку jpg,затем сделать просмотр стандартными средствами виндовс и просто пролистывать,должно сработать!)
myurico, это зашированный tiff. Внутри него находится изображение с другим расширением. Первые байты этих файлов совпадают, это говорит о том что они зашифрованы одинаковым алгоритмом. Как говорил eugeny98 внутри этих tiff находятся изображения в формате png и gif. Вся суть в том что мне нужно разобраться с алгоритмом шифрования, но к сожалению пока никак не получается.
Значит так
Особо там нету ничего тяжелого
1. выцыпать файл который расшифровал ETKA - т.е. получаем нормальный файл tiff или png.
2. Исходный (зашифрованный) файл из ETKA
3. т.е. получили нормальный фал рисунок ETKA и зашифрованный. Берм HEX - просмотрщик, Берем калькулятор - сравниваем - и догадываемся чем же они зашифрованы. ;)
Эти файлы мелочь. Идем дальше
---
Есть в ETKA новые рисунки - красивые они zgd-файлах (ну например 409260200.zgd). Походу это архивы. Кто смог сделать - подскажите направление. готов отблагодорить за вознагрождение.
Особо там нету ничего тяжелого
1. выцыпать файл который расшифровал ETKA - т.е. получаем нормальный файл tiff или png.
2. Исходный (зашифрованный) файл из ETKA
3. т.е. получили нормальный фал рисунок ETKA и зашифрованный. Берм HEX - просмотрщик, Берем калькулятор - сравниваем - и догадываемся чем же они зашифрованы. ;)
Эти файлы мелочь. Идем дальше
---
Есть в ETKA новые рисунки - красивые они zgd-файлах (ну например 409260200.zgd). Походу это архивы. Кто смог сделать - подскажите направление. готов отблагодорить за вознагрождение.
И что, решение для ZGD-картинок нашлось? Я вот уже несколько дней никак не могу понять эти файлы. Может кто-то подсказку даст?
Цитата: Sandulf
И что, решение для ZGD-картинок нашлось? Я вот уже несколько дней никак не могу понять эти файлы. Может кто-то подсказку даст?
Ага, печалька по ним (
По поводу вашего сообщения
Я понимаю что немного не в тему мой вопрос, но может кто-то знает. Мне нужно раcшифровать файлы zgd из ETKA. Например вот файлик: ETKAVW-SE-SK-AUBilder787787035400.zgd. В этих файлах красивые объемные картинки. Выполняя их загрузку, ETKA разархивирует их во временную папку windows (это архив gz, чтобы самому его распаковать - достаточно переименовать 787035400.zgd в 787035400.zgd.gz и дальше работать как с zip-архивом). В распакованном виде ETKA сохраняет их с расширением SGD. Но все равно их ничем не откроешь. У меня уже есть утилита конвертации базы данных в MySQL, TIF и PNG картинки тоже уже разобрал, остались только эти zgd, уже несколько дней голову ломаю. Судя по виду этих картинок в самой ETKA, это точечный рисунок с индексированными цветами, наподобие png или gif.
Обратите внимание что размер распакованного архива (это когда вы пишите достаточно переименовать 787035400.zgd в 787035400.zgd.gz и дальше работать как с zip-архивом) отличается от размера распакованного ETKA (ETKA разархивирует их во временную папку windows (это архив gz))
Я думаю тут нужно просить чела, умеющего делать декоддинг (дессасемблирование)
Да не, размер такой-же, файлы идентичные. Я проверял специально.
Цитата: bunak
Я думаю тут нужно просить чела, умеющего делать декоддинг (дессасемблирование)
Да я уже три дня гоняю ETKA под отладчиком! Но там столько кода, что сложно найти истину. Еще надстройка mfc42.dll от Microsoft постоянно под ногами путается, мешает исследованию. Всю работу с картинками выполняет LxidDcod.dll, LxidDib.dll. LxidDcod.dll выполняет предварительную расшифровку картинок. sgd не проходят расшифровку, т.е. они не зашифрованы (надо только распаковать zgd). Далее происходит преобразование любой картинки в DIB Bitmap в модуле LxidDib.dll (это необходимо для отображения картинки на экране под виндовс). И тут сильно все перемешано с mfc42.dll, их классами и файловыми потоками.
Обратите внимание что размер распакованного архива (это когда вы пишите достаточно переименовать 787035400.zgd в 787035400.zgd.gz и дальше работать как с zip-архивом) отличается от размера распакованного ETKA
Возможно вы перехватили этот файл не в тот момент, раньше чем он будет полностью записан. Там же в начале идет рапаковка, файл записывается почти всегда кусками по 16кб, после чего он открывается в другом потоке ETKA, потом во всех потоках закрывается и удаляется.
Цитата: Sandulf
Да не, размер такой-же, файлы идентичные. Я проверял специально.
Давно возился с ними, может и перепутал их.
Цитата: Sandulf
sgd не проходят расшифровку, т.е. они не зашифрованы (надо только распаковать zgd).
1. я проверил свои наработки. У меня размеры распакованного фала ЕТКА отличаются от размеров распакованным zip-архиватором!!! Чуть позже еще раз проверю.
2. Если вы утверждаете что размеры совпадают то сравните побайтово, не наблюдается ли закономерность между файлами. Кроме того может сам зип архив перед распаковкой прогнать по XOR_с_ключем?
Файлы идентичные. Только-что перепроверил. Подробности во вложении.
Обнаружил странную вещь: После распаковки распакованный sgd файл закрывают, после этого открывают снова, но уже с защитой от его открывания другими программами (dwShareMode=0, "the file or device cannot be shared and cannot be opened again until the handle to the file or device is closed"). Далее, размер файла увеличивается примерно в два раза, но записи/чтения не происходит, вторая половина файла просто автоматически системой заполнена нулями. После этого файл обратно обрезается до прежнего размера (такого, какой выдает "ручная" разархивация zgd) и закрывается. Для чего это? Может просто чтобы меня запутать?
Sandulf
Скажите а при десассемблировании (при разборе тиф-рисунков), вы сразу увидили шифрацию? Не наблюдается ли подобные действия с sgd-файлами?
И сразу вопрос может dll можно каким нибудь образом использовать для распаковки?!
Скажите а при десассемблировании (при разборе тиф-рисунков), вы сразу увидили шифрацию? Не наблюдается ли подобные действия с sgd-файлами?
И сразу вопрос может dll можно каким нибудь образом использовать для распаковки?!
Скажите а при десассемблировании (при разборе тиф-рисунков), вы сразу увидили шифрацию? Не наблюдается ли подобные действия с sgd-файлами?
Явно просматривается конструкция такого вида:
Код:
// Предварительная загрузка, на этом этапе zgd превращается в sgd
if(ext=='PNG' || ext=='TIF'){
Расшифровать();
}
// Дальнейшая загрузка картинок (преобразование в DIB для вывода на экран)
if(ext=='PNG' || ext=='TIF'){
Расшифровать();
}
// Дальнейшая загрузка картинок (преобразование в DIB для вывода на экран)
Можно, но необходимо понять, какие параметры необходимо передать нужной функции.
В модуле LxidDcod.dll необходимо сперва вызвать DECODER_NewDecoderInterface() (без параметров) для инициализации модуля, по завершении работы вызвать DECODER_DeleteDecoderInterface(). Расшифровка и подготовка к выводу на экран всех картинок (в т.ч. tif и png) выполняется функцией DECODER_MakeDib(11 параметров).
Кроме того, в этом модуле есть функции, которые ETKA ни разу не вызывает: DECODER_MakeDibFromFile, DECODER_GetSpecialInfo, DECODER_GetFileInfo.
Ок
Смотри, только что поступил другим образом. Восстановил удаленные в ЕТКА - файлы.
И вот теперь опять утверждаю, что файлы .sgd отличаются даже по размеру с файлами unzip:.zgd
И по содержимому тоже - отличаются!!!
Смотри, только что поступил другим образом. Восстановил удаленные в ЕТКА - файлы.
И вот теперь опять утверждаю, что файлы .sgd отличаются даже по размеру с файлами unzip:.zgd
И по содержимому тоже - отличаются!!!
Да, вы правы. После разархивирования файл закрывается, снова открывается и с ним еще производятся какие-то манипуляции. Мне уже удалось получить картинку из ETKA, просто скопировав уже расшифрованную (в DIB) картинку из памяти ETKA в файл и дополнив данные заголовочными структурами DIB-файла. Но до создания автоматического расшифровщика картинок мне еще далеко. Главная проблема в том, что функции расшифровки в качестве параметров принимают объекты (или интерфейсы?) C++. Воссоздать эти объекты мне не представляется возможным, вместо этого я буду искать более "низкоуровневые" функции, которые непосредственно выполняют расшифровку.
Sandulf
готов приобрести у вас методы распаковки zgd-файлов, естественно за вознаграждение
готов приобрести у вас методы распаковки zgd-файлов, естественно за вознаграждение
Короче, я эту работу пока откладываю. Начальник сказал, сделаем вначале со старыми картинками (а они там все есть в двух вариантах, непонятно зачем), а потом будем "наводить красоту". Время деньги. К вопросу zgd вернусь наверно через полгода-год, или если в ETKA уберут дубликаты zgd в tif формате.
Цитата: Sandulf
... и дополнив данные заголовочными структурами DIB-файла
Можете подсказать доку откуда брать чтобы правильно наполнить
Цитата: Sandulf
со старыми картинками (а они там все есть в двух вариантах, непонятно зачем)
Потому что вначале были они (старые картинки) и только потом начали появляться цветные.
О чем вы спрашиваете? о том, какой формат у DIB файла? Необходимо записать в файл:
1. BITMAPFILEHEADER http://msdn.microsoft.com/en-us/library/aa930979.aspx
2. После него сразу идет BITMAPINFO http://msdn.microsoft.com/en-us/library/aa921550.aspx
3. И, собственно, сама картинка.
В принципе, какая разница, в каком формате сохранять? для использования в ВЕБ удобнее сохранить в png, но с ним мне еще надо разбираться. Я выбрал DIB, поскольку он настолько простой, что в нем за 30 минут можно полностью разобраться. Непосредственно данные изображения могут быть одинаковы в png, bmp, tif, dib и многих других форматах, с отличиями только в заголовочных данных. т.е. с таким же успехом можно сохранять и в png без какого-либо преобразования карты пикселей (но при использовании в коммерческих целях, а не для проверки своей программы, преобразовывать все таки придется ради многократного уменьшения веса картинки).
Это я понял. Но у самых новых машин все картинки дублируются: для каждого номера изображения есть tif и zgd файл, хотя можно было делать новые только zgd.
Вставлю свои 5 копеек.
Если вы думаете, что сохранять в формат PNG сложно, могу посоветовать воспользоваться GDI+. Как я понял, вы вручную собрались кодировать файлы, но это не нужно. GDI+ поможет перевести файл из одного формата в другой, или даже из памяти сохранить в PNG.
Если вы думаете, что сохранять в формат PNG сложно, могу посоветовать воспользоваться GDI+. Как я понял, вы вручную собрались кодировать файлы, но это не нужно. GDI+ поможет перевести файл из одного формата в другой, или даже из памяти сохранить в PNG.
Готов опять помудохаться с zgd-файлами. Если у кого нить есть подсказки, пишите буду ломать голову
Готов оплатить подсказки и решения
Готов оплатить подсказки и решения
Разобрал структуру SGD файлов в объеме, достаточном для декодирования всех изображений из каталога ETKA. Кому нужно, описание формата ниже.
Формат SGD, насколько мне удалось узнать, используется в одной немецкой ГИС, и сам по себе достаточно навороченный. Изображения в каталоге ETKA используют небольшое подмножество всех предусмотренных функций формата, что делает возможным написание декодера.
Основой изображения служит растровый слой MRCI, поверх которого рисуются векторные элементы (используются для стрелок и надписей).
Способ хранения растровых данных в формате MRCI "плиточный": исходное изображение разбивается на плитки заданного размера, каждая плитка отдельно кодируется. Затем плитки последовательно (слева направо, сверху вниз) пишутся в файл. Плитки по правому и нижнему краям изображения могут иметь размер меньше номинального, если ширина или высота изображения не кратна размеру плитки.
Формат предусматривает несколько способов кодирования плиток: lzw, zlib, png, без кодирования. Для изображений в каталоге ETKA используется только метод zlib.
Структура SGD файла
Адреса в SGD файле всегда кратны 4 байтам для удобства работы с ним через отображение памяти. Порядок байт в файле little-endian.
Первые 16 байт занимает заголовок файла:
По смещению 0x4c от начала файла находится таблица директорий:
Интересна только директория с типом 0 (каталог записей). В ней содержатся адреса всех записей в SGD файле, которые нужны для декодирования. По абсолютному адресу из таблицы директорий находится заголовок каталога (смещения указаны от начала структуры):
Здесь и далее для получения абсолютного адреса записи в файле нужно добавить константу 0x94 к адресу в таблице. Заголовок у каждой записи одинаковый и имеет вид:
Интересны следующие типы записей:
Структура записи MRCIHEADER (следует за стандартным заголовком записи):
По адресу палитры расположен ее заголовок:
За заголовком следует сама палитра размером (кол-во цветов X размер пикселя) байт. Стоит заметить, что реальное количество цветов, используемое в растровом слое, как правило меньше указанного в заголовке палитры (обычно не более 8).
Директория с адресами плиток:
Структура плитки:
За заголовком следует сжатый блок данных. Размер блока вычисляется из поля "размер структуры" за вычетом размера поля "метод сжатия" (4 байта).
Структура записи POLYLINE2D (следует за стандартным заголовком записи):
Структура записи TEXTLINE2D (следует за стандартным заголовком записи):
Алгоритм конвертации SGD
Формат SGD, насколько мне удалось узнать, используется в одной немецкой ГИС, и сам по себе достаточно навороченный. Изображения в каталоге ETKA используют небольшое подмножество всех предусмотренных функций формата, что делает возможным написание декодера.
Основой изображения служит растровый слой MRCI, поверх которого рисуются векторные элементы (используются для стрелок и надписей).
Способ хранения растровых данных в формате MRCI "плиточный": исходное изображение разбивается на плитки заданного размера, каждая плитка отдельно кодируется. Затем плитки последовательно (слева направо, сверху вниз) пишутся в файл. Плитки по правому и нижнему краям изображения могут иметь размер меньше номинального, если ширина или высота изображения не кратна размеру плитки.
Код:
Структура SGD файла
Адреса в SGD файле всегда кратны 4 байтам для удобства работы с ним через отображение памяти. Порядок байт в файле little-endian.
Первые 16 байт занимает заголовок файла:
Код:
Смещение Тип Описание Значение
-------- --- -------- --------
0x00 U32 Магическое значение 0x000a0090
0x04 U16 Номер версии 0x07db
0x06 U16 Номер ревизии 0x0406 или 0x0407
0x08 U32 Неизвестно 0x01020015
0x0c U32 Магическое значение 0x55555555
-------- --- -------- --------
0x00 U32 Магическое значение 0x000a0090
0x04 U16 Номер версии 0x07db
0x06 U16 Номер ревизии 0x0406 или 0x0407
0x08 U32 Неизвестно 0x01020015
0x0c U32 Магическое значение 0x55555555
Код:
Смещение Тип Описание Значение
-------- --- -------- --------
0x4c U32 Количество директорий в SGD файле 3
0x50 U32 Тип директории 2 2
0x54 U32 Абсолютный адрес начала директории 2
0x58 U32 Тип директории 1 1
0x5c U32 Абсолютный адрес начала директории 1
0x60 U32 Тип директории 0 0
0x64 U32 Абсолютный адрес начала директории 0
0x68 U32 Неизвестно 0
0x6c U32 Размер SGD файла
-------- --- -------- --------
0x4c U32 Количество директорий в SGD файле 3
0x50 U32 Тип директории 2 2
0x54 U32 Абсолютный адрес начала директории 2
0x58 U32 Тип директории 1 1
0x5c U32 Абсолютный адрес начала директории 1
0x60 U32 Тип директории 0 0
0x64 U32 Абсолютный адрес начала директории 0
0x68 U32 Неизвестно 0
0x6c U32 Размер SGD файла
Код:
Смещение Тип Описание Значение
-------- --- -------- --------
0x00 U16 Младшие 16 бит размера директории
0x02 U16 Тип директории 0x63
0x04 U32 Размер директории
0x08 U32 Неизвестно
0x0c U32 Число записей в директории
0x10 U32 Неизвестно
0x14 U32 Неизвестно
0x18 U32 Относительный адрес записи 0
0x1c U32 Относительный адрес записи 1
... ... ...
-------- --- -------- --------
0x00 U16 Младшие 16 бит размера директории
0x02 U16 Тип директории 0x63
0x04 U32 Размер директории
0x08 U32 Неизвестно
0x0c U32 Число записей в директории
0x10 U32 Неизвестно
0x14 U32 Неизвестно
0x18 U32 Относительный адрес записи 0
0x1c U32 Относительный адрес записи 1
... ... ...
Код:
Смещение Тип Описание Значение
-------- --- -------- --------
0x00 U16 Размер записи
0x02 U16 Тип записи 0x1a, 0x2d, 0x37 и др.
0x04 U32 Номер записи
0x08 U32 Неизвестно
0x0c U32 Флаги отрисовки (подробнее об этом поле ниже)
0x10 U32 Неизвестно
0x14 U32 Неизвестно
0x18 U32 Неизвестно
-------- --- -------- --------
0x00 U16 Размер записи
0x02 U16 Тип записи 0x1a, 0x2d, 0x37 и др.
0x04 U32 Номер записи
0x08 U32 Неизвестно
0x0c U32 Флаги отрисовки (подробнее об этом поле ниже)
0x10 U32 Неизвестно
0x14 U32 Неизвестно
0x18 U32 Неизвестно
Код:
Значение Название Описание
-------- ------- --------
0x1a MRCIHEADER Растровый слой в формате MRCI
0x2d POLYLINE2D Ломаная линия
0x37 TEXTLINE2D Текстовая метка
-------- ------- --------
0x1a MRCIHEADER Растровый слой в формате MRCI
0x2d POLYLINE2D Ломаная линия
0x37 TEXTLINE2D Текстовая метка
Код:
Смещение Тип Описание Значение
-------- --- -------- --------
0x1c U32 Ширина изображения в пикселях
0x20 U32 Высота изображения в пикселях
... ... ...
0x6c U32 Размер пикселя в байтах 1
0x70 U32 Битовая глубина 8
0x74 U32 Относительный адрес палитры
0x78 U32 Номинальная ширина плитки в пикселях 256
0x7c U32 Номинальная высота плитки в пикселях 256
... ... ...
0x90 U32 Относительный адрес директории с адресами плиток
-------- --- -------- --------
0x1c U32 Ширина изображения в пикселях
0x20 U32 Высота изображения в пикселях
... ... ...
0x6c U32 Размер пикселя в байтах 1
0x70 U32 Битовая глубина 8
0x74 U32 Относительный адрес палитры
0x78 U32 Номинальная ширина плитки в пикселях 256
0x7c U32 Номинальная высота плитки в пикселях 256
... ... ...
0x90 U32 Относительный адрес директории с адресами плиток
Код:
Смещение Тип Описание Значение
-------- --- -------- --------
0x00 U16 Размер структуры
0x02 U16 Тип структуры 0x04ef
0x04 U16 Размер пикселя в байтах 1
0x06 U16 Битовая глубина 8
0x08 U32 Количество цветов в палитре 256
-------- --- -------- --------
0x00 U16 Размер структуры
0x02 U16 Тип структуры 0x04ef
0x04 U16 Размер пикселя в байтах 1
0x06 U16 Битовая глубина 8
0x08 U32 Количество цветов в палитре 256
Директория с адресами плиток:
Код:
Смещение Тип Описание Значение
-------- --- -------- --------
0x00 U16 Размер структуры
0x02 U16 Тип структуры 0x04ed
0x04 U32 Относительный адрес плитки 0
0x08 U32 Относительный адрес плитки 1
... ... ...
-------- --- -------- --------
0x00 U16 Размер структуры
0x02 U16 Тип структуры 0x04ed
0x04 U32 Относительный адрес плитки 0
0x08 U32 Относительный адрес плитки 1
... ... ...
Код:
Смещение Тип Описание Значение
-------- --- -------- --------
0x00 U16 Размер структуры
0x02 U16 Тип структуры 0x04ee
0x08 U32 Метод сжатия 1 (zlib)
-------- --- -------- --------
0x00 U16 Размер структуры
0x02 U16 Тип структуры 0x04ee
0x08 U32 Метод сжатия 1 (zlib)
Структура записи POLYLINE2D (следует за стандартным заголовком записи):
Код:
Смещение Тип Описание
-------- --- --------
0x1c U32 Неизвестно
0x20 U32 Неизвестно
0x24 U32 Количество вершин
0x28 F32 Координата "x" вершины 0
0x2c F32 Координата "y" вершины 0
0x30 F32 Координата "x" вершины 1
0x34 F32 Координата "y" вершины 1
... ... ...
-------- --- --------
0x1c U32 Неизвестно
0x20 U32 Неизвестно
0x24 U32 Количество вершин
0x28 F32 Координата "x" вершины 0
0x2c F32 Координата "y" вершины 0
0x30 F32 Координата "x" вершины 1
0x34 F32 Координата "y" вершины 1
... ... ...
Код:
Смещение Тип Описание
-------- --- --------
0x1c U32 Неизвестно
0x20 U32 Неизвестно
0x24 F32 Координата "x" левого края надписи
0x28 F32 Координата "y" нижнего края надписи
0x2c F32 Неизвестно
0x30 F32 Ширина надписи
0x34 F32 Неизвестно
0x38 F32 Неизвестно
0x3c F32 Высота надписи
0x40 F32 Неизвестно
0x44 F32 Неизвестно
0x48 STR Текст надписи (заканчивается нулевым байтом)
-------- --- --------
0x1c U32 Неизвестно
0x20 U32 Неизвестно
0x24 F32 Координата "x" левого края надписи
0x28 F32 Координата "y" нижнего края надписи
0x2c F32 Неизвестно
0x30 F32 Ширина надписи
0x34 F32 Неизвестно
0x38 F32 Неизвестно
0x3c F32 Высота надписи
0x40 F32 Неизвестно
0x44 F32 Неизвестно
0x48 STR Текст надписи (заканчивается нулевым байтом)
- Проверяем заголовок файла. При необходимости распаковываем (если файл сжат gzip).
- Находим в директории с типом 0 адрес структуры MRCIHEADER.
- Разбираем MRCIHEADER, определяем размер изображения и количество плиток, выделяем под них память.
- Находим палитру по ее адресу и разбираем.
- Находим директорию с адресами плиток, распаковываем плитки в выделенную область памяти.
- Выделяем память под итоговое изображение, "мостим" его плитками.
- Еще раз проходим по директории с типом 0, рисуем поверх изображения с применением любой библиотеки векторной графики ломаные линии и текстовые метки. Важный момент: записи, у которых значение поля "Флаги отрисовки" равно нулю, нужно пропускать, иначе будет нарисовано много лишнего.
- Сохраняем результат в файл (BMP, PNG или любой другой).
Красава!!!!
Цитата: Кхалиси
Я открывала файлы такого формата, много программ умеют это делать
Ну да, ну да
Можете пару программ назвать