Ein effizienter Komprimierungsalgorithmus für kurze Textzeichenfolgen [geschlossen]

Ich suche nach einem Algorithmus zum Komprimieren kleiner Textzeichenfolgen: 50-1000 Bytes (dh URLs). Welcher Algorithmus funktioniert dafür am besten?

Schauen Sie sich Smaz an :

Smaz ist eine einfache Komprimierungsbibliothek, die zum Komprimieren sehr kurzer Zeichenfolgen geeignet ist.

Huffman hat statische Kosten, die Huffman-Tabelle, daher bin ich nicht der Meinung, dass dies eine gute Wahl ist.

Es gibt adaptive Versionen, die dies beseitigen, aber die Komprimierungsrate kann darunter leiden. Die Frage, die Sie sich stellen sollten, lautet: "Welcher Algorithmus zum Komprimieren von Textzeichenfolgen mit diesen Merkmalen". Wenn beispielsweise lange Wiederholungen erwartet werden, kann eine einfache Run-Lengh-Codierung ausreichen. Wenn Sie garantieren können, dass nur englische Wörter, Leerzeichen, Satzzeichen und gelegentliche Ziffern vorhanden sind, kann Huffman mit einer vordefinierten Huffman-Tabelle gute Ergebnisse liefern.

Im Allgemeinen weisen Algorithmen der Lempel-Ziv-Familie eine sehr gute Komprimierung und Leistung auf, und es gibt zahlreiche Bibliotheken für sie. Ich würde damit gehen.

Mit der Information, dass es sich bei den zu komprimierenden URLs um URLs handelt, würde ich vorschlagen, dass Sie sie vor dem Komprimieren (mit jedem leicht verfügbaren Algorithmus) KODIFIZIEREN. URLs folgen genau definierten Mustern, und einige Teile davon sind sehr vorhersehbar. Wenn Sie dieses Wissen nutzen, können Sie die URLs zunächst in etwas Kleineres kodieren, und Ideen hinter der Huffman-Codierung können Ihnen hier helfen.

Wenn Sie beispielsweise die URL in einen Bitstrom übersetzen, können Sie "http" durch das Bit 1 und alles andere durch das Bit "0" gefolgt vom eigentlichen Procotol ersetzen (oder eine Tabelle verwenden, um andere gängige Protokolle wie https zu erhalten). FTP, Datei). Das ": //" kann ganz gelöscht werden, solange Sie das Ende des Protokolls markieren können. Lesen Sie mehr über das URL-Format und überlegen Sie, wie sie codiert werden können, um weniger Speicherplatz zu beanspruchen.

Ich habe nicht den Code zu Hand, aber ich mochte immer die Annäherung eines Tabellennachschlag 2D Aufbau der Größe 256 * 256 Zeichen ( RFC 1978 , PPP Predictor Compression Protocol ). Um eine Zeichenfolge zu komprimieren, durchlaufen Sie jedes Zeichen und verwenden die Nachschlagetabelle, um das 'vorhergesagte' nächste Zeichen zu erhalten, wobei das aktuelle und das vorherige Zeichen als Indizes für die Tabelle verwendet werden. Wenn es eine Übereinstimmung gibt, schreiben Sie ein einzelnes 1-Bit, andernfalls schreiben Sie eine 0, das Zeichen und aktualisieren die Nachschlagetabelle mit dem aktuellen Zeichen. Bei diesem Ansatz wird im Wesentlichen eine dynamische (und grobe) Nachschlagetabelle des wahrscheinlichsten nächsten Zeichens im Datenstrom beibehalten.

Sie können mit einer auf Null gesetzten Nachschlagetabelle beginnen, aber offensichtlich funktioniert sie am besten bei sehr kurzen Zeichenfolgen, wenn sie mit dem wahrscheinlichsten Zeichen für jedes Zeichenpaar initialisiert wird, z. B. für die englische Sprache. Solange die anfängliche Nachschlagetabelle für die Komprimierung und Dekomprimierung identisch ist, müssen Sie sie nicht in die komprimierten Daten ausgeben.

Dieser Algorithmus bietet kein brillantes Komprimierungsverhältnis, ist jedoch unglaublich sparsam mit Speicher- und CPU-Ressourcen und kann auch mit einem kontinuierlichen Datenstrom arbeiten. Der Dekomprimierer verwaltet beim Dekomprimieren eine eigene Kopie der Nachschlagetabelle, also der Nachschlagetabelle passt sich dem Typ der zu komprimierenden Daten an.

Jeder Algorithmus / jede Bibliothek, die ein voreingestelltes Wörterbuch unterstützt, z . B. zlib .

Auf diese Weise können Sie den Kompressor mit demselben Text grundieren, der wahrscheinlich in der Eingabe erscheint. Wenn die Dateien in irgendeiner Weise ähnlich sind (z. B. alle URLs, alle C-Programme, alle StackOverflow-Beiträge, alle ASCII-Zeichnungen), werden bestimmte Teilzeichenfolgen in den meisten oder allen Eingabedateien angezeigt.

Jeder Komprimierungsalgorithmus spart Platz, wenn derselbe Teilstring in einer Eingabedatei mehrmals wiederholt wird (z. B. "the" im englischen Text oder "int" im C-Code).

Bei URLs werden bestimmte Zeichenfolgen (z. B. " http: // www .", ".Com", ".html", ".aspx" normalerweise einmal in jeder Eingabedatei angezeigt. Sie müssen sie also zwischen Dateien freigeben Anstatt ein komprimiertes Vorkommen pro Datei zu haben, wird dies durch Platzieren in einem voreingestellten Wörterbuch erreicht.

Die Huffman-Codierung funktioniert hierfür im Allgemeinen in Ordnung.

Wenn Sie davon sprechen, den Text tatsächlich zu komprimieren und nicht nur zu kürzen, sondern Deflate / gzip (Wrapper um gzip), eignet sich zip gut für kleinere Dateien und Text. Andere Algorithmen sind für größere Dateien wie bzip2 usw. hocheffizient.

Wikipedia hat eine Liste der Komprimierungszeiten. (Vergleich der Effizienz)

Name       | Text         | Binaries      | Raw images
-----------+--------------+---------------+-------------
7-zip      | 19% in 18.8s | 27% in  59.6s | 50% in 36.4s
bzip2      | 20% in  4.7s | 37% in  32.8s | 51% in 20.0s
rar (2.01) | 23% in 30.0s | 36% in 275.4s | 58% in 52.7s
advzip     | 24% in 21.1s | 37% in  70.6s | 57& in 41.6s
gzip       | 25% in  4.2s | 39% in  23.1s | 60% in  5.4s
zip        | 25% in  4.3s | 39% in  23.3s | 60% in  5.7s

Vielleicht möchten Sie sich das Standardkomprimierungsschema für Unicode ansehen .

SQL Server 2008 R2 verwendet es intern und kann eine Komprimierung von bis zu 50% erreichen.