Packer für ASCII-Daten gesucht

Es gibt 4 Antworten in diesem Thema, welches 1.199 mal aufgerufen wurde. Der letzte Beitrag (27. März 2020 um 20:36) ist von Freak.

  • Hallo,

    für ein Bitte melde dich an, um diesen Link zu sehen. suche ich einen geeigneten Packer/Cruncher. Dieser soll aber keine Programme packen, sondern ca. 2000 kByte an reinem ASCII-Text, aufgeteilt in vier Pakte zu je 50 kByte. Ich will in meinem Programm nacheinander auf diese vier Pakete zeilenweise zugreifen, d.h. im Idealfall liefert mir das Entpackprogramm zeilenweise den Originaltext eines Pakets zurück, solange bis das Ende des Pakets erreicht ist. Ein Bereitstellen einzelner Bytes ist aber auch natürlich möglich, dann füge ich diese zu den benötigten Zeilen zusammen.

    Der ASCII-Text, der gepackt werden soll, sieht generell so aus:

    Und so geht es dann weiter, bis zu einer Länge von ca. 50 kByte.

    Da ich mich auf diesem Gebiet nicht sonderlich gut auskenne, meine Frage in die Runde: Gibt es einen dafür geeigneten Packer/Cruncher?

    Schon mal vielen Dank für eure Kommentare.

    Gruß

    Thomas

    Meine Projekte:
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Gibt es einen dafür geeigneten Packer/Cruncher?

    Wenn alle Stricke reißen:

    Bitte melde dich an, um diesen Link zu sehen. und der Folgebeitrag.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Geht's da um Bitte melde dich an, um diesen Link zu sehen.? Dann glaube ich, dass ein generischer Packer immer zweite Wahl ist, weil man mit Tokenisieren und binärer Kodierung der Zahlen nicht nur mehr Kompression erreicht, sondern man spart sich auch den ganzen Tabellenkram. Es bleibt dann nur der Code zur Rückwandlung, der nicht wesentlich größer sein dürfte, als der Entpacker. Und die Originalstruktur - also Zeilen in dem Fall - bleibt ohne Klimmzüge erhalten.

    Bei Hexzahlen erreicht man 50%, bei Commandos wesentlich mehr, Spaces fliegen komplett raus, Linefeeds werden Deskriptoren...

    Aus so einer Zeile

    Code
    SIR 8 TDI (42);

    werden dann - je nach dem, wie weit man geht - 5 Bytes statt 15. Selbst wenn man integer defaultmäßg mit 16 Bit speichert, wären es nur 7 Bytes.

    Ich hab' sowas mal zur Übertragung von Telemetriedaten via seriellen Port zur physischen Netztrennung gemacht... Da war's zum Beispiel so, dass die Fließkommazahlen maximal eine Stelle vor dem Komma hatten - da kodiert man nur noch 4 Ziffern und setzt den Punkt fix nach der ersten Stelle... Würde 40% der Ausgangsgröße erzeugen. Das ist mit den Kompressions-Algorithmen, die man auf dem 64er umsetzen kann, sonst kaum zu erreichen.

  • Geht's da um sowas? Dann glaube ich, dass ein generischer Packer immer zweite Wahl ist, weil man mit Tokenisieren und binärer Kodierung der Zahlen nicht nur mehr Kompression erreicht, sondern man spart sich auch den ganzen Tabellenkram.

    Dachte ich zuerst auch. Aber es sind im SVF-File auch große Teile, die sich zig-fach wiederholen. Die würde man mit Tokenisierung nicht wirklich wegkürzen können, sprich: Da würden sich dann halt nur die Token (plus zugehörige Daten) wiederholen...

    Exomizer packt auch ziemlich gut. Bitte melde dich an, um diesen Link zu sehen.

    Gibt es dafür auch eine ausführliche Dokumentation? Ich habe mit dem Exomizer heute Nachmittag mal das Packen einer 100 kByte SVF-Datei ausprobiert:

    "exomizer raw infile.svf -P0 -o outfile.raw"

    Danach lag im Verzeichnis ein nur 4 kByte langes File!

    Sollte Exomizer die Datei wirklich um 96% eingedampft haben? Ich weiß es leider noch nicht, da ich jetzt erstmal nach einem ASM-Source zum Entpacken des Streams suchen muss. Wobei der doch mit generiert werden soll. Ist der etwa im Stream mit drin?

    Naja, ROM wurde auch nicht an einem Tag erbaut...

    Gruß

    Thomas

    Meine Projekte:
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.