Einzelnen Beitrag anzeigen

Muetze1
(Gast)

n/a Beiträge
 
#7

Re: Bessere Kompression mit eigenem Dateiformat??

  Alt 26. Mai 2004, 14:06
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
  Mit Zitat antworten Zitat