Tutorial Arbeiten mit Dateien auf binärer Ebene

[Sir Rufo]

Zitat von Fehlersucher:

Wie sollte man denn bei einem Komprimierungsalgorithmus vorgehen:
In welcher Form sollte man eine Datei eingelsesen um später möglichst effektiv zu komprimieren?
Hexadezimal, binär o.ä.?

Gruß

Nochmal zum mitschreiben:

Eine (jede) Datei besteht aus einer Ansammlung von Bytes.
Jedes Byte kann 256 Zustände haben.
Diese Zustände kann man dezimal mit 0..255 darstellen
oder hexadezimal 00..FF
oder binär 00000000..11111111

Der Inhalt ändert sich nicht durch die Darstellung. Diese Darstellung ist nur für unseren analogen Aufnahmemodus gedacht (Augen) und damit wir die Theorie dahinter verstehen.

Wenn du an Komprimierung denkst, dann hat das nichts, aber auch gar nichts mit dezimal, hexadezimal oder binär zu schaffen.

[Popov]

Vielleicht noch mein Senf dazu. Das Beispiel weiter vorne wo eine beliebige Datei in einen AnsiString geladen wird, kann man sich letztendlich sparen, bzw. den Teil mit dem String. Einfach mit TFileStream eine Datei öffnen und schon hat man die Datei im Stream. Sie besteht auf Bytes (also Werten zwischen 0 und 256) und hat die Länge der Datei. Ein Byte hat also immer maximal den Wert von 255. Man kann ihn Dezimal schreiben als 255 oder hexadezimal als $FF oder Binär als 11111111. Letztendlich stehen alle für den gleichen Wert, wobei es Delphi Schnuppe ist ob du die Zahl 255 als 255 schreibst oder als $FF. Delphi kommt mit beiden Schreibweisen gleich klar. Komplizierter wird es mit der Binärdarstellung.

Also, du kannst eine Datei in einen AnsiString laden, da er zufällig auch eine Zeichenmenge in sich aufnehmen kann und jedes Zeichen eines von 256 Werten darstellen kann. Musst du aber nicht.

[Fehlersucher]

Zitat von MeierZwoo:

Zitat von Fehlersucher:

In welcher Form sollte man eine Datei eingelsesen um später möglichst effektiv zu komprimieren?
Hexadezimal, binär o.ä.?

Gegenfrage: Willst Du es nicht begreifen?
Man kann NICHTS Hexadezimal oder Oktal oder .. einlesen, NUR binär, weil ALLES in der EDV binär IST.

Ein Byte ist ein Byte ist ein Byte,
ein Bit ist ein Bit ist ein Bit!

Nochmal: Es gibt weder Nullen und Einsen noch Hexadezimal noch Oktal ... in Dateien und im RAM - NUR Bits und Bytes! Bits zu Bytes gruppiert, Bytes nach Bittiefe des OS zu Bytegruppen gruppiert.

Ja aber was habe ich dann?
Beim Einlesen von den Bytes habe ich doch die 8 Bits und die sind ja nichts anderes als 1 und 0.
Habe ich demnach nicht nach dem Einlesen eine Reihe aus einsen und nullen?
Wie sollten die Bytes sonst anders dargestellt werden?

[MeierZwoo]

Zitat von Fehlersucher:

Ja aber was habe ich dann?
Beim Einlesen von den Bytes habe ich doch die 8 Bits und die sind ja nichts anderes als 1 und 0.
Habe ich demnach nicht nach dem Einlesen eine Reihe aus einsen und nullen?
Wie sollten die Bytes sonst anders dargestellt werden?

Bytes bzw. Bits bestehen nicht aus Einsen oder Nullen, sondern aus Zuständen. Wir Menschen nennen diese Zustände 0 oder 1 oder ...
Der Zustand eines Bits ist gesetzt/ungesetzt oder Spannung/keine Spannung oder Strom/kein Strom oder pos. Spannung/neg. Spannung oder Loch/kein Loch ........

Die Darstellung dieser Zustände benennen wir blöden Menschen mit Zahlen, sonst könnten wir der EDV nicht folgen. Die Kiste kennt in allen Speichern nur Zustände.

