Sergey Spiridonov -> [email protected] @ Sun, 22 Mar 2015 17:29:15 +0100:
>> SS> Хочется именно специализированную программу. >> >> Мой опыт подсказывает, что задача, возлагаемая описанной программой на >> юзера, сравнима по сложности с задачей написания парсера формата >> средствами перлового или тиклового unpack. SS> На юзера возлагается задача всего лишь запустить программу. Описания форматов SS> программа уже должна иметь в своей базе данных. SS> Дописывать и расширять базу данных нужно только для новых и нестандартных SS> форматов. SS> Более того, такая программа, по-моему, просто обязана быть частью SS> дистрибутива. SS> Хорошая аналогия - программа file. SS> Ещё такая программа могла бы предоставлять удобный интрерфейс для SS> реверс-инжиниринга бинарных форматов. SS> Короче, удивлён что её нет. Есть принципиальная разница между программой, которая уже знает форматы, и программой, которую можно использовать для реверс-инжиниринга бинарных форматов. Первый случай решается по принципу UNIX way: берем file, смотрим, что он сказал про формат, запускаем смотрелку этого формата. Всё есть в дистрибутиве. Ключевые слова - file, которое ты уже знаешь, и mailcap. Кажется, была и какая-то ориентированная на иксы программа, которая объединяла функциональность. Для выяснения, почему и это, скорее всего, плохая идея в общем случае, могу порекомендовать поставить wireshark, запустить его и прикинуть количество ТОЛЬКО СЕТЕВЫХ форматов, известных ему (он умеет по просьбе юзера, а при наличии стандартного порта и самостоятельно, интерпретировать данные как пакеты или поток различных сетевых форматов). И понять, что к КАЖДОМУ нужно было приложить интеллект, чтобы прочесть стандарт и проинтерпретировать структуру - она в бинарных форматах в большинстве случаев существенно нелинейна. Второй же случай - это задача на программирование. От того, что это задача на программирование черного ящика, она легче не становится, скорее наоборот. Поэтому дешевле всего оказывается короткий скрипт с использованием unpack на перле или тикле, весь UI которого сводится к выводу в stdout того, что он проинтерпретировал (лучше, наверное, параллельно с дампом), а интерпретация написана в коде. Цикл работы: написали интерпретатор, запустили, посмотрели на вывод, подрихтовали интерпретатор, запустили, ... Попытки навернуть на это гуй и куцый язык программирования делают процесс существенно дороже, причем не столько для программиста оного гуя, сколько для пользователя, он же программист парсера. Ему придется бороться с куцым языком программирования в незнакомом гуе. Ну, к гую со временем привыкнет (тот же xterm, в конце концов, тоже гуй), а куцый язык программирования никуда не денется. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
