Warum ermöglicht die Ascii85-Codierung keine dynamische Komprimierung?

Question

Laut Wikipedia: (!)

[ASCII85 verwendet] des ASCII-Zeichen 33 bis 117 (u) inklusive (die Basis-85 repräsentiert die Ziffern 0 bis 84), zusammen mit dem Buchstaben z (als Sonderfall zur Darstellung eines 32-Bit 0-Wertes).

[btoa] Version 4.2 hinzugefügt, um eine „y“ Ausnahme für eine Gruppe aller ASCII Leerzeichen

Während 0 Daten könnten durchaus üblich, dass die Verwendung von z des zu komprimieren 0 wie eine beliebige Optimierung scheint, dass wird nicht immer von Nutzen sein.

Auch die weniger häufige Verwendung von y ist nur dann von Nutzen, wenn das Roh-Bytes benachbarte Leerzeichen enthalten. Die Unicode-Codierung von Speicherplatz ist eigentlich 20 00, so 0x20202020 ist nicht so häufig in Unicode-Texten.

Binäre Daten haben oft benachbarte 00 's, aber es enthält oft auch benachbarte FF' s.

Textdaten enthalten oft benachbarte Räume, aber es enthält auch oft benachbarte Tabulatoren oder benachbarte new-line Zeichen.

Es scheint, dass eine Frequenzanalyse, und die Verwendung von 9 oder 10 Zeichen (ASCII-Zeichen 118-126/127, oder durch v~/ DEL), um die am häufigsten 9/10 32-Bit-Werte zu repräsentieren, könnte zu einer besseren Komprimierung führen.

Die Zuordnung von Komprimierungszeichen zu 32-Bit-Wert könnte möglicherweise am Anfang der codierten Zeichenfolge zwischen <[ und ]> sitzen. Bei 32-Bit-Werten, bei denen es sich um 4 wiederholte Bytes handelt, kann der 32-Bit-Wert als wiederholter Hexadezimalwert (s) abgekürzt werden.

Zum Beispiel:

die binären Daten (192 Bytes):

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

00 00 00 00 FF FF FF FF 20 20 20 20 2D 2D 2D 2D 09 09 09 09 0D 00 0A 00

Hinweis das Vorhandensein von Räumen 20, Bindestriche 2D, Tabs 09 und Unicode Carriage Return-Line Feeds 0D 00 0A 00

könnte als (79 Bytes)

<[00;FF;20;2D;09;0D000A00]><~vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|vxyz{|~>

Gibt es Verdienst in einem Codierungs Ansatz codiert werden, die eine solche Kompression verwendet? Warum sind die verschiedenen Ascii85-Spezifikationen nicht aggressiver mit Kompression?

Answer 1

Weil Sie normalerweise ein Komprimierungsprogramm vor dem Kodieren mit ASCII85 verwenden würden, das eine viel bessere Arbeit als die vorgeschlagenen Ad-hoc-Kodierungen leisten kann.

Answer 2

Es gibt einige Anwendungen, für die es nützlich ist, das N-te Oktett einer codierten Zeichenkette zu finden, ohne das Ganze scannen zu müssen. Kompression würde das stören. Es gibt jedoch andere Anwendungen, für die bestimmte Formen der Komprimierung nützlich sein könnten. Wenn mehr als 85 verschiedene Zeichen verwendet werden können, ermöglicht eine Codierung mit der Basis 85 eine einfache Komprimierung mit Zeichen außerhalb des primären Satzes. Selbst wenn man auf einen Satz von genau 85 Zeichen beschränkt ist, ist die Anzahl der Folgen von fünf Basen-85-Zeichen grßer als die kombinierte Anzahl von Sequenzen von einem, zwei, drei und vier Basen-256 Bytes, so daß Platz wäre einige spezielle Kombinationen von Zeichen zu verwenden, um z Läufe von bestimmten Charakterwerten. Das größte Problem besteht darin, dass dadurch die Möglichkeit verloren geht, zufällige Suchvorgänge innerhalb des codierten Datenstroms durchzuführen.