Bessere Kompression mit eigenem Dateiformat??

[yankee]

Mir ist da mal gerade so 'ne Idee gekommen, wie man einfache Textdateien kleiner speichern könnte:
Und zwar hat ja jeder einzelne Buchstabe im ASCI-Format 8-Byte. Jetzt könnte man doch statt jeden Buchstaben einzeln abzuspeichern einfach nur Zahlen, die die Position im Text beinhalten speichern. Das heißt dieser Text:
aaabbbaba
wird zu
12379,4568
oder so ähnlich. Dann hat man nur gespeichert, an welcher Position im Text ein a und in welcher ein b vorkommt. Da Integerwerte viel platzsparender gespeichert werden können, müsste man doch auf erstaunliche Kompressionsraten kommen, oder? Am besten nimmt man statt integerwerten noch Hex-werte oder sowas.
Ich gebe zu ein paar Probleme gibt es dabei schon, da man die Werte voneinander trennen muss usw.
Aber 'n Versuch wär's doch wert? oder?
Was haltet ihr von der Idee? Die Idee ist ja mit Sicherheit nicht neu, also gibt es womöglich Progs, die das tun. Kennt jemand so eins?

EDIT: Ihr fragt euch sicher, warum ich diesen Beitrag in die Kategorie Delphi_Language getan habe. Ich wollte eigentlich fragen, wie man sich eigene Dateitypen definiert, in denen Beispielsweise nur Zahlen geschrieben werden können, um Speicher zu sparen...
Also wenn mir das noch einer erklären könnte (auch wenn ich es zu 90%iger wahrscheinlichkeit nicht verstehen werde...)

[Ultimator]

Aber wenn du einen Text mit >2.000.000 Zeichen hast, ics die Zahl wahrscheinlich größer als der Buchstabe selber.
Aber die Idee an sich ist nicht schlecht.

[yankee]

Nun, man könnte zur Not die Datei in mehrere kleine Datein mit einer maximalgröße von 65535 (entspricht der Größe der Variable Word) unterteilen...

[Ultimator]

Wenn du das machst dann benötigst du wieder mehr Platz im Master Allocation Table (heißt doch so, oder?). Und damit ist dein Vorteil der kleinen Dateien wieder so gut wie hinüber. Man könnte es allerdings so wie OpenOffice machen, dass man einer .txt- Datei oder so eine erfundene Endung anhängt und die dann packt und während der Programmlaufzeit wieder entpackt.

Ich hoffe, du verstehst, was ich meine

[yankee]

@Ultimator: Ja, genau so war das gemeint. Es muss schon das Prog selber zur Laufzeit (ent)packen...

[Ultimator]

Also praktisch ein Archiv in dem 1 bis sozusagen unendlich viele Textdateien liegen, in denen immer die Zahlen drinstehen?
Versteh ich das richtig?

[Muetze1]

Moin!

