Байтшкодим: Header

---

Представим себе ситуацию: нужно загрузить swf`ку и требуется срочным образом узнать о её характеристиках, до того как swf`ка сама поймёт, что она swf`ка и сможет нам это сказать. Нормальные люди хранят, например, xml файл с нужным описанием или что нибудь-ещё. Но не мы.

К тому же, мы совсем не признаем сжатие swf`ек. Мы считаем, что сжатые swf`ки - пережиток прошлого, с нашими пропускными способностями каналов связи это оскорбление экономить на размере.

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

Итак, что такое байткод?
Теперь давайте с вами договоримся: я буду называть байткодом всю ерунду, которая содержится внутри swf файла. Конкретно сегодня мы будем работать с заголовком. Код, который исполняется AVM внутри тега doABC я буду называть abc-кодом. Для тех кто не понял что такое abc-код скажу проще: это те команды, которые компилируются из AS в тот-самый-байткод. О нём я, возможно, расскажу как нибудь позже.

Итак, нам понадобится:
Калькулятор
HEX-редактор


Берём любую swf`ку и открываем её HEX-редактором. Видим много страшных непонятных чисел, делаем умное лицо, морщим лоб и усиленно пытаемся декомпилировать swf`ку в уме. Не получилось? То-то. Но если посмотреть на первые 3 байта swf`ки можно заметить, что там вполне такие нормальные символы: FWS или CWS. Это сигнатура файла. Она есть у каждого файла и обозначает его тип. Вырезав их любой файл потеряет "голову" и мало кто его признает за своего.
Глядим на первый байт: там стоит буква F (0x46) или буква C (0x43) - это сокращения от Compressed и Full. Если первая буква C - Вам не повезло, придётся менять положение. К сожалению изменение первой буквы результата не даст, swf`ку надо "пережать". Я пользуюсь программкой cws2fws, консольное приложение - для меня вполне удобное.

Итак, swf`ка пережата и имеет сигнатуру FWS. Другое дело! Теперь можно хвастаться своим коллегам что мы умеем пережимать swf`ки.
Давайте попробуем сперва разобраться на пальцах, как этот самый байткод в Header`е устроен. Работать будем с версией swf файла 9 и 10, спецификации формата меняются от версии к версии. Header для 9 и 10 одинаков, так что тут выбор за вами.
Вот вырезка из спецификации:
Не очень красивое форматирование, но каждый момент я проговорю отдельно.
Итак, поехали.
Первый байт:
Signature UI8 Signature byte
UI8 означает Unsigned Integer 8 bit, т.е. размер один байт.

Следующие 2 байта:
Signature UI8 Signature byte always “W”
Signature UI8 Signature byte always “S”

Это означает, что 2 байт всегда W, третий байт всегда S. Делов то!



ВАЖНО! Метод загрузки, изложенный ниже писался мной до получения новых технических знаний. Даже сжатую флешку можно отдать обычному Loader`у, а после взять у него байты по contentLoaderInfo.bytes и они будут расжаты, поэтому в практическом применении стоит грузить именно через Loader и байты брать от него же.
Однако я считаю что суть этой статьи не в методах загрузки SWF`ки, а именно в парсе, поэтому статью переписывать я не буду. Спасибо за внимание.


Теперь пока не забыли, быстренько оформим всё это дело в коде. По идее, надо бы сделать ради этого отдельный класс, но мне лень. Лепим в Main`е.
log - это типа аналог trace, чтобы выводило на экран. Мне так хочется.

Мы создаём urlStream и просим его загрузить testFull.swf, теперь нужно дождаться пока поступят байты: это дело контролирует onProgress.
Теперь толстый момент: размер Header`а не определен заранее и в целях упрощения подачи материала мне хотелось бы чтобы при начале его разбора он полностью был загружен. Обычно он занимает байтов 20, мы подождем когда загрузим 50, чтобы уж точно наверняка. Я не считаю это за "плохой" приём: скорость интернета измеряется в мегабитах - 30 байт... О чем речь?

