Пакуем JS и CSS в png

Jacob Seidelin http://blog.nihilogic.dk/2008/05/compression-using-canvas-and-png.html опубликовал интересную идею — паковать JS код в изображения PNG и распаковывать их обратно при выполнении. При этом происходит сжатие кода, и появляется необычная возможность реализации интеллектуальных систем восстановления изображений исключительно на языке растров. Указывая пространственное положение очередного изображения-кода, мы можем формировать очень интересные структурированные по принципу нарезки (tiling) библиотеки практически неограниченного размера, высоко оптимизированные по трафику и времени доступа к конкретному участку кода.





Список его примеров выглядит весьма интересным

prototype-1.6.0.2.js
123 KB Javascript compressed to 30 KB PNG (24%)

jquery-1.2.3.min.js
53 KB Javascript compressed to 17 KB PNG (32%)

excanvas.js
24 KB Javascript compressed to 8 KB PNG (33%)

excanvas-compressed.js
10 KB Javascript compressed to 5 KB PNG (50%)

dijit.js
46 KB Javascript compressed to 16 KB PNG (35%)

Кому интересно, вот еще ссылочка на публикацию и обсуждение этой темы
ajaxian.com/archives/want-to-pack-js-and-css-really-well-convert-it-to-a-png-and-unpack-it-via-canvas?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+ajaxian+(Ajaxian+Blog)

UPD:
Существует перевод статьи
webo.in/articles/habrahabr/47-compression-using-canvas/
Перевод: Мациевский Николай aka sunnybear sunnybear.habrahabr.ru/
Опубликована: 16 июня 2008
Ссылка на Хабре habrahabr.ru/blogs/javascript/33841/
+88
23 августа 2010, 02:34
147
Valery35 30,3

комментарии (99)

+4
VolCh #
Оригинально, но практический смысл не понял
0
kostin #
Экономия трафика, ускорение загрузки, не?
+30
VolCh #
Стандартное сжатие сервером настолько плохо сжимает, что есть смысл заморачиваться с распаковкой на стороне клиента?
–6
kostin #
Вы про gzip? Не знаю, кто из них жмёт лучше, но gzip не всегда и не везде можно включить. Этот метод вряд ли лучше, но какой-то практический толк он таки имеет.
+4
r13 #
А почему не всегда и не везде?
НЛО прилетело и опубликовало эту надпись здесь
+15
TheShock #
например, на конкурсе «Javascript весом не больше 10к» гзип не прокатывает, а пнг — прокатывает)
+11
VasilioRuzanni #
Это исключение в стиле «for fun», а не реальные production-условия.
–4
TheShock #
тем не менее, такие примеры есть.
факт описанный в топике должен знать каждый жс-кодер.
с другой стороны непонятно, зачем постоянно повторять одну и ту же статью
+3
DIDJER #
Скажем так, этот пример — частный случай, поэтому предлагаю рассматривать его в частном порядке, вы так не думаете?
+3
FractalizeR #
Думаю, такое PNG там тоже скоро запретят.
0
divanikus #
Иногда админ хостинга не дает включать, де сервер грузит. Может и бред, но когда другого выбора нет (например закрытая площадка провайдера), приходиться с этим жить.
0
freeAKK #
Сжать руками, положить rewrite-правило в .htaccess?
0
divanikus #
Я же говорю, админ не дает включать — т.е. выключит сам :). Просто примите это как данность.
0
divanikus #
Тьфу, у меня лишь серверная в голове. Со скриптами-то да, такой подход прокатит. А вот динамическая генерация уже гораздо сложнее.
0
divanikus #
*серверная сторона
+1
adnull #
А не надо динамическую генерацию gzip-а делать. За это любой вменяемый админ руки оторвет, т.к. нагрузка на сервер будет дай боже.
0
roboter #
не при каждом же запросе!
0
adnull #
Умудряются при каждом! :)
Включая «умные» CMS, у которых это по дефолту включено.
+1
roboter #
ну тогда если вернуться к сути топика, то можно умудриться и картинку с js при каждом запросе генерить.
+2
VolCh #
Когда трафик дороже CPU это оправдано. Или если канал узкое место (что часто бывает).

