ugrás a tartalomhoz

JavaScript kód tárolása PNG-ben

Török Gábor · 2008. Május. 5. (H), 11.26
Eredetileg csak blogmarkként gondoltam hivatkozni Jacob Sedelin elképesztő ötletére, de nem bírtam megállni, hogy ne mutassam be néhány szó erejéig ezt a kísérleti fogást. Az erősen a JavaScriptre támaszkodó felületek kiszolgáló és ügyfél közötti adatátvitel csökkentése érdekében több megoldás is alkalmazható, ezek tárházát bővíti az alábbi elgondolás. Jacob a szerzője JavaScript alapú Super Mariónak, ott vetette először be ezt a kódtömörítésen alapuló technikát.

Az ötlet lényege, hogy a JavaScript kódot – példának okáért vegyük a Jacob által említett Prototype kódtárat – képbe ágyazva küldjük le a kliensnek. A használt képformátum lehetőleg legyen veszteségmentesen tömöríthető, erre a célra a szerző a 8 bites PNG formátumot találta az ideálisnak. A kép előállítása során az egyes képpontokat a JS kód karaktereinek ASCII értéke határozza meg. A kreált képet a böngészőben betöltjük egy canvas elembe, a pixeleket visszaolvassuk, a kapott sztringet pedig kiértékeljük.

Prototype kódtár PNG-be ágyazva


A Prototype függvénytár esetében (prototype-1.6.0.2.js) az eredeti 123 KB-os méret PNG-ként tárolva annak csupán 24%-a, mintegy 30 KB. Érdekességképpen a korábban már bemutatott YUI Compressor (obfuszkálással együtt) gzippelve ugyanezt a kódmennyiséget 22 KB-ra tömörítette.

Az elgondolásnak több sebezhető pontja is van. Egyrészt a megoldás alkalmazhatósága a canvas elem miatt leszűkül az azt támogató motorok körére, másfelől nagyobb kódtárak esetén a kép kirajzolása és beolvasása a kliensre jelentős terhelést dobhat, így inkább csak gondolatébresztő Jacob írása, mint élesen bevethető technika.
 ■
1

Hány százaléka?

vbence · 2008. Május. 5. (H), 11.37
Nem volt túl szerencsés a két tömörítés összehasolításánál először százalékban, majd tényleges méretben megadni a hatékonyságot. Ezért lehet, hogy rosszul értem, de a 123K 24%-a 29,52K aminél a 22K jobb. (méghozzá 34%-kal ;)
3

22K obfuszkált, gzippelt kód

Török Gábor · 2008. Május. 5. (H), 11.52
Minden stimmel, de valóban szerencsétlenül fogalmaztam. A 22K egyértelműen jobb teljesítmény, pontosítottam a bejegyzésben, köszönöm az észrevételt.
2

Az ötlet nem új...

presidento · 2008. Május. 5. (H), 11.51
A 2003-ban megrendezett Web Konferencia 5k Compo-jára érkezett hasonló elgondolású "műalkotás" :), igaz, ott PHP volt az értelmező nyelv.

http://www.phpconf.hu/2003/5kcompo.php/Gorcso/csongor
4

Szteganográfia

Jano · 2008. Május. 5. (H), 20.04
Viccesebb lett volna, ha egy rendes képbe ültette volna be szteganográfiás eljárással :)
5

[Off]

Gixx · 2008. Május. 6. (K), 09.55
vajon a TV-ben milyen JS kód fut, amikor elmegy az adás? :)
6

[off] - nem kód :-)

Max Logan · 2008. Május. 6. (K), 10.44
Az nem JS kód, hanem a világűrből érkező sugarak által létrehozott "adás".
7

szintén off

gex · 2008. Május. 6. (K), 11.02
vagy esetleg a híres festményekben (azok digitalizált képében) milyen pöpec framework-ök bújkálhatnak. ;)
8

GZIP?

saxus · 2008. Május. 8. (Cs), 14.30
És most miért jó ez? PNG gyakorlatilag egy gzip stream-l tömörített bitmap. Most miért jó az, hogy az user gépét megdobjuk egy jó erős képfeldolgozással (így is elég lassúak tudnak lenni egy modern gépen a sok JS-t tartalmazó oldalak), minthogy szimplán egy gzip-l tömörített .js fájlt adunk neki oda, ami már év(tizedek?) óta támogatott az összes mainstream böngészőben, gyakorlatilag transzparens módon a látogató számára.

Megint feltaláljuk a spanyolviaszt, csak egy sokkal bonyolultabb módszerrel...
9

letöltés

vbence · 2008. Május. 8. (Cs), 15.41
Egy picit más aböngészők viselkedése aképekkel, és a JS sájlokkal. A JS letöltésekor az oldal renderelése megáll a szkript előtt, és nem is folytatódik, amég az nincs letöltve, feldolgozva és futtatva. A képek pedig aszinkron módon töltődnek (persze a böngésző limitációit figyelembe véve).

Ahogy a postban is van, nem cél a gzip kiváltása, csupán egy érdekes eszközt mutat be, amiről tudni nem árt...
10

Mire a felháborodás?

Joó Ádám · 2008. Május. 8. (Cs), 15.42
El is olvastad a hivatkozott bejegyzést, vagy csak ugrasz? Egyrészt, leírja, hogy voltak a gzip-nél jobb eredmények, másrészt hangsúlyozza, hogy (épp a feldolgozás költségessége miatt) pillanatnyilag a dolog nem több, mint játék.
12

Nem felháborodás

saxus · 2008. Május. 8. (Cs), 20.13
Igen, elolvastam, nem felháborodásból írtam, csak szerintem sem több, mint egy játékszer.

Azt meg nem láttam, hol írta, hogy kissebb, lenne, mint a gzip-nél jobb eredmények (lehet az én figyelmem kerülte el), viszont azt láttam, hogy van más is, aki úgy gondolja, hogy vicces, de haszna nincs és még rosszabb is.

Sajnálom, hogy probléma az, hogy nem látok fantáziát a dologban sem most, sem a jövőben. A javascript egy lassú nyelv, képfeldolgozás szintén nem egy gyors dolog. Ha a kettőt egyesíteni próbáljuk abból csak egy még lassabb valami jön ki. És akárhova is fognak gyorsulni a processzorok, nem úgy tűnik, hogy ez jelentősen változna a jövőben.

Ennek tükrében nem értem a nagy felhajtást körülötte, mert az eredeti célját (gyorsabb oldalletöltés) nagyon nem teljesíti. Hiába érdekes, ha gyakorlati haszna nincs.
13

Mea culpa

Joó Ádám · 2008. Május. 8. (Cs), 20.21
Igazad van, én emlékeztem rosszul, a tömörítéssel volt csak összevetve.
Szerintem senki sem gondolja, hogy ezzel bármit is lehet kezdeni, egyszerűen csak ötletes és vicces megoldás.
11

tetszik

akos.tajti · 2008. Május. 8. (Cs), 19.44
érdekes ötlet. a szteganográfiát mindig szerettem, és ez hasonló valami, csak más a motiváció. kíváncsi vagyok, mit hoznak még ki belőle.