Tutorial Arbeiten mit Dateien auf binärer Ebene

[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ß

[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.

[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.

[MeierZwoo]

oder Oktal 000 .. 377
oder als Nibble 0 + 0 .. F + F

[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?

[Popov]

Oder Yan Tan Tethera, aber das ist eher zum zählen von Schafen.

Vielleicht etwas für den Einstieg: http://de.wikipedia.org/wiki/Hexadezimal

//Edit

Zitat:

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?

Nein, nach dem Einlesen hast du erst ein mal Bytes. Zwar bestehen Bytes aus Bits, somit kann man behaupten, dass Bits die kleinsten Einheiten im Computer sind, aber so stimmt es meiner Meinung nach nicht ganz. Die kleinsten Einheiten im Computer sind die Bytes, und die konnten einen von 256 Werten haben. Noch kleiner kriegt man es auf dem Computer nicht direkt gespeichert. Immer nur mindestens ein Byte. Selbst Booleanwerte, also True und False, also 1 und 0 verbrauchen ein Byte.

Wenn du also ein Byte geladen hast, kannst du es in Bist weiter aufteilen. Dann kannst du durch eine Berechnung aus 255 eben Binär 11111111 machen.

[Sir Rufo]

Um mal zum (wohl eigentlichen) Thema Komprimierung zurückzukommen ein simples Beispiel:

Angenommen man hat eine Datei in der folgendes enthalten ist
(ACHTUNG: Darstellung in Hexadezimal-Schreibweise damit ich das hier veranschaulichen kann)

Code:

05 05 05 05 1F 1F 1F 1F 1F 1F 1F 1F 7B 7B 7B 7B 7B

und möchte diese komprimieren, so kann ich hier einen ganz simplen Komprimier-Algorithmus verwenden und dampfe die Datei auf folgende Bytefolge ein:

Code:

04 05 08 1F 05 7B

Die Struktur dieser Datei ist wie folgt:

Code:

Länge: 1 Byte
Wert : 1 Byte

und bedeutet somit

Code:

4 Bytes mit 05
8 Bytes mit 1F
5 Bytes mit 7B

Das dieser Algorithmus nicht wirklich optimal ist sollte man auf den ersten Blick erkennen, denn hier werden nur dann gute Kompressionsraten erzielt, wenn es möglichst viele gleiche Bytefolgen gibt. Schlimmstenfalls wird die komprimierte Datei doppelt so groß wie die Ursprungsdatei

Aber das allgemeine Prinzip sollte etwas klarer 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?