Вообще по хорошему надо собирать статистику на конкретном проекте, железе и тарифе хостера и стараться, чтобы клиент получил полный ответ как можно быстрее (временем распаковки на клиенте можно пренебречь, а можно нет :) ), если дополнительных расходов для вас это не вызывает или они приемлемы.
0
adnull #
Для виртуального хостинга в 90% случаев такое точно неприемлимо — там как раз CPU сильно дороже трафика и диска. За всех не скажу, как вы правильно заметили, есть много «но». Но, как правило, админы предпочитают сразу срезать даже возможность перегруза по этому параметру. Что, естественно, не устраняет перегрузов по другим параметрам (например ErrorDocument 404 / :)
0
VolCh #
Я больше ориентируюсь на VPS/VDS, где процессор тебе выделяют по потребностям (небесплатно, конечно), а вот канал, видимо, фиксированный на физический сервер и его загрузка зависит от соседей, даже в пределах датацентра
0
andoriyu #
а, что отдавать уже сжатое не камильфо? уйти на нормальный сервер денег нет?
0
divanikus #
Нормальный сервер во внутренней сети провайдера? Только если свой поставить…
0
andoriyu #
А зачем в пиринге вообще что-то сжимать? И еще важнее — зачем, что-то хостить у провайдера?
0
taliban #
А пнг кодирование не грузит совсем сервер? Что-то мне подсказывает что эти алгоритмы на таких обьемах данных будут занимать одинаковые рессурсы сервера
0
klubben #
Так и почему просто вручную гзипом не жать? т.е. зачем пнг-то?
+17
kostin #
Во, а ещё скрипты и стилм на имадж-хостингах хранить теперь можно.
+4
TiGR #
Так себе и представил распределённый сайт для извращенцев…

Индексный файл — на личном компьютере с денвером, все остальные — изображения, стили и js — разбросаны по разным хостингам картинок…
+4
zitter #
Предвижу заголовки — png-червь поражает image-хостинги, и рассылает трояны пользователям…
ну или что-то подобное…
0
D1pa5 #
Хорошая идея!
0
NickMitin #
Имеет, в популярных проектах кластер серверов всегда на порядки меньше количества клиентов.
0
VolCh #
И? Кластеру проще сформировать PNG-картинку, а не gz-файл/поток? А если говорим о формировании файлов для продакшена заранее, то проще, имхо, пользоваться gzip, который прозрачно понимают все нормальные браузеры.
0
NickMitin #
Я протупил, исходя из того, что сжимать в gzip надо на лету. :)
+15
SilentBob #
Идея интересная в теории, но ужасная на практике. Далеко не все клиенты показывают изображение в оригинальном виде. Взять хотя бы Оперу Мобайл или Гугл Ридер Мобайл — оба сервиса работают с изображением как с _изображением_ и могут изменять его размер/качество сжатия в зависимости от соединения. Что произойдет со скриптами, закодированными вовнутрь — неизвестно.

Если уж очень хочется соригинальничать — то где-то рядом ледит статья про JS-powered gzip.
+1
SLIDERWEB #
Во-во, а еще некоторые прокси картинки пережимают, либо вовсе запрещают загрузку изображений, вот веселуха то… Извините, но у меня сайт не отображается. ИМХО метод сомнительный
+3
TiGR #
И это главный комментарий к данной статье.
+1
ssve #
> Что произойдет со скриптами, закодированными вовнутрь — неизвестно

