DE10142024A1

DE10142024A1 - Kompressionsverfahren

Info

Publication number: DE10142024A1
Application number: DE2001142024
Authority: DE
Inventors: Arnd Schuette
Original assignee: Individual
Current assignee: Individual
Priority date: 2001-08-28
Filing date: 2001-08-28
Publication date: 2003-03-27

Abstract

Die Erfindung betrifft ein Verfahren zur Kompression von HTML/XHTML-Inhalten, wobei die auf einem Server (2) angelegten HTML/XHTML-Dateien und deren Struktur in Form komprimierter Strings in Element-Arrays (12, 12'), Rendering-Arrays (13) und Tree-Arrays (14) in Verbindung mit einem in einer ECMA-Script-Sprache kodierten Dekompressionstool (15) vorzugsweise in JAVA-Scrip abgelegt werden. Beim Bezug der HTML/XHTML-Seiten mittels eines Demands (5) von einem Client (1) wird in Verbindung mit der HTML/XHTML-Response (6) mit dem Dekompressionstool (15) mit übermittelt und mittels eines herkömmlichen Browsers abgearbeitet. Dabei werden die HTML/XHTML-Seiten in Echtzeit auf Clientseite wieder aufgebaut.

Description

Die Erfindung betrifft ein Kompressionsverfahren für HTML/XHTML-Dateien.

Im Zusammenhang mit der weltumspannenden Bedeutung des Internets und hierbei insbesondere des Word-Wide-Webs hat die Verbreitung von HTML-Seiten, in der sogenannten Hypertext- Markup-Language (HTML) eine derart herausragende Bedeutung gewonnen, daß inzwischen HTML-Dateien zum erleichterten Austausch über das Internet zunehmend auch Eintritt in Intranets finden bzw. bestehende Dateien, wie etwa herkömmliche Textdateien mittels entsprechender Programme in HTML- Dateien überführt werden können um diese über das Internet austauschen bzw. dort sichtbar machen zu können. Hinter dem Akronym HTML verbirgt sich die Bezeichnung eine softwareunabhängige Dokument-Beschreibungssprache. Mit Hilfe dieser Sprache können die Inhalte von Dokumenten mittels einfacher Befehlen im Textformat umschrieben werden. Die herausragende Fähigkeit nach HTML liegt in der Möglichkeit Verweise zu anderen Projekten in Form von Hyperlinks oder Links zu anderen Projekten, insbesondere im World-Wide-Web zu erstellen. HTML-Dokumente können, wenn auch ggf. in unterschiedlicher Form auf jedem Rechner der Welt gelesen werden, auf dem ein Browser installiert ist. Die letzte aktuelle HTML- Spezifikation liegt in der Version 4.01 vor. Der designierte Nachfolger von HTML dürfte XHTML sein, der eine bessere Portierbarkeit bereitstellt, um der zunehmenden Verbreitung von HTML außerhalb der Browserwelt Rechnung zu tragen. XHTML ist ebenso wie HTML XML-konform und kann daher mit XML-Editoren bearbeitet werden.

In Verbindung mit der geradezu explosionsartigen Ausweitung des Internets und der metastasenartigen Vernetzung bisher nicht verknüpfter Rechnernetze scheinen eine Reihe von Grundprinzipien der elektronischen Datenverarbeitung vorübergehend außer Acht gelassen worden zu sein, wie etwa geordnete und wohl strukturierte Ablage von Dateien und Daten schon immer unverzichtbare Voraussetzung für einen schnellen und geordneten Zugriff auf Dateien und Daten sowie für eine effiziente elektronische Datenverarbeitung.

Eine derart geordnete Anordnung von HTML-Dateien ist insbesondere auf Webservern in den meisten Fällen nicht vorhanden. Aufgrund der Eindeutigkeit der Adressierung von HTML- Dateien ist weitgehend darauf verzichtet worden, diese strukturiert oder gar komprimiert auf den entsprechenden Server anzulegen. Ein verschwenderischer Umgang mit Speicherplatz, aber auch lange Übertragungs- und Zugriffszeiten sind die nachteilige Folge dieser Datenstrukturen.

Es existieren selbstverständlich auch für HTML-Dateien geordnete Datenbankstrukturen und Kompressionsverfahren. Der Vorteil der Softwareunabhängigkeit der durch die Verwendung von HTML/XHTML erreicht wurde, wird hierbei jedoch regelmäßig aufgegeben, da zur Dekompression bzw. zur Interpretation der erzeugten Dateien die hierzu jeweils verwendete Softwareplattform benötigt wird. Als Beispiel hierfür seien die in der Windows-Welt bekannten Zip-Verfahren erwähnt.

Der Erfindung liegt die Aufgabe zugrunde, softwareunabhängig eine verbesserte und komprimierte Datenstruktur serverseitig zu erreichen, die dann clientseitig einen schnelleren Zugriff gestattet.

Diese Aufgabe wird durch ein Kompressionsverfahren mit den Merkmalen des Hauptanspruchs gelöst. Vorteilhafte Ausgestaltungen der Erfindung ergeben sich aus den abhängigen Unteransprüchen.

Dadurch, daß die HTML/XHTML-Dateien, vorzugsweise auf einem Server zu komprimierten Strings zusammengefaßt werden, ergibt sich ein geringerer Speicherplatzbedarf und somit kürzere Übertragungszeiten für den Client. Die Dekompression erfolgt dabei mittels eines individuellen Dekompressionscode, der in einer ECMA-Script-Sprache bei der Kompression der HTML oder XHTML-Dateien erzeugt wird. Im Falle des Bezugs der komprimierten Dateien wird der entsprechende Dekompressionscode in der erwähnten Script-Sprache mit übermittelt. Der Vorteil der Verwendung von ECMA-Script- Sprachen ist deren Portal- und Softwareunabhängigkeit. Hierunter ist zu verstehen, daß ebenso wie die HTML/XHTML- Dateien auch der Dekompressionscode auf jedem Rechner lauffähig ist, der über einen Browser verfügt. Nachdem der Browser jedoch Voraussetzung für den Bezug der HTML/XHTML- Dateien ist, stellt dies keinerlei Einschränkung dar.

Dadurch, daß der Dekompressions-Algorhithmus im Falle des Bezug der HTML-Dateien oder XHTML-Dateien mit an den Client übermittelt wird, entfällt für diesen die Notwendigkeit, irgendeine Software vorzuhalten. Für den Client stellt sich der Bezug der komprimierten Dateien völlig unverändert zum Bezug herkömmlicher HTML-Dateien dar, da die Kompression und Dekompression der Dateien im Verborgenen für ihn kaum merklich stattfindet. Die infolge der Dekompression bezogenen HTML/XHTML-Dateien bauen sich analog zu dem herkömmlichen Bezug über das HTTP-Protokoll auf.

Dabei wird der Dekompressionscode vorzugsweise als Link in Verbindung mit den komprimierten HTML/XHTML-Dateien übermittelt und im Falle der Dekompression clientseitig aufgerufen.

Die clientseitige Dekompression der bezogenen HTML/XHTML- Dateien erfolgt somit vorzugsweise in realtime direkt beim Aufruf der erwähnten HTML/XHTML-Dateien.

Dabei müssen bei dem Kompressionsverfahren zunächst die vorhandenen HTML/XHTML-Dateien und deren Strukturen gescannt werden. Hierbei werden die Tags, Keys und Values der zu komprimierenden HTML/XHTML-Datei bzw. Dateistruktur erkannt und die hierdurch gewonnene Information zwischengespeichert.

Die hierbei gewonnenen Informationen werden bevorzugt in Vektorform in sogenannten Arrays abgelegt, wobei die erkannten Elemente in Element-Arrays, die Information über die jeweiligen Elementtypen in einem Rendering-Array und die Informationen über die Anordnung oder Reihenfolge der Elemente sowie den Aufbau der Datenstruktur in einem Tree- Array abgelegt werden.

Der erreichbare Kompressionsgrad ist dadurch erhöht, daß die Tags, Values und Keys klassifiziert und eine entsprechende Information zu diesen Elementen jeweils in dem Rendering-Array abegelegt wird.

Einen noch höheren Kompressionsgrad erreicht man durch die Erkennung von Redundanzen in der zu komprimierenden Struktur also von mehrfach verwendeten Elementen, die dann nur einmal in Verbindung mit einer Rendering Information über den Ort Ihrer Verwendung abgespeichert werden.

Um die komprimiert gespeicherten Elemente bei der Dekompression restaurieren zu können, werden diese durch spezielle Trennzeichen voneinander getrennt innerhalb des oder der Element-Arrays angelegt. Hierbei werden mit Vorteil solche Trennzeichen eingesetzt die üblicherweise nicht in HTML/XHTML-Dateien Verwendung finden.

Zur Vermeidung von Kompressionsfehlern ist es dabei sinnvoll in einem weiteren Verfahrensschritt höchstvorsorglich die zu komprimierenden Struktur zunächst dahingehend zu überprüfen, ob nicht doch möglicherweise aufgrund eines Fehlers das ausgewählte Trennzeichen in der urspünglichen Struktur vorhanden ist und dieses zunächst anderweitig zu ersetzen

Die Anzahl der zu erkennenden und verwaltenden Elementtypen muß beschränkt sein, da ansonsten der Kompressionseffekt durch eine umständliche Verwaltung der Elementtypen wieder verschlechtert wird.

Die komprimierten Strings können auch in mehreren Element- Arrays abgelegt sein, so daß zu jedem Element innerhalb des Rendering-Arrays auch eine Information abgelegt werden muß, in welchem Element-Array das jeweilige Element zu finden ist. Die Rendering-Arrays weisen in diesem Falle zu jedem Element eine sogenannte Array-Information auf.

Die eigentliche Datenstruktur der Dateien als solche aber auch deren Bezug zueinander, wird innerhalb eines Tree- Arrays abgelegt. Dabei hat man sich den Tree-Array als eine Folge von Integer-Zahlen, die vorzugsweise in Base 36 kodiert sind, vorzustellen. Bei der Dekompression wird dann dieser Tree-Array sequentiell abgearbeitete. Dabei erfolgt zunächst mittels des Zugriffs auf das Rendering-Arrays eine Bestimmung des Element-Typs und anhand der dort vorhandenen Information über die Adresse des Elementes ein Zugriff auf das Element im Element-Array und schließlich anhand der im Rendering-Array vorgefundenen Informationen über den Element-Typ und dessen nähere Spezifikation eine Überführung ein sogenanntes "Rendering" des komprimierten Elements in das Originalelement, daß an der jeweiligen Stelle wiederhergestellt wird. Durch die sequentielle Abarbeitung des Tree-Arrays wird nach und nach die gesamte HMTL/XHTML-Datei bzw. die gesamte HTML/XHTML-Struktur wieder hergestellt.

Ein erster Kompressionsschritt besteht schon darin, daß auch die Leerzeichen sogenannte "white spaces" in der zu komprimierenden Struktur erkannt und eliminiert werden. Hierdurch ist bereits eine erste Kompression des HTML/XHTML-Codes verwirklicht.

Dadurch, daß die in den HTML/XHTML-Dateien integrierten Script-Sprachen sogenannte "Embedded-Script-Languages" erkannt und verarbeitet werden können, können auch dynamische HTML/XHTML-Dateien komprimiert und verarbeitet werden.

Hierzu werden die eingesetzten Script-Sprachen in der ursprünglichen Form in der komprimierten Struktur erhalten und mit der komprimierten Struktur ggf. an den Client übermittelt und zur Laufzeit bei der Restaurierung auf Clientseite wiederhergestellt. Somit ist auch die dynamische HTML/XHTML-Welt dem erfindungsgemäßen Kompressionsverfahren zugänglich.

Es wird nachstehend anhand eines in der Beschreibung stark vereinfachten Ausführungsbeispiels näher erläutert. Es zeigen:
Fig. 1 eine Client-Server-Beziehung in einem Prinzipschaubild
Fig. 2 einen beispielhaften HTML-Code
Fig. 3 die Dateistruktur eines Webservers
Fig. 4 eine komprimierte Dateistruktur
Fig. 5 ein dem Stand der Technik entsprechendes Kompressionsverfahren in einer Prinzipdarstellung und zum Vergleich
Fig. 6 ein der Erfindung entsprechendes Kompressionsverfahren in einer analogen Prinzipdarstellung
Fig. 1 zeigt in einen Client 1 und einen Server 2, die beide über ein Rechnernetz vorzugsweise das Internet 3 miteinander nach den Regeln eines Übertragungsprotokolls hier dem TCP/IP-Protokoll miteinander in Datenaustausch treten können. Im vorliegenden Beispiel eines Austauschs im World- Wide-Web, also dem WWW, wird man von einem Webclient 1 und einem Webserver 2 gesprochen. Der sogenannte Webclient 1 ist demnach ein an das Internet 3 angeschlossener Computer, der sich über das Internet 3 mit dem Webserver 2 verbindet. Dabei treten die beiden Computer nach einem Protokoll, nämlich HTTP, dem "Hypertext-Transfer-Protokoll" miteinander in Datenaustausch. Hierzu baut der Client 1 zunächst unter Verwendung einer IP-Adresse eine Verbindung mit dem Server 2 im Rahmen des Einloggvorgangs 4 auf.
Der Einloggvorgang 4 ist durch einen Doppelpfeil gekennzeichnet, weil hierbei ein "handshake" zwischen Client 1 und Server 2 stattfindet. Es handelt sich dabei um eine bidirektionale Datenverbindung.
In einem weiteren Schritt im sogenannten Demand 5 fordert der Client 1 ein HTML-File vom Server 2 an. Der Server 2 übermittelt daraufhin mit einer sogenannten HTML-Response 6 die nachgefragte HTML-Datei. Schließlich schließt der Client 1 im Ausloggvorgang 7 die Verbindung zum Server 2.
Eine dabei herkömmlicherweise übermittelte HTML/XHTML-Datei ist in Fig. 2 dargestellt.
Die dabei übermittelten HTML-Dateien - also in der als Hypertext-Markup-Language bezeichneten softwareunabhängigen Dokument-Beschreibungssprache - bestehen im Wesentlichen aus sogenannten Tags 16, die einfache Befehle im Textformat umschreiben, Keys 17 und diesen Keys 17 jeweils zugewiesene Values 18. sowie möglichen Verweise auf andere HTML-Files, die sogenannte Hyperlinks und Links enthalten können. Die HTML-Dateien werden von einem Browser interpretiert und dargestellt.
Dabei sind auf einem Webserver 2 die dort abgelegten HTML- Dateien normalerweise hierarchisch strukturiert. Unter einer hierarchischen Struktur versteht man, daß die Seiten in der Regel durch eine Oberseite eine sogenannte "Homepage 10" adressierbar und von dieser durch Links Unterseiten 11 der Homepage 10 adressierbar bzw. aufrufbar sind. Eine derartige Struktur ist als Prinzipskizze in Fig. 3 dargestellt. Dabei kann die hierarchische Struktur wesentlich komplizierter aufgebaut sein, als in Fig. 3 dargestellt.
In jedem Fall ergibt sich aus der Darstellung in Fig. 2 und 3, daß ein Kompressionsverfahren zur Komprimierung der auf einem Server 2 abgelegten HTML/XHTML-Dateien sowohl die HTML/XHTML-Dateien als solche, wie auch deren Struktur erfassen und komprimieren muß.
Dabei wir im Rahmen der Kompression zunächst ein Scannen des gesamten HTML/XHTML-Inhalts durchgeführt. Bei diesem Scannen werden zunächst die im HTML/XHTML-Code angelegten Tags 16, Keys 17 und Values 18 erkannt und zwischengespeichert.
In einem zweiten Schritt werden die in dem HTML/XHTML-Code enthaltenen Leerzeichen sogenannte white spaces erkannt und eliminiert. Hierdurch ist bereits eine erste Kompression des HTML/XHTML-Inhalts verwirklicht.
In einem weiteren Schritt werden etwa im HTML/XHTML-Code enthaltene Redundanzen also immer wiederkehrende Elemente erkannt und eliminiert. Das Eliminieren von Redundanzen ist dadurch möglich, daß anstelle einer ständigen Wiederholung der Elemente das Element einmal benannt wird und dann nur noch die Stelle, an der es benötigt wird, in geeigneter Form abgespeichert wird.
Die einzelnen Tags 16, Keys 17 und Values 18 des HTML-Codes werden erkannt und als komprimierte Strings in einem oder mehreren Element-Arrays 12, 12' abgelegt. Zu diesen Elementen wird jeweils eine Rendering Information, die beispielsweise eine Information über den Elementtyp umfaßt in einem Rendering Array 13 angelegt. Der Ort der einzelnen Element also der Aufbau der Datei wie auch der Dateistruktur insgesamt ergibst sich aus der in einem Tree-Array 14 angelegten Information bzw. aus deren Reihenfolge. Es handelt sich dabei um eine Folge von Integer zahlen, die den Ort des jeweils zu dekomprimierenden Elements im Element Array 12, 12' angibt. Zusätzlich zu diesen Arrays wird ein individueller Dekompressionscode in einer ECMA-Script-Sprache, hier JAVA-Script erzeugt. Im Rahmen der Kompression einer HTML- File werden somit zunächst komprimierte Element-Arrays 12, 12' in Verbindung mit einem Rendering-Array 13 und einem Tree-Array 14 erzeugt. Die Arrays werden mit dem Dekompressionstools 15, das als JAVA-Script auf dem Server 2 abgelegt ist, auf dem Server 2 gespeichert.
Das Dekompressionstool 15 stellt ein echtes in einer Makrosprache definiertes Programm dar, daß vom Browser übersetzt und abgearbeitet wird. Dadurch daß das Dekompressionstool in Form von JAVA-Script realisiert ist, muß keine weitere Software beim Client 1 installiert sein.
Der Client 1 bezieht auf ein Demand 5 im HTML-Response 6 das Dekompressionstool 15 in Verbindung mit den genannten Element-Rendering und Tree-Arrays 12 bis 14.
Das Dekompressionstool 15 arbeitet zur Dekompression oder aber zum Aufbau der HTML-Seite, die im Wege des HTML- Response 6 übermittelt wurde, zunächst den Tree-Array 14 ab. Der Tree-Array 14 gibt die Position der zum Aufbau der Seite jeweils benötigten Elemente in den betreffenden Element-Arrays 12, 12' an. Durch die sequentielle Abarbeitung des Tree-Arrays 14 ergibt sich gleichzeitig die Reihenfolge der zu restaurierenden Elemente.
Die Position der Elemente und der HTML-Files innerhalb der HTML-Dateien und der Dateistruktur ist ebenfalls komprimiert in Form von Integer-Zahlen, die in Base 36 kodiert sind, innerhalb des Tree-Arrays 14 angelegt. Zusätzlich zu dem Zugriff auf ein Element innerhalb des Elementen-Arrays 12, 12' wird aus dem Rendering-Array 13 die entsprechende Information über den jeweiligen Element-Typ bezogen.
Anhand der Informationen über den Element-Typ und etwaig weitere Spezifikationen des Elements wird mit Hilfe des Dekompressionstools 15 das Originalelement aus dem Element- Array 12, 12' rekonstruiert und an die durch die sequentielle Abarbeitung des Tree-Arrays 14 an die vorgegebene Stelle gesetzt. Im Falle redundanter Elemente werden dabei sämtliche Elemente an der jeweils erforderlichen Stelle rekonstruiert.
Der durch die hier beispielhaft beschriebene Kompression erreichte wesentliche Unterschied zwischen der Kompression mittels herkömmlicher Programme wie den bekannten Zip- Verfahren und dem erfindungsgemäßen Verfahren wird noch einmal anhand des Prinzipbilder in den Fig. 5 und 6 erläutert.
Fig. 5 zeigt eine herkömmliche HTML-Struktur mit HTML- Dateien 20 und script embedded language HTML Strukturen 21-23, wie etwa mit einem JSP-, PHP- und ASP-Bestandteil und den hierzu benötigten Präprozessoren 24-26 und den hierzu gehörigen Server 2. Im Falle eines Demands 5 werden dann die HTML-Dateien 20-23 im Stand der Technik zunächst serverseitig beispielsweise mittels eines Zip- Kompressionsschritts 27 komprimiert. Hierbei findet eine CPU-Belastung des Servers 2 statt, die je nach Mächtigkeit dessen Performance beeinträchtigen kann.
Die dem Stand der Technik entsprechend komprimierte Struktur wird dann über das Internet 3 oder ein Intranet an den Client 1 übermittelt. Der Client 1 bzw. der Clientrechner muß jedoch vor der Darstellung der bezogenen HTML-Struktur durch einen Browser 28 einen Zip-Dekompressionsschritt 29 mittels eines zusätzlichen vom Client 1 jeweils passend vorzuhaltenden Zip-Programms die HTML-Struktur 20-23 in de ursprünglichen Form wiederherstellen.
Im Unterschied hierzu liegen gemäß Fig. 6 in Übereinstimmung mit dem erfindungsgemäßen Verfahren anstelle der HTML- Strukturen 20-23 bereits speicherplatzoptimierte komprimierte Strukturen 30-33, ergänzt durch das individuelle Dekompressionstool 15 auf dem Server 2. Die im Zusammenhang mit den script embedded language Strukturen 31-33 benötigen Präprozessoren 34-36 sind allerdings analog vorhanden. Im Falle eines Demand 5 entfällt demnach der in Fig. 5 gezeigte Kompressionsschritt 27 vollständig. Statt dessen werden die bereits komprimierten Dateien incl. dem Dekompressionstool 15 unmittelbar über das Internet 3 an den Client 1 übermittelt, wobei dann durch Abarbeitung des als Javascript übermittelten Dekompressionstools 15 mittels des Browsers 28 die bereits serverseitig komprimierten ursprünglichen HTML-Strukturen 20-23 aufgebaut werden.
Vorstehend ist somit ein Verfahren zur Kompression von HTML/XHTML-Strukturen wie sie vorzugsweise auf einem Webserver 2 abgelegt sind, beschrieben. In Verbindung mit der Kompression der HTML/XHTML-Strukturen 20-23 wird gleichzeitig ein Dekompressionstool 15 erzeugt, das in einer ECMA-Sprache angelegt und mit dem komprimierten Dateninhalt an den Client 1 übermittelt wird. Der Client 1 kann dann ohne eine zusätzliche Software die komprimierten HTML/XHTM-Dateien 30 33 beziehen und auf seinem Computer betrachten bzw. weiter verarbeiten. Dabei erfolgt die serverseitige Kompression der Dateien aufgrund der im Rahmen der Erfindung verschiebenen Kompression. Dabei entsteht ein zur Dekompression benötigtes individuelles Dekompressionstool 15, dessen Aufbau im wesentlichen vom HTML/XHTML- Content der jeweiligen Server 2 abhängt. BEZUGSZEICHENLISTE 1 Client
2 Server
3 Internet
4 Einloggvorgang
5 Demand.
6 HTML-Response
7 Ausloggvorgang
10 Hompepage
11 Unterseiten
12, 12 Element-Arrays
13 Rendering-Arrays
14 Tree-Arrays
15 Dekompressionstool
16 Tag
17 Key
18 Value
20 HTML-Datei
21 HTML-Datei mit JSP-Anteil
22 HTML-Datei mit PHP-Anteil
23 HTML-Datei mit ASP-Anteil
24 JSP-Präprozessor
25 PHP-Präprozessor
26 ASP-Präprozessor
27 ZIP-Kompression
28 Browser
29 ZIP-Dekompression
30 Komprimierte HTML-Datei
31 Komprimierte HTML-Datei mit JSP-Anteil
32 Komprimierte HTML-Datei mit PHP-Anteil
33 Komprimierte HTML-Datei mit ASP-Anteil
34 JSP-Präprozessor
35 PHP-Präprozessor
36 ASP-Präprozessor

Claims

1. Kompressionsverfahren für HTML/XHTML-Dateien mit folgenden Schritten;

- Scannen zumindest eines Teils der auf einem Server abgelegten HTML/XHTML-Dateien (20-23),

- Ersetzen des HTML/XHTML-Codes dieser Dateien und deren Datenstruktur durch komprimierte Strings

- Generierung eines individuellen Dekompressionscodes (15) in einer ECMA-Script-Sprache, vorzugsweise Java-Script, der den jeweils komprimierten HTML/XHTML-Dateien (30-33) zugeordnet wird.

2. Kompressionsverfahren nach Anspruch 1, dadurch gekennzeichnet, daß im Falle eines Zugriffs durch einen Client (1) auf den Server (2) die jeweils angesprochenen HTML/XHTML- Dateien (30-33) komprimiert in Verbindung mit dem individuellen Dekompressionscode (15) übermittelt werden.

3. Kompressionsverfahren nach Anspruch 2, dadurch gekennzeichnet, daß der individuelle Dekompressionscode (15) clientseitig vorzugsweise als Link abgelegt und jeweils beim Zugriff auf denselben Server (2) mittels eines beim Client (1) eingesetzten Browsers zur Dekompression der bezogenen HTML/XHTML-Dateien interpretiert und abgearbeitet wird.

4. Kompressionsverfahren nach Anspruch 3, dadurch gekennzeichnet, daß die clientseitige Dekompression der jeweils bezogenen HTML/XHTML-Dateien (30-33) in realtime erfolgt.

5. Kompressionsverfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß beim Verfahrensschritt "Scannen" folgende Unterschritte abgearbeitet werden;

- Erkennen von Tags (16) der zu komprimierenden HTML/XHTML-Datei

- Erkennen von Keys (17) dieser HTML/XHTML-Datei

- Erkennen von Values (18) dieser HTML/XHTML- Datei

- Zwischenspeicherung dieser Informationen

6. Kompressionsverfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Verfahrensschritt "Ersetzen des HTML/XHTML-Codes" der Dateien und deren Struktur die Anlage von wenigstens einem Element- Array (12 oder 12'), wenigstens einem Tree-Array (14) und wenigstens einem Rendering-Array (13) umfaßt.

7. Kompressionsverfahren nach Anspruch 5 oder 6, dadurch gekennzeichnet, daß die Tags (16), Values (18) und/oder Keys (17) der zu komprimierenden HTML/XHTML-Datei klassifiziert und als Rendering Information im Rendering Array (13) abgelegt werden.

8. Kompressionsverfahren nach Anspruch 5, 6 oder 7, dadurch gekennzeichnet, daß innerhalb der zu komprimierenden HTML/XHTML-Datei etwa vorhandene Redundanzen erkannt und als Redundanz-Information im Tree-Array (14) abgelegt werden.

9. Kompressionsverfahren nach einem der vorhergehenden Ansprüche 5 bis 8 dadurch gekennzeichnet, daß der HTML/XHTML-Code als komprimierte -Strings innerhalb des wenigstens einen Element-Arrays (12) abgelegt wird, wobei die Elemente durch spezielle Trennzeichen innerhalb des Rendering-Arrays (13) voneinander trennbar gespeichert werden.

10. Kompressionsverfahren nach Anspruch 9, dadurch gekennzeichnet, daß die zu komprimierenden HTML/XHTML-Datei in einem weiteren Schritt daraufhin gescannt wird, ob das spezielle Trennzeichen vorhanden ist, wobei dies bejahendenfalls ersetzt wird.

11. Kompressionsverfahren nach einem der vorhergehenden Ansprüche 5 bis 10, dadurch gekennzeichnet, daß innerhalb des Rendering-Arrays (13) zu jedem Element eine Rendering-Information bezüglich des Elementtyps aus einer Menge von, vorzugsweise 9, vordefinierten Elemententypen zugewiesen wird.

12. Kompressionsverfahren nach Anspruch 11, dadurch gekennzeichnet, daß im Falle mehrere Element-Arrays (12, 12') zu jedem Element innerhalb des Rendering-Arrays (13) eine Array-Information abgelegt wird.

13. Kompressionsverfahren nach einem der Ansprüche 5 bis 12, dadurch gekennzeichnet, daß die Dateistruktur der Dateien als solcher sowie die Bezüge der Dateien untereinander in dem Tree-Array (14), vorzugsweise als Integer-Zahlen in Base 36 kodiert, abgelegt werden, wobei dieses Tree-Array (14) bei der Dekompression gemäß dem individuellen Dekompressionscode (15) sequentiell abgearbeitet wird.

14. Kompressionsverfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß in einem weiteren Verfahrenschritt nach oder vor dem "Scannen" der zu komprimierenden Struktur etwa in dieser Struktur vorhandene "white spaces" erkannt und ggf. eliminiert werden.

15. Kompressionsverfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß serverseitig in die zu komprimierenden HTML/XHTML-Dateien integrierte Script-Sprachen, vorzugsweise JAVA-Server-Pages, Hypertext-Preprocessor-Prozessor, Activ-Server-Pages serverseitig in der komprimierten Struktur erhalten bleiben und mit dieser komprimierten Struktur an den Client (1), übermittelt werden.

16. Kompressionsverfahren nach einem der vorhergehenden Ansprüche 1 bis 14, dadurch gekennzeichnet, daß serverseitig in die zu komprimierenden HTML/XHTML-Dateien integrierte Script-Sprachen, vorzugsweise JAVA-Server- Pages, Hypertext-Präprozessor, Activ-Server-Pages ebenfalls komprimiert werden und ein insoweit veränderter individueller Dekompressionscode (15) an den Client (1) übermittelt wird.