Comments 23
Поздравляю авторов!
Патент уже получили?
А насчет этого:
не факт, что это поможет. Модуль сможет распаковывать только те данные, которые закодированы в описываемом стандарте. Автор же малвари может придумать подобный, но свой формат упаковки данных в картинки, вплоть до стеганографического, когда при просмотре такой картинки человек даже будет видеть осмысленное изображение.
Патент уже получили?
А насчет этого:
добавят соответствующий модуль распаковки и анализа
не факт, что это поможет. Модуль сможет распаковывать только те данные, которые закодированы в описываемом стандарте. Автор же малвари может придумать подобный, но свой формат упаковки данных в картинки, вплоть до стеганографического, когда при просмотре такой картинки человек даже будет видеть осмысленное изображение.
>> Модуль сможет распаковывать только те данные, которые закодированы в описываемом стандарте.
На самом деле — не обязательно.
Модуль вполне может анализировать код распаковщика и восстанавливать алгоритм упаковки. Если по какой-либо причине восстановить алгоритм не получилось, но ясно, что где-то здесь идёт распаковка — ругаться нехорошими словами.
На самом деле — не обязательно.
Модуль вполне может анализировать код распаковщика и восстанавливать алгоритм упаковки. Если по какой-либо причине восстановить алгоритм не получилось, но ясно, что где-то здесь идёт распаковка — ругаться нехорошими словами.
some.geekly.info/pngfy.html / code.google.com/p/pngfy/ Вы опоздали лет на 5. Вообще, это еще hid.im придумали (и, судя по тому, что больше упоминаний об этом у них нет — не взлетело)
Спасибо, добавил в топик!
И вот была публикация
habrahabr.ru/post/102394/
habrahabr.ru/post/102394/
Если отдавать этот PNG не по https, то может всё сломаться — некоторые опсосы и браузеры сжимают картинки для экономии.
«изображение», которое визуально ничего осмысленного не несет и выглядит, как цветной шум
Преимущество rarjpg было именно в возможности незаметно передавать информацию в обычном, казалось бы, изображении. А для этого «изобретения» пока не придумали применения.
Некоторые облачные хостинги не считают занимаемое место файлами типа «фотографии», при условиях не превышения определённого разрешения и веса. Пакуем важные файлы с шифрованием в png и заливаем на подобные хостинги (можно сделать драйвер ФС на fusefs), получаем надёжное, бесплатное и безлимитное хранилище для важных (и не очень) файлов.
В своё время в разработке игр на флеше использовали метаданные jpeg для сохранения уровней, сделанных пользователями. Уровень сохранялся в виде картинки с превьюшкой уровня и внутри него была вся информация о самом уровне.
А тут просто каша из пикселей, скучно.
А тут просто каша из пикселей, скучно.
Я думаю, что в ближайшие год-два с распространением http/2 появится стандарт бинарного контейнера для веба наподобие CBOR, BSON или MsgPack и необходимость в столь изощренных способах упаковки данных исчезнет.
Внедрял такое на одном своём ресурсе, только использовал чёрно-белые изображения — они лучше жмутся optipng.
Что именно упаковывали, если не секрет?
Объединённые JS/CSS (в minified в сумме около 400кб), в RGB (3 байта на пиксель) пожалось до 80кб, в grayscale — до 50кб.
Сейчас повторил с обновлённой версией optipng — разница уже не такая существенная. А на некоторых файлах и вовсе RGB выигрывает. В общем надо индивидуально подбирать.
Сейчас повторил с обновлённой версией optipng — разница уже не такая существенная. А на некоторых файлах и вовсе RGB выигрывает. В общем надо индивидуально подбирать.
А если сравнить с minified версиями после обыкновенного gzip/deflate?
Существенный выигрыш сжатия png относительно минифицироанных версий скриптов заключается только в том, что первый использует всю таблицу символов, а во втором случае только печатные символы. А если сравнивать gzip и png, то особой разницы в сжатии не будет.
Существенный выигрыш сжатия png относительно минифицироанных версий скриптов заключается только в том, что первый использует всю таблицу символов, а во втором случае только печатные символы.Не только. PNG может ещё какой-нибудь deflate на данные применять, что приводит к сравнению оверхеда при разных подходах (deflate при HTTP против заголовков самого png + распаковщика, который вытащит данные из png).
Минифицированный скрипт/css ещё требует соблюдения синтаксиса соответствующего языка, что ещё повышает энтропию и, значит, потенциальную возможную степень сжатия.
Есть черновик спеки Packaging on the Web w3ctag.github.io/packaging-on-the-web/
Вместо значений цветов пикселей находится содержимое файлов-ресурсов, которое извлекается клиентской библиотекой с помощью Canvas.
Насколько я понимаю, чтение такого canvas будет «греть атмосферу» несколько секунд, что при загрузке веб-страницы совершенно неприемлемо. Хотелось бы увидеть в статье, насколько замедлилась загрузка страницы благодаря такой «оптимизации» по сравнению с несжатым аналогом.
Очень похожая техника используется в JsExe для упаковки демок на джаваскрипте
Sign up to leave a comment.
Web Bundle — дело RarJPEG живет