Капец
–1
MikhailEdoshin #
Возможность точечной загрузки только нужных функций через HTTP Range.
+1
MikhailEdoshin #
Хотя я не знаю алгоритма сжатия PNG, не факт, что там можно так просто загрузить кусочек.
0
bondbig #
deflate, насколько я помню.
+2
kurokikaze #
Что мешает запросить с HTTP Range обычный Javascript?
0
MikhailEdoshin #
Логично.
+5
ilyaProphet #
не давно на хабре ребята рассказывали о своей игрушке
+3
seregagl #
Мне кажется не нужно искать практического смысла в блоге «ненормальное программирование»
+1
VolCh #
Когда я размещал коммент, пост был в «веб разработке» кажется
0
Valery35 #
Да, позднее я его переместил в более подходящий блог
0
niksmile #
Первое, что приходит на ум — вирус.
Кто мешает загрузить сначала «безобидный» скрипт, которые просто читает эти самые «рисунки», а потом просто давать команды на выполнение через эти же «рисунки»?
0
fruit #
Ничего нового для вирусописателей в этом конкретном случает нет.

Стеганография и обфускация используются давным-давно. Если же с помощью JS каким-то образом удалось скомпрометировать целевую систему через браузер, то уже не важно каким образом будет доставляться вредоносный код.

Сам метод просто любопытен, так как ранее с помощью Javascript реализовать такое решение было крайне затруднительно, и, фактически, это было бессмысленным. Появление встроенного метода getImageData() изменило ситуацию.
+13
sunnybear #
ы?
habrahabr.ru/blogs/client_side_optimization/27207/
webo.in/articles/habrahabr/47-compression-using-canvas/

вроде даже в книжки включал. Но уже точно не помню
0
Valery35 #
Спасибо, ваши публикации мимо пробежали, не заметил.
Статьи немного разными получились, поэтому оставил. Добавил ссылки.
0
kostin #
Остроумный ответ любителям псевдографики и ASCII-арта?
+2
kurokikaze #
Угу. Они изображения делают в тексте — а мы текст в изображении. Touché.
+1
amarao #
А почему бы это делать не в PNG а в самом что ни на есть законном bz2? Скрипт подкачивает bz2 файл, наверняка если не bz2, то хотя бы gz все браузеры умеют. Распаковывает, юзает.

И если мне память не изменяет, gzcompressed чуть ли не в спеках http предусмотрено.
+1
equand #
bunzip можно реализовать в javascript теоритически :)
+3
amarao #
Мне кажется, что реализация любого рода «heavy-duty» кода на интерпретируемом языке — неуважение к пользователю. Ради небольшой копеечки экономии трафика взять, например, и сожрать у человека батарейку в два раза больше — это свинство.
+3
equand #
Для файлов такого размера это будет «незаметно» для батареек компьютера. Жаль забросил свой код архиватора на Питоне, как раз изучал внутренности BZIP.
0
amarao #
Почему незаметно? Две секунды загрузки процессора на 100% на арме — это вполне себе неприятный кусок из батарейки.
+2
amarao #
да, кстати, ещё один аргумент: если архиватор на JS имеет смысл, то он должен распаковывать код, который в размере больше самого архиватора (так, чтобы загрузка архиватора и сжатого кода была меньше развёртнутого кода). А это будет не такой уж маленький размер (а значит, нагрузка на процессор).
+4
SKYnv #
этой идее в обед — сто лет.
+3
SKYnv #
и собственно ссылка на эту же статью на хабре имеется в конце статьи. рекурсия?
+15
nekt #
Не труЪ.

Давайте лучше жать скрипты в аудиофайлы. Так будет интереснее.
0
maseal #
Захотелось послушать мелодии а-ля модем? Я их ещё лет 15 назад наслушался :)
НЛО прилетело и опубликовало эту надпись здесь
0
Untit1ed #
тогда уж sql-injectionы лучше при помощи битбокса)
+4
Myp #
cat script.js > /dev/dsp
0
fruit #
Идея не нова: см. спектрум, магнитофонные кассеты :)
+10
sectus #
Это полный бред.

