Binäre Datei lesen

SeppJ

Was erwartest du denn? Nullen und Einsen?

coder++

Lol, irgendwie schon.
Ich meine so, wie ein Hex-Editor es lesen kann, muss es doch irgendwie möglich sein, also ja, mit Nullen und Einsen.

Marthog

Du kannst die Datei Byte für Byte einlesen. Wenn du dich schon an Dateien wagst, solltest du auch ein Byte in einen hexadezimalen bzw. binären String umwandeln können.

coder++

Ja also ich meine, mit ios::binary sollte er die Datei ja eig. binär lesen.
Aber wenn ich es entferne, wird mir trotzdem das Gleiche ausgegeben.
Die Datei sollte ja schon binär gelesen werden, aber sie wird irgendwie trotzdem nach dem ASCII ausgelesen.
Wie mache ich das?

Caligulaminus

coder++ schrieb:

Ja also ich meine, mit ios::binary sollte er die Datei ja eig. binär lesen.
Aber wenn ich es entferne, wird mir trotzdem das Gleiche ausgegeben.
Die Datei sollte ja schon binär gelesen werden, aber sie wird irgendwie trotzdem nach dem ASCII ausgelesen.
Wie mache ich das?

Gelesen wird Byte für Byte( char für char ).
Bei der Konsolenausgabe werden char s aber eben als ASCII(bzw. die verwendete Codepage) interpretiert. Wenn Du das nicht willst könntest Du z.B. nach unsigned casten(oder gleich in unsigned lesen).
Und für die Ausgabe als Hex schau mal hier.

coder++

Danke

coder++

Wieder ein Problem
Es klappt jetzt, ich kann die einzelnen Bits sehen (1, 0) hab diese auch in dezinal Zahlen umgewandelt, aber die Datei wird immer noch als Textdatei gelesen und nicht als Binärdatei.
Warum?
Ich benutze doch ios::binary

Nathan

Es gibt nur einen Unterschied zwischen dem binary mode und dem Normalen:
Bei dem Normalen Modus werden Newlines in etwas plattformspezifisches konvertiert wie "\r\n" unter Windows. Im binary mode entfällt das. Mehr Unterschied ist da nicht.
So oder so landen am Ende in der Datei binäre Dateien, die von einem Texteditor als Zeichen interpretiert werden.

coder++

Achso.
Aber ich mein ja nur:
Wenn ich die Binärdateie mit einem normalen Texteditor öffne sehe ich nur eine Sammlung Zeichen.
Nur mit einem Hex-Editor kann ich sie richtig lesen.
Wenn ich aber versuche die Bytes einzeln einzulesen mit ifstream, dann kommt das Gleiche herraus, wie im Texteditor.

Fytch

coder++ schrieb:

Achso.
Aber ich mein ja nur:
Wenn ich die Binärdateie mit einem normalen Texteditor öffne sehe ich nur eine Sammlung Zeichen.
Nur mit einem Hex-Editor kann ich sie richtig lesen.
Wenn ich aber versuche die Bytes einzeln einzulesen mit ifstream, dann kommt das Gleiche herraus, wie im Texteditor.

die (teils unlesbaren) zeichen im texteditor sind von den werten her gleich wie die im hexeditor, nur anders dargestellt eben. wenn du also einen char aus einer datei liest und du den numerischen wert ausgeben möchtest, dann musst du den char in einen int z.b. casten. die daten sind überall (editor, hexeditor, char, int) gleich, die unterschiede liegen in der darstellung.

Caligulaminus

coder++ schrieb:

Wenn ich die Binärdateie mit einem normalen Texteditor öffne sehe ich nur eine Sammlung Zeichen.

Der Texteditor ist nunmal für Text da.
Darum stellt er die Daten als Text dar.

coder++

Das heißt, ich muss Binärdateien nicht binär lesen?
Und außerdem, kann es sein dass Hex ein anderer Standard ist?
Also dass z.B. 85 gleich "U" in ASCII ist, aber in Hex ein anderes Zeichen?

Fytch

coder++ schrieb:

Das heißt, ich muss Binärdateien nicht binär lesen?
Und außerdem, kann es sein dass Hex ein anderer Standard ist?
Also dass z.B. 85 gleich "U" in ASCII ist, aber in Hex ein anderes Zeichen?

hä, ich versteh nicht was du ausdrücken möchtest. wenn du ein byte liest, dann kann das gelesene byte gleichzeitig 85, 'U', 0x55 und 0101 0101 sein. der wert ist immer gleich, egal ob man "binär oder hex liest". (was man gar nicht unterscheiden kann in diesem kontext...)

Der Unterschied zwischen Text und Binärmodus ist, das die Umsetzung vom Zeilenende in '\n'. Unter DOS/Windows ist das Zeilenende \r\n (Carriage Return und Line Feed (newline) CR LF).
Diese Umsetzung wird im Binärmodus nicht gemacht.