1. Ein ASCII Wert besteht aus 8 Bit, also 1 Byte.
2. Um eine Zahl kleiner als 1 Byte zu speichern, musst du deren Wertebereich verringern. So kann man z.B. in 4 Bit Werte zwischen 0 und 15 Abspeichern, daber das bringt dir wohl nix, weil so gut wie jeder Text grösser als 15 Zeichen ist, oder?
3. Wenn du immer nur die Position der Zeichen in der Textdatei speichern. Gut, wenn wir nun eine maximale Grösse von einer Textdatei auf 64 KByte festlegen, dann bräuchten wir für die Angabe der Position innerhalb der Datei 16 Bit, also 1 Word = 2 Byte. Somit gehen pro Vorkommen des einen Buchstaben anstatt einem Byte für den Buchstaben 2 Byte verloren - ergo, die Textdatei wird grösser.
4. Du kannst natürlich das ganze auch anders machen: Baue dir eine Tabelle auf, wo die 255 häufigsten Zeichen vorkommen. Diese kannst du in der Tabelle eintragen und einfach in der Textdatei speichern, der wievielte Eintrag das ist. Gut, wäre nicht das Problem, aber Nachteil: Pro Angabe der Position in der Tabelle brauchst du ein Byte - genauso viel wie vorher für das Zeichen an sich. Zusätzlich musst du noch die Tabelle mit vermerken. Ergo: bringt auch nix.
5. Um den Vorschlag von 4. noch abzuändern: wir machen die Tabelle nur 16 Zeichen lang, also die 16 häufigsten Zeichen werden drinne gespeichert und dann brauchen wir für die Position in der Tabelle nur noch 4 Bit, also ein halbes Byte. Somit haben wir schonmal die Hälfte eingespart. Gut, nun muss aber nochmal die Tabelle mit in die Datei, also nochmal 16 Byte wieder hinzu. Ok, auch noch nicht der Beinbruch. Nun haben wir das Problem, das pro ersetztem Zeichen (anstatt ASCII Code der Index in der Tabelle mit 4 Bit) nur noch 4 Bit haben, somit folgt das nächste Zeichen direkt auf den 4 Bit und somit wird das Byte des Zeichens aufgeteilt: eine Hälfte kommt in das ein Byte, die andere Hälfte im folgenden. Somit verschieben sich die Bytes gleich mit bis zum nächsten Zeichen was durch die Tabelle erstetzt werden kann. Dadurch wird der Text auch gleich unleserlich. Nun haben wir aber ein anderes Problem: Woher sollten wir beim entpacken erkennen, ob das nun 4 Bit als Index für die Tabelle sind oder 4 Bit eines 8 Bit ASCII Codes?
6. Ok, 5. nochmal aufgegriffen und nun schreiben wir es so, das wir das oberste Bit auf 0 setzen, wenn es ein Index für die Tabelle ist. Vorteil: wir können die Tabelle 128 Einträge gross machen. Nachteil: originale Zeichen die schon das oberste Bit benutzen, die müssen wir wieder gesondert schreiben, also geht für diese Zeichen nochmal ein Bit verloren - ist aber nicht so schlimm, weil die Zeichen mit dem gesetzten obersten Bit sind eigentlich nur grafische Sonderzeichen (alle mit ASCII Code > 127), somit kommen diese nicht vor in normalen Texten. Somit hat man doch schonmal eine akzeptable Lösung, oder nicht? Nein, hat man nicht, weil pro normalen ASCII Zeichen als Index 7 Bit + 1 Bit zu Erkennung benutzt werden, also auch wieder 8 Bit pro Zeichen, das hatten wir im Original auch schon so. Zusätzlich haben wir dann noch eine Tabelle von 128 Zeichen (also 128 Byte wieder extra) und dann haben wir noch eine Anzahl x von Zeichen, die das oberste Bit gesetzt haben und somit nochmal extra ein Byte pro Zeichen brauchen. Also: Datei wird grösser...

Schau dir mal lieber den Fakt der Wiederholungen von Zeichen an, wie z.B. Leerzeichen und dann schau dir mal die Lauflängenkodierung (RLE, run length encoding), da wirst du mehr Erfolg mit haben - und es wird kleiner.

Und bedenke, das ein ASCII Zeichen 8 Bit hat, also 1 Byte gross ist und nicht 8 Byte...

MfG
Muetze1

[Ultimator]

Der Meister hat gesprochen.

[70UR157]

oops hat schon jmd ausfühlich (& richtig) geantwortet.

[yankee]

Ich muss ja nicht alles verstehen, was du geschrieben hast, aber es reicht um zu verstehen, das meine Idee eigentlich Müll war.
Sagen wir wir beschränken uns auf das am häufigsten Vorkommende Zeichen in jedem normalen Text: Das Leerzeichen. Des weiteren ändere ich die Kommprission ab. Statt sie Absolute Position im Text gebe ich die ralative Position im Text am vorangegengenen Leerezeichen an. Aus diesem Text:

Hi, du Ei! Wie geht es dir?
wird dann also
Hi,duEi!Wiegehtesdir?
und in einer nicht-ASCI Datei
4344535

Das müsste es doch tun, oder?