Tutorial Arbeiten mit Dateien auf binärer Ebene

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

[Sir Rufo]

Zitat von 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?

Musst du nicht (siehe mein Beispiel) sondern hängt von deinem Komprimierungs-Algorithmus ab.
Ich würde dir aber empfehlen erst mal bei den Bytes als Einheit zu bleiben

[Popov]

Code:

00101011
00000001 AND
--------
00000001

Hier wissen wir, dass in dem oberen Byte an der ersten Stelle ein Bit gesetzt ist.

1 AND 1 ergibt 1.

Der erste Bit steht für den Wert 1. Wenn du also einen beliebigen Byte mit 1 AND rechnest und das eine 1 ergibt, weißt du, dass der Byte an der Stelle eine 1 hat. Das klappt auch mit dem nächsten Byte:

Code:

00101011
00000010 AND
--------
00000010

Hier wissen wir, dass in dem oberen Byte an der zweiten Stelle ein Bit gesetzt ist.

Code:

00101011
00000100 AND
--------
00000000

Hier wissen wir, dass in dem oberen Byte an der dritten Stelle kein Bit gesetzt ist.

Code:

00101011
00001000 AND
--------
00001000

Hier wissen wir, dass in dem oberen Byte an der vierten Stelle ein Bit gesetzt ist.

[Fehlersucher]

Das scheint sehr simpel zu sein,

aber warum beginnt die erste Stelle ganz rechts?
Was bringt das?

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