[Fehlersucher]

Was würde ich dann sehen, wenn ich einen FileStream in einen String schreibe und mir im Edit zeigen lasse?

Wie kann ich vernünftig mit einem FileStream arbeiten, wenn ich nicht weiß, was er enthält?

[DeddyH]

Zitat von Fehlersucher:

Was würde ich dann sehen, wenn ich einen FileStream in einen String schreibe und mir im Edit zeigen lasse?

Wie kann ich vernünftig mit einem FileStrem arbeiten, wenn ich nicht weiß, was er enthält?

Es kommt auf den Dateiinhalt an. Ist es eine Textdatei, wirst Du wohl auch darstellbaren Inhalt zu Gesicht bekommen, ansonsten wahrscheinlich irgendwelchen Wirrwarr, der womöglich auch kürzer ist als die Dateigröße. Mit einem FileStream zu arbeiten, ohne zu wissen, wie der Inhalt zu interpretieren ist, ist selten eine gute Idee.

[Sir Rufo]

Zitat von DeddyH:

Zitat von Fehlersucher:

Was würde ich dann sehen, wenn ich einen FileStream in einen String schreibe und mir im Edit zeigen lasse?

Wie kann ich vernünftig mit einem FileStrem arbeiten, wenn ich nicht weiß, was er enthält?

Es kommt auf den Dateiinhalt an.

Es kommt auch auf die Interpretation des Dateiinhaltes an - selbst bei Textdateien.
Eine Textdatei kann auf unterschiedliche Arten kodiert sein (ANSI, UTF-8, UTF-16 Little Endian, UTF-16 Big Endian, etc.) und dass muss man wissen um den enthaltenen Text aus der Bytefolge auch richtig zu interpretieren.

Bei der (verlustfreien) Komprimierung ist das aber völlig wumpe, da interessieren einen eh nur die Bytes und nicht was die tatsächlich bedeuten sollen.

[Fehlersucher]

Demenstprechend werden Zeichen in einem Stream nicht interpretiert.

Wenn ich also eine Datei (für einen Komprimieralgorithmus) öffne, müsste ich die Bytes sinnvollerweise als Folge von einsen und nullen interpretieren lassen. Wie mache ich dies denn?

[MeierZwoo]

Wenn du etwas in einen string schreibst (string als Typen Declaration)dann geht das Programm davon aus, daß es die bytes als Darstellbare Zeichen interpretieren soll. Dann ist allein durch die type-Zuordnung schon eine Interpretation vorgenommen worden.

Trotzdem stehen im string nur bytes, und keine "A" "B" ...

Wenn du diesen String in Edit einfügst, kommt es darauf an, wie die Codierung in Edit gesetzt ist (die nächste Interpretation), ob ASCII oder Indian oder UTF-8 ...

Warum guckst du dir nicht endlich mal eine Datei in einem HexEditor an, zB eine BMP. Dann zeigt der HexEditor rechts Punkte oder Buchstaben an - bloß es gibt in der gesamtem BMP keinen einzigen Buchstaben! Es ist eine Frage der Interpretation eines Bytes, was dargestellt wird.

[Popov]

Was Sir Rufo beschrieben hat ist die Grundlage der Komprimierung. Man kann das übrigens auch auf Binärebene machen.

5050F1F1 ist Binär 1010000010100001111000111110001, die Komprimierung könnte auch so aussehen 1,1,1,5,1,1,1,4,4,3,5,3,1, also 1 mal 1, 1 mal 0, 1 mal 1, 5 mal 0, usw. Wobei bei diesem Beispiel die Komprimierung wohl größer wäre als die alte Datei, wenn aber paar hundert Nullen hintereinander sind, dann klappt das wieder.

Was man auch machen kann ist sich eine Bibliothek aus Mustern anlegen. In einer Datei wiederholen sich Bereiche. Man würde dann nicht speichern wie oft eine Null oder Eins vorkommt, sondern eine Adresse auf ein Muster.

//Edit

Ich hab dir doch weiter vorne zwei fertige Funktionen gepostet. Warum eigentlich? Wie wäre es wenn du sie ausprobierst, dann weißt du was da steht.