Der Rest ist alles nur ein Problem der Darstellung.
ASCII kennst du ja. Da hast du 'A' oder
Bei der allgemein übliche Dezimaldarstellung 65 oder
als Hexadezimalwert zur Basis 16 ist das 0x41 oder
auch als Oktaldratsellung zur Basis 8 dann 0101 oder
als Dualzahl (Basis 2) 0b01000001

Alles nur eine andere Darstellung vom selben Wert.

coder++

Vergesst das Vorherige.
Ich habs nun vertstanden.
Und wenn ichs richtig verstanden hab, muss ich die Werte einfach nur in Hexadezimal umwandeln und schon hab ich einen Maschinencode, den ich bearbeiten kann.
Bin ich damit richtig?
Und ausserdem, woher soll ich wissen, welches Zähl-System der Prozessor benutzt?

Nathan

coder++ schrieb:

Vergesst das Vorherige.
Ich habs nun vertstanden.
Und wenn ichs richtig verstanden hab, muss ich die Werte einfach nur in Hexadezimal umwandeln und schon hab ich einen Maschinencode, den ich bearbeiten kann.
Bin ich damit richtig?
Und ausserdem, woher soll ich wissen, welches Zähl-System der Prozessor benutzt?

Nein.
Wenn du Zahlen/Buchstaben/was auch immer einliest, werden 0 und 1en (binär eben...) eingelesen und an der Adresse der Variable gespeichert. Gibts du diese binär-Daten aus, hängt das vom Typ ab, in dem sie gespeichert werden, wie sie ausgegeben werden. Die ostreams geben char als Zeichen aus und konvertieren eine Zahl in die entsprechende Folge von Zeichen.
Um beim 'A' zu bleiben. In der Datei steht 01000001. Liest du das in einem char ein, steht da auch 01000001. Gibst du das allerdings aus (via cout oder in eine Datei) wird das dem ASCII Code entsprechende Zeichen ausgegeben ('A'). Gibts du das aber als int aus, wird die Zahl 65 als zwei Zeichen '6' und '5' ausgegeben.
Der Texteditor sieht an der selben Stelle auch 01000001, ist aber eingstellt Zeichen auszugeben, deshalb siehst du 'A'.
Der Binäreditor hat ebenfalls 01000001, ist aber darauf eingstellt, das als Zahl einzulesen und diese Zahl hexadezimal auszugeben, deshalb siehst du (0x)41.
Die interne Repräsentation ist aber immer 01000001.

coder++

Sorry,dann hab ichs falsch formuliert.
So meinte ich es eig. auch.
Also ja,das heißt ich könnte dann wie in einem hex-Editor direkt den Maschinencode bearbeiten, richtig?
Und wenn man es lesen könnte, könnte man ja dann auch in einem Texteditor den Maschinencode bearbeiten, da ja nur die Darstellung eine andere ist und man halt statt den Hex-Zahlen die equalivänten Zeichen angeben müsste (wenn wir davon ausgehen, dass der ASCII nicht nur von 0-255 gehen würde), oder?

Edit: Obwohl eig. ja nur die Kommandozeichen, etc zum Verhängnis werden, da ja ein Byte nur bis zu 255 darstellen kann.

coder++ schrieb:

Und ausserdem, woher soll ich wissen, welches Zähl-System der Prozessor benutzt?

Die allermeisten Prozessoren benutzen das Dualsystem.

coder++ schrieb:

und schon hab ich einen Maschinencode,

Wenn du es lesen kannst
Unter Maschinencode versteht man die (Codiereng der) Befehle die ein Prozessor kennt. i.A wird der als (Dis)Assembler Code dargestellt.

Die Bedeutung der Werte in der Datei ergibt sich aus dem Kontext der Datei.
Man kann aus der Dateinamenerweiterung oder aus den ersten Werten der Datei (Dateiheader) darauf schließen.

ASCII geht nur bis 127.
Für mehr als 255 brauchst du auch zwei Byte. Wobei dann schon wieder die Endianess (Bytereihenfolge) eine Rolle spielt.

coder++

Aber ein Byte ist 8 Bit, dachte ich.

Nathan

coder++ schrieb:

Edit: Obwohl eig. ja nur die Kommandozeichen, etc zum Verhängnis werden, da ja ein Byte nur bis zu 255 darstellen kann.

Nun, da sie wirklich binär von einem Programm in eine Datei geschrieben ( bei 1024 wird auch wirklich die binäre Zeichenfolge - sprich: die vier Bytes aus denen der int besteht - und nicht '1', '0', '2' und '4' geschrieben), demzufolge entstehen da Byte-Blöcke und der Texteditor geht halt byteweise vor, anstatt die zusammenzupacken, ist das eig. kein Problem, du musst lediglich mehrere Zeichen ändern.
Wie DirkB schon sagte spielt Endianess dabei eine Rolle.