AndersonDunai 26 дек 2013 в 21:53

Portable Network Javascript

3 мин

34K

Ненормальное программирование*Веб-разработка*Обработка изображений*

Из песочницы

+72

Комментарии 34

cyberface 26 дек 2013 в 22:16

Из графиков не понятна целесообразность — судя по графику JQuery в PNG занимает что-то межу 50 и 60 КБ, а gzip судя по closure-compiler.appspot.com/home должен занимать 32КБ

AndersonDunai 26 дек 2013 в 22:31

Спасибо за отзыв! Я этот момент не учёл. А цифры действительно забыл добавить в статью, как только попаду домой — сразу отредактирую статью.

aplic 26 дек 2013 в 22:25

Забавно, поучительно. Зануда mode on: практически все js, css и html и другие легко сжимаемые файлы отдаются с сервера уже сжатыми. То есть в настоящий момент нет необходимости даже минифицировать js и css, достаточно только комментарии вырезать. Даже не могу сообразить где ваш код пригодился бы.

AndersonDunai 26 дек 2013 в 22:32

Согласен. Годится, по большому счету, лишь для забавы.

bytecode_rus 27 дек 2013 в 08:33

Я бы написал об этом в статье, потому что мне показалось, что описанный в статье метод предлагается как решение проблемы сжатия скриптов.
Очевидно, что он не самый лучший, ведь есть gzip, который:
— поддерживается всеми браузерами
— поддерживается всеми серверами
— лучше сжимает

А идея сама очень прикольная, респект

white_mage 27 дек 2013 в 10:02

Если хочется совсем уж адского сжатия, то таки минифицировать желательно. Удаляются лишние пробелы, переводы строк и прочие штуки.

deepsweet 26 дек 2013 в 22:29

просто для истории :) – Compression using Canvas and PNG-embedded data, May 4, 2008

xxxTy3uKxxx 26 дек 2013 в 22:32

Я, грубо говоря, изобрёл велосипед

aplic 26 дек 2013 в 22:36

pro100hikka98 27 дек 2013 в 00:21

Заместо прочтения статьи играл в марио.

sunnybear 27 дек 2013 в 14:55

да-да, здесь и перевод :)
webo.in/articles/habrahabr/47-compression-using-canvas/

bask 26 дек 2013 в 22:43

Напомнило habrahabr.ru/post/151538/

Alexey2005 26 дек 2013 в 23:13

Когда реализовывал такую систему (вынужденно, т.к. требовалось залить интерактивный рассказ на Самиздат, а засунуть туда JS можно только через img-эксплойт), столкнулся с её ненадёжностью.
Во-первых, картинки частенько не прогружаются или прогружаются не полностью, особенно на мобильных устройствах с хреновым GPRS. Поэтому пришлось к изображению добавить контрольный столбец — самый правый столбик у меня содержал только синие (0,0,255) пиксели. Тогда перед декодированием можно проверить, прогрузилась ли картинка до конца или браузер срезал половину.
Во-вторых, браузеры на движке WebKit отличаются редкостной параноидальностью, и когда пользователь сохраняет страничку, то JS запущенной локальной копии не имеет доступа к данным канваса (кто только придумал такое ограничение?).
Наконец, оказалось, что слишком большие (>5Мб) картинки в процессе декодирования крашат Firefox for Android, причём он не просто падает, а уводит весь девайс в перезагрузку.

trueClearThinker 27 дек 2013 в 11:07

Кстати, был опыт с Opera Turbo? Подозреваю, что пережатые картинки работать не будут вообще :)

Grox 27 дек 2013 в 16:54

Opera Turbo пережимает только jpg изображения, png, gif остаются без пережатия, так было.

burjui 27 дек 2013 в 17:57

Сделал в Gimp PNG'шку размером 2000x2000 и объёмом 7.8 МБайт с RGB-шумом, попробовал открыть на Nexus 7 с Android 4.3:

Firefox 26.0.1: открыл, можно смотреть, масштабировать, полёт нормальный
Chrome 31.0.1650.59: упал

Разумеется, это ни о чём не говорит, просто интересный факт.

printf 27 дек 2013 в 03:49

Да-да-да, я то же самое однажды сделал, но на Хабр поленился запостить.
Ссылка: animuchan.net/sukijs/ (см. исходники)

bolk 27 дек 2013 в 09:13

Было уже: habrahabr.ru/post/102394/ и habrahabr.ru/post/31607/

Техника старая, обсосанная не раз. Используйте браузерный gzip и не парьтесь.

marapper 27 дек 2013 в 14:36

Кстати, Касперский может резать большой json, приходящий аяксом (что-то около 3 мегабайт). Причем режет по длине текста, т.к. приходит на самом деле 700-килобайтный gzip. Можно извратиться с мапами, а можно и попробовать скомпрессить так.

bolk 27 дек 2013 в 14:57

Можно попробовать выкинул Касперский и не покупать его никогда, если он это действительно делает.

marapper 27 дек 2013 в 18:11

Это сродни «давайте побивать камнями пользователей с 6 ослом/старой оперой/любителей на палмах»

bolk 27 дек 2013 в 20:43

Нет, это как покарать производителя за плохой продукт.

Old_Chroft 27 дек 2013 в 09:21

Парень, ты ненормальный. В хорошем смысле слова :) Именно такие и двигаю прогресс в программировании.

Gerh 27 дек 2013 в 09:50

А что на счет использования данного способа для обфускации js? Столкнулся недавно с этой проблемой и кроме как closure и обфускаторы вида !([]+[])+[], которые увеличивают длину кода в 100500 раз и прекрасно деобфусцируются одним нажатием кнопки, ничего не нашел.

bolk 27 дек 2013 в 14:57

С обфускацией тут ничего. Это не обфускация.

Mushtat 27 дек 2013 в 12:37

Если я не ошибаюсь — в один пиксель можно загнать четыре байта? Альфа канал же ещё…

haxecoder 27 дек 2013 в 13:34

Всё верно, ARGB, по байту на канал. Жаль, что в статье не описано почему именно 3 байта берётся.

bolk 27 дек 2013 в 14:58

Сжимается плохо, да и альфа полбайта только, если не ошибаюсь.

Alexey2005 27 дек 2013 в 15:30

Нельзя. К сожалению, canvas по-идиотски работает с альфа-каналом — в буфере хранятся не истинные цвета, а умноженные на значение альфа. В момент считывания браузер пытается восстановить их делением на альфа, что невозможно без потерь. Т.е. при считывании данных с канваса получим искажение цветов, если есть альфа-канал с переменными значениями.

bolk 27 дек 2013 в 16:36

Что-то я такого не наблюдал. Возвращаются все 4 компоненты из канваса. В псевдомассиве data данные лежат как RGBA.

Alexey2005 27 дек 2013 в 17:31

Данные возвращаются, но с потерей точности, т.е. эти RGBA будут немного (незаметно для глаза) отличаться от исходных.
Попробуйте закодировать текст в RGBA, засунуть этот массив в канвас, а потом сразу же снова считать и декодировать. При этом значительная часть символов заменяется «мусором» в результате потери точности.