PNG использует Deflate и gzip использует его же. Что мешает просто gzip-овать, а не рендерить рисунок, а потом его распарсивать?
+1
MihallicA #
Не только его, еще фильтры всякие
НЛО прилетело и опубликовало эту надпись здесь
–3
yul #
сделаем js еще тормознее?
–1
UrbanRider #
habrahabr.ru/blogs/web_2_0/102394/#comment_3180046

Посмотрите данный комментарий, пройдите по ссылке. Почитайте про игру, а потом поиграйте в нее…

Тормозов не наблюдается что-то.

JS делается тормознутым не из-за плохой идеи, а из-за криворукого программиста. (ИМХО)
–3
yul #
Сравните с компилируемыми играми.
–3
yul #
*компилированными
0
lol2Fast4U #
Из-за криворуких разработчиков брузеров ;)
В V8 (Chrome) летают даже поделия самых криворуких разработчиков.
0
noRerih #
Имхо, в комменте из статьи от 5-го мая 2008 года, приведённой в конце этого топика, многое детально расписано.
+3
sectus #
А можно мне ещё разъяснить мне связь тэга «web 2.0» и темой данной статьи.
+1
Valery35 #
Перенес в «ненормальное программирование» и JS
Основной интерес, пожалуй, в оригинальности идеи.
Практическая ценность не столь велика.
0
sectus #
Это мудрое решение.
–1
lehha #
Боян, как бэ.

Из оргиринала все давно поняли, что в современных мегабитных каналах скорость загрузки ничтожно мала по сравнению с декодированием подобных картинок. У кого FF не подвисает?
+6
SunexDevelopment #
Хм, так ведь тот парень с ВикиЛеакс теперь может беспалевно хранить статьи прямо на Фликре безо всяких там ухищрений
+18
ehvadimka #
Что-то мне кажется, что скоро будет переосмысление картин леонардо да винчи.
Там найдут Javascript код
+2
digi #
Самый волнующий вопрос в этой технологии — что покажет картинка? — вызывает разочарование.
Телевизионные помехи, да и только.
+2
SCINER #
Картинки должны быть картинками, скрипты скриптами!
А что если админ сети или юзер компа отключили показ картинок?
А что если юзается Opera Turbo?
0
z123 #
не вижу практического смысла
0
standov #
я так понял основная мысль данного метода «как-то еще заюзать canvas» и все, в принципе если браузеры смогут например работать с canvas силами видеокарт, т.е. в частности deflate в таком режиме будет реализован на ней то… в общем полет фантазии далеко может увлечь
+1
s0rr0w #
Круто, можно будет проводить кибератаки на сайт с таким методом упаковки. Достаточно подсунуть свой URL с картинкой…
0
andan #
Про эксплойты которые будут основаны на данном методе еще мы услышим.
+2
VolCh #
… и обеспечить распаковку и выполнение кода в клиенте ;)
+2
isafdar #
На том сайте меня больше всего заинтересовала возможность поиграть в Марио!
+2
artifex #
Этот метод скрывает от пользователя исходный код js и css, что может быть опасным с точки зрения безопасности и идеологически неправильно с точки зрения открытых технологий (не за это мы боролись). Сама же идея довольно старая. Если мы её всё ещё не наблюдаем в повседневной жизни, значит она оказалась нахрен никому не нужна.
+1
darkfrei #


А подобный код не несет в себе угрозы?
+1
pietrovich #
бедный-бедный Noscript, теперь он будет банить не только скрипты но и картинки.
бедные-бедные антивирусы, теперь в http-трафике им придется сканить картинки.
бедные-бедные мы, весь этот бардак будет исполняться на наших машинах.

+2
Captcha #
А верхом мастерства будет считаться глядя на изображение, находить ошибки в коде =)
+1
MaxL #
— Оу, тут у тебя тег не закрыт.
— точно, сейчас в фотошопе подправлю!
:-)
0
eremin #
извините, а «баян» уже говорили? :)
0
jblo #
#d5d3c9! =)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.