SWF структура для unsigned integer`ов любит быть LITTLE_ENDIAN - и загружать её мы будем так же, т.к. в основном с ними нам и предстоит работать. Сразу скажу, что в случае с битами дело обстоит наоборот - они хранятся как BIG_ENDIAN - но с ними мы будем работать чуть позже и обходными путями.
Вот например из оф. доки пример, как хранится число:
Сразу считаем первые 3 байта как строку и если она не такая, как нам нужна - то вываливаемся и прекращаем работу. Всё просто.

Далее идёт:
И это снова byte. Просто считываем byte и выводим.
Далее:
UI32, обратите внимание. Это 32 бита, т.е. 4 байта. Ещё тонкий момент: это дело хранит размер файла после декомпрессии. В нашем случае - FWS - разжимать нечего, поэтому размер файла совпадает с оригинальным. В случае с CWS они будут расходиться: это сделано для более эффективного разжимания.
32 бита считывает метод readUnsignedInt:
А вот теперь сложнее.
Есть тип данных такой - RECT, это как видно из названия прямоугольник. Он задает 4 свойства: xMin, xMax, yMin, yMax. Вроде всё просто, элементарный прямоугольник, но он немного сложен своим заданием: выравнивание происходит не по байтам, а по битам.
Как это? Сейчас объясню. Например вот группа байтов:
11010100 10101010 011011111
Каждый байт "как-бы" самодостаточен и несет собственную смысловую нагрузку - как было выше. В случае с RECT ситуация другая:
11010100 10101010 011011111

Цветом выделены группировки.
Эти бесстыдники не то чтобы своё место удержать не могут - они ещё и на чужое лазят. Нужно их сгруппировать обратно.
Во flash`е работа с битами проходит не под полным контролем - нету флага переноса, например, благодаря которому можно было бы биты легко перекидывать и других "низкоуровневых" вещей. Я уже писал про биты - если у Вас это вызывает затруднения - прочитайте мои прошлые статьи. Объекта "бит" у нас тоже нету, поэтому будем крутиться: записываем все значения в int и uint. Например, комбинация битов 110 в int будет выглядеть так:
00000000 00000000 00000000 00000110

Печально, но тут никуда не денешься.
Теперь снова о RECT: первые 5 битов в конструкции означают количество битов, отведенных под xMin, xMax, yMin, yMax по отдельности.
Например, если первые 5 битов 01111 (это 15), то потом 4 раза по 15 битов будут заданы xMin, xMax, yMin, yMax.

Ради этого я написал класс BitMachine. Суть его в том, что ему передается любой IDataInput (например наш _urlStream) и потом оттуда тянутся биты в нужном количестве.
Вот реализация:
Писался класс на скорую руку, поэтому не могу гарантировать "красоту" решения. Тем не менее, он работает - комментарии по исполнению приведены в нём.
Теперь парсим этот самый RECT:
В случае Header`а xMin и yMin всегда по нулям, а xMax и yMax - это stageWidth и stageHeight "по умолчанию". Результаты они возвращают в твипсах, т.е. 1/20 пикселя.
Но это не проблема, ведь так?
Дальше по описанию идёт
Это типа первый байт на дробную часть, второй байт на целую. Чтобы дробную сделать дробной нужно её поделить на 255, т.е. на максимально возможное значение в байте. Тогда он будет лежать между [0,1]. Он вылезает, если задавать FPS, например 30.2. В 99% случаев первый байт будет по нулям. Тем не менее:
Обратите внимание, выделено 16 битов (UI16) и мы считали 2 раза по 8, т.е. те же 16!

Ну и закрывает это дело:
На этот раз число действительно "целое" - а не как в прошлый раз, поэтому просто считываем 16 бит:
На этом кончается Header флешки.
Есть такой любопытный момент:
Чем это объясняется - я не знаю. Если Вы знаете - пожалуйста, поделитесь =)
Спасибо за внимание.