nicht angemeldet
Komprimierung von HTML-Dateien
Hi Forum,
da mein Provider (Strato) nicht in der Lage ist, ein Speicherplatzproblem individuell kulant zu lösen, suche ich nach einer Möglichkeit meine HTML-Files möglichst klein zu bekommen.
Ein Script zum Entfernen sämtlicher Zeilenumbrüche und unnötiger Blanks habe ich ja bereits (danke Frank), wenn es interessiert, im Archiv sollte es noch nachzulesen sein.
Nun habe ich die Idee gehabt, dieses Script einzusetzen und danach die entstandene Seite nochmal zu komprimieren, irgendwo habe ich da auch schonmal ein Script o.ä. gesehen, leider weiss ich nicht mehr wo :(
Wer dazu etwas weiss (max. Komprimierung von HTML-Files per JavaScript), der kann es gern mal posten, ich bräuchte es dringend *g*
viele gruesse, stefan
PS: U.a. um folgende Seite geht es: [view-source:http://www.favicon.de/patchwork/patchwork.html], mal schauen ob dieser tolle Link wirklich funktioniert :)
-
view-source:http://www.favicon.de/patchwork/patchwork.html
sorry, aber irgendwie muß es ja mal klappen </testgelände>
-
Hallo!
Wer dazu etwas weiss (max. Komprimierung von HTML-Files per JavaScript), der kann es gern mal posten, ich bräuchte es dringend *g*
Ich habe hier vor zwei Wochen mal etwas derartiges vorgestellt. Es ist allerdings nicht auf große Gegenliebe gestoßen, da es tatsächlich mit ein paar Nachteilen verbunden ist (JavaScript notwendig, Wartezeit beim Entpacken, Text wird nicht durch Suchmaschinen gefunden). Deshalb habe ich mich dann auch nicht mehr groß damit beschäftigt. Ich könnte aber zumindest das Tool, mit dem ich die Kompression vorgenommen habe, so wie es ist veröffentlichen. Wie ein damit erzeugtes Komprimat etwa aussieht, kannst du dir hier ansehen (Kompressionsfaktor dort etwa 1:3):
http://steffengerlach.de/htmlcompression/compressed.html
Besser und schneller als ein Universal-Packer ist in jedem Falle eine Speziallösung, die im Falle deines Beispieldokuments auch recht einfach wäre: Eine JavaScript-Schleife erzeugt das Dokument aus einem "Extrakt", der nur die Domains enthält. Etwas anderes würde der Universal-Packer letzendlich auch nicht machen, nur umständlicher.
Eins ist mir allerdings nicht ganz klar: Wie kann eine 32K kleine Datei ein ernsthaftes Speicherplatzproblem darstellen???
Viele Grüße
Steffen-
Hi Steffen,
Ich könnte aber zumindest das Tool, mit dem ich die Kompression vorgenommen habe, so wie es ist veröffentlichen.
Gern, ich wäre daran interessiert, wenn es dann doch nicht Verwendung finden sollte, weiss ich wenigstens, wie es gewesen wäre ... ;)
Besser und schneller als ein Universal-Packer ist in jedem Falle eine Speziallösung, die im Falle deines Beispieldokuments auch recht einfach wäre: Eine JavaScript-Schleife erzeugt das Dokument aus einem "Extrakt", der nur die Domains enthält.
Stimmt einerseits (nur leider werde ich diese Speziallösung imho nicht hinbekommen, zumindest wenn der Komprimieralgorhythmus sehr kompliziert ist), andererseits wäre ich auch so mal daran interessiert (wenn man es mal vereinfacht sieht, hat man damit einen 95%-igen Quelltextschutz ?!).
Eins ist mir allerdings nicht ganz klar: Wie kann eine 32K kleine Datei ein ernsthaftes Speicherplatzproblem darstellen???
Dann surfe mal zu Strato, schaue Dir die Features einer Web-Visitenkarte (1 MB!) an und rechne davon noch die (theoretisch nicht enthaltene aber dennoch erwünschte) Statistik ab, dann weisst Du wieviel 32 KB ausmachen können. Die Datei wird am Ende etwa 80-90 KB gross sein.
viele gruesse, se
ps: bei 1 MB Webspace _inklusive_ Statistik muss man ziemlich genau kalkulieren ... *g*
-
Dann surfe mal zu Strato, schaue Dir die Features einer Web-Visitenkarte (1 MB!) an und rechne davon noch die (theoretisch nicht enthaltene aber dennoch erwünschte) Statistik ab, dann weisst Du wieviel 32 KB ausmachen können. Die Datei wird am Ende etwa 80-90 KB gross sein.
Dann lager doch einfach Dateien wie Grafiken oder so auf einen kostenlosen Webspace-Provider aus. Ich denke Webspace ist heute wirklich nicht mehr das Problem :-)
Viele Gruesse, Thomas Hieck
-
Nun denn. Ich habe das Kompressionstool noch einmal überarbeitet, und ab sofort steht es unter
<http//steffengerlach.de/freeware/hc.zip>
zum Download bereit. (Windows-Version, Freeware, 137K) Die Funktionsweise ist ganz einfach: Zeichenketten werden bei wiederholtem Vorkommen nicht wiederholt, sondern es wird nur noch auf das erste Auftreten verwiesen. Beim Entpacken werden die referenzierten Zeichenketten dann wieder komplett eingefügt. Der Kompressionseffekt hängt natürlich stark von der Art des Dokuments ab.
Wo der größte Nachteil liegt merkst du, wenn du die eine derart komprimierte Seite aufrufst - dann ist nämlich erstmal Warten angesagt, wobei Netscape hier den Vogel abschießt. (Ich habe auch schon an anderer Stelle feststellen müssen, daß die NS-JavaScript-Implementierung wesentlich langsamer ist als die von MS.)
Aber bei deiner Seite scheint das Ganze sowieso nicht zu funktionieren. :-( Das Dokument wird zwar komprimiert (auf 8.6K) und korrekt entpackt, aber irgendwie falsch angezeigt. Bei Netscape fehlt der untere Bereich, beim IE der ganz rechte. Daß der Text korrekt entpackt wird weiß ich, weil der MSIE - im Gegensatz zu Netzscape - den Seitenquelltext NACH der Dekompression anzeigt. ( --- Den 95%-igen Quelltextschutz können wir also vergessen, den gab es nur bei einer früheren Variante, wo ich zum Schreiben noch innerHTML statt document.write verwendet habe. Da brauchte man schon einen Java- oder C-Compiler, um am den Klartext zu kommen. --- ) Wenn ich den entpackten Quelltext als HTML speichere und dann im Browser öffne, kommt die Seite dann so, wie es sein soll. Irgendwie machen die Browser also bei document.write nicht genau dasselbe wie beim Öffnen einer Datei - zumindest nicht im Falle deiner Seite, bei meiner eigenen Testseite gab es keine Probleme.
Ich muß hier noch anfügen, daß ich nicht gerade ein JavaScript-Experte bin. Ich programmiere zwar schon eine ganze Weile, mit JS aber erst seit ein paar Wochen. Wenn sich jemand einigermaßen gut mit JS auskennt, könnte er vielleicht den Algorithmus wesentlich beschleunigen. Vielleicht sind die Möglichkeiten zur String-Manipulation doch nicht so begrenzt, wie es mir erscheint. Der größte Knackpunkt ist aber, den entpackten Text ins Dokument zu bekommen. document.write scheint nicht so optimal zu sein, und was ich vorher ausprobiert hatte, war noch schlimmer.
Nochmal zu den 32K: Wenn der Platz unter favicon.de wirklich so knapp ist, warum lagerst du nicht ein paar Dateien (z.B. Inline-Bilder, falls dort welche sind) anderswohin aus?
Steffen
-
-
-
Hallo Stefan,
nun steht weiter unten, das Du leider nur die 1Mb Weiterleitung hast, aber eine Alternative, ein cgi-bin ist natürlich Voraussetzung wäre:http://metalab.unc.edu/pub/Linux/apps/www/misc/zcat-cgi.tar.gz
ein kleines Tool (kompr 1897 Bytes) um mittels gzip on the fly zu dekomprimieren. Das Problem ist hierbei, daß bereits Serverseitig dekomprimiert wird, gespart wird also "nur" Serverplattenplatz, der aber auch schon teuer genug ist, gebraucht wird noch zcat, ist eigentlich Standard auf Unix Systemen. Falls irgend jemand damit schon Erfahrung hat, wäre eine kleine Notiz nett.
Grüße
Christoph
PS:
Warum gibt es eigentlich bis heute kein ziptool bei Windoofs von Haus aus, jeder Sch... ist dabei, blos nichts vernünftiges <grmbl> ;-)
CZ