Tutorial Arbeiten mit Dateien auf binärer Ebene

[DeddyH]

Zitat:

Zitat von Fehlersucher (Beitrag 1201381)

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.

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

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1201382)

Zitat:

Zitat von Fehlersucher (Beitrag 1201381)

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:

Zitat von Fehlersucher (Beitrag 1201389)

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?

[Medium]

Konvention. Genau so, wie wir im Zehnersystem hinten die Einerstellen schreiben, es ginge auch vorne. Macht nur keiner.

[Aphton]

Ich bin sehr erfreut darüber, dass die meisten hier nun wissen, dass es nicht verschiedene Lese/Schreibverfahren (binär/ascii) gibt sondern alles eigentlich intern nur aus Nullen und Einsen (zusammengereiht) besteht.
So herrlich.. Habe mich mal vor Ewigkeiten darüber beschwert!