Tutorial Arbeiten mit Dateien auf binärer Ebene

[Fehlersucher]

Hallo,

wo findet man ein Tutorial wie ich mit Dateien auf binärer Ebene arbeite. Also z.B. welche Möglichkeiten es gibt Dateien binär auszulesen etc.

Gruß

[Klaus01]

Hallo,

eine Datei ist immer binär abgelegt.
Wenn Du die Datei einliesst legst Du fest wie diese Daten interpretiert werden sollen.

Die kleinst Einheit die Du einlesen kannst ist ein Byte.
Das kannst Du mit read(file,b) wenn Deine Datei vom Type file of Byte ist.
Du kannst auch ein TFileStream benutzen und diesen dann byte-weise auslesen.

Grüße
Klaus

[Fehlersucher]

Ich würde gerne alle möglichen Dateien binär auslesen und mich ein bisschen mehr mit dem Thema beschäftigen.

Kann man den File Stream auch in einen String schreiben, oder macht das keinen Sinn?

Was würde im String stehen? Eine Zahlenreihe mit den Ziffern 0 bis 9?

Gibt es auch ausführliche Tutorials dazu?

Gruß

[p80286]

Zitat:

Zitat von Klaus01 (Beitrag 1200111)

Hallo,

eine Datei ist immer binär abgelegt.
Wenn Du die Datei einliesst legst Du fest wie diese Daten interpretiert werden sollen.

Dem ist nichts hinzuzufügen. Nur das "File of Byte" würde ich als theoretische Möglichkeit abhaken. Das Mittel der Wahl ist meiner Meinung nach TFilestream.

Was hast Du denn konkret vor?

Gruß
K-H

[jfheins]

Du kannst einen Filestream in Delphi problemlos in einen Ansistring einlesen. Und es steht dann der Dateiinhalt darin. das ist vergleichbar mit dem öffnen der Datei per Notepad.

Wenn du also eine XML-Datei in den String einließt kommt wohl ungefähr sowas dabei raus:

Zitat:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>◘◙<verzeichnis>◘◙ <titel>Wikipedia Städteverzeichnis</titel>..........

(Zeilenumbrüche habe ich jetzt mal ersetzt, sehen aber so ähnlich aus)

Bei einer exe Datei ganz viele nicht darstellbare Zeichen ;-)

[Luckie]

Suchst du eventuell so was?
http://michael-puff.de/Programmierun...exLoader.shtml

[Fehlersucher]

Nein, ich will an die einsen und nullen einer Datei kommen und diese möglichst in einem String oder so haben.

Gruß

[Sir Rufo]

Zitat:

Zitat von Fehlersucher (Beitrag 1200850)

Nein, ich will an die einsen und nullen einer Datei kommen und diese möglichst in einem String oder so haben.

Gruß

Häh? Das ist doch nur eine andere Schreibweise (im Dualsystem).

[MeierZwoo]

Zitat:

Zitat von Fehlersucher (Beitrag 1200850)

Nein, ich will an die einsen und nullen einer Datei kommen und diese möglichst in einem String oder so haben.

Es gibt keine "Einsen" und "Nullen" in einer Datei (oder im RAM oder ..), sondern nur bits - und deren Wert ist als 1 (gesetzt) oder 0 (ungesetzt) definiert - aber eben auch nur definiert.

Die Darstellung eines Bytes (zB) als binär "00110001" oder Hex "31" oder dezimal 49 ist doch nur für uns doofe Menschen so gebräuchlich, weil wir sonst garnichts kapieren würden.

Wenn Du in einem String die Darstellung der Werte der bits als "0" und "1" haben möchtest, dann mußt du die Werte der einzelnen Bits in chars "0" bzw. "1" umwandeln und in den String schreiben. Gut dir eine/deine Datei in einen HexEditor an, dann siehst Du, was gemeint ist.

Wenn Du in dem String aber die Werte der Bytes haben möchtest, brauchst du doch nur das Eingelesene in den String schieben oder gleich in einen String einlesen oder eine Typumwandlung in String machen (unter Beachtung des Längensetzens des Strings).

[Popov]

Zitat:

Zitat von Fehlersucher (Beitrag 1200850)

Nein, ich will an die einsen und nullen einer Datei kommen und diese möglichst in einem String oder so haben.

Also wie schon gesagt, das Laden sollte in ein String klappen. Hier ein Beispiel (wenn es ein String sein soll):

Delphi-Quellcode:

function LoadStringFromFile(AFilePath: String; var AFileString: AnsiString): Boolean;
var
  FileStream: TFileStream;
begin
  Result := False;
  if not FileExists(AFilePath) then Exit;
  FileStream := TFileStream.Create(AFilePath, fmOpenRead);
  try
    if FileStream.Size <> 0 then
    begin
      SetLength(AFileString, FileStream.Size);
      FileStream.Read(AFileString[1], FileStream.Size);
      Result := True;
    end;
  finally FileStream.Free end;
end;

function SaveStringToFile(AFilePath: String; AFileString: AnsiString): Boolean;
var
  FileStream: TFileStream;
begin
  Result := False;
  FileStream := TFileStream.Create(AFilePath, fmCreate);
  try
    if Length(AFileString) <> 0 then
    begin
      FileStream.Write(AFileString[1], Length(AFileString));
      Result := True;
    end;
  finally FileStream.Free end;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  Path: String;
  TestString: AnsiString;
begin
  Path := ExtractFilePath(ParamStr(0));
  LoadStringFromFile(Path + 'Datei-A.exe', TestString);
  SaveStringToFile(Path + 'Datei-B.exe', TestString);
end;

Das mit den Nullen und Einsen ist ein anderer Part. Da kannst du je nachdem die Bits eines Bytes auslesen, z. B. mit AND.

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

Zitat von Fehlersucher (Beitrag 1201360)

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:

Zitat von Fehlersucher (Beitrag 1201360)

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:

Zitat von MeierZwoo (Beitrag 1201369)

Zitat:

Zitat von Fehlersucher (Beitrag 1201360)

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:

Zitat von Fehlersucher (Beitrag 1201376)

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:

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!

[p80286]

Es ist alles eine Frage der Interpretation.
Unangenehm wird es da, wo jemand annimmt seine Interpretation wäre die einzig richtige.

Gruß
K-H

[Popov]

Zitat:

Zitat von Aphton (Beitrag 1201401)

Ich bin sehr erfreut darüber, dass die meisten hier nun wissen, ...

Bei der Gelegenheit: Es gibt nur 10 Typen von Menschen, solche die binär verstehen und solche die kein binär verstehen!

[Fehlersucher]

Was loht sich denn bei der Lauflängenkodierung mehr?

Ein Wort aus einer Textdatei direkt zu komprimieren, oder es erst binär umzuschreiben und dann zu komprimieren?

[Furtbichler]

Zitat:

Zitat von Fehlersucher (Beitrag 1201536)

Ein Wort aus einer Textdatei direkt zu komprimieren, oder es erst binär umzuschreiben und dann zu komprimieren?

Was verstehst Du unter 'Wort direkt komprimieren' und unter 'in binär umzuschreiben'?

[Fehlersucher]

Ich meine die chars direkt zu komprimieren oder die chars erst in 0 und 1 umschreiben und dann von 0 und 1 die Lauflängencodierung zu machen.

[jfheins]

Bei der letzten Variante fängst du glatt mal mit der 8 fachen Datenmenge an. Der erste Schritt wäre, die redundanz zu reduzieren indem man 8 Symbole in ein Byte zusammen fasst und damit schon eine Kompression um 87,5% erreicht ;-)

[Aphton]

Beispiel:

Inhalt der Textdatei
"ABCD"

Inhalt nach einer "Übersetzung in binär"
"01000001010000100100001101000100"

Die Länge ist von 4 auf 4 * 8 gestiegn, also um 800%.

[jfheins]

Zitat:

Zitat von Aphton (Beitrag 1201553)

Ich bin mir nicht sicher, aber intuitiv vermute ich (es gibt bestimmt iwelche Theorien dazu), dass die Entropie sich bei einer 1:1 Übersetzung nicht ändert.

Dafür gibt es sogar eine Einheit :mrgreen: (habe ich aber auch gerade erst entdeckt...)

Wenn ich jetzt mal ein Alphabet ausschließlich aus A-Z Großbuchstaben annehme, dann hat die Nachricht "ABCD" einen Informationsgehalt von 4,7 Shannon pro Zeichen. man benötigt also 5 Bits um ein Zeichen zu übertragen, bzw. 5*4=20 bits für die ganze Nachricht.

Für die Alternative Nachricht wären das 1 bit pro Zeichen = 32bits für die ganze Nachricht.
Ich würde sagen, Ziel verfehlt :stupid:

Wenn man das jetzt noch RLE codiert kommt da sowas raus:
10 11 40 10 11 10 11 40 11 20 11 40 21 10 11 30 11 20

Das könnte man schön speichern, man kommt pro Wiederholungseinheit mit 4 bits aus. (Die erst Zahl minus 1 speichern braucht 3 bits und das Datenbit)
das macht bei 36 Wiederholungseinheiten glatt 144 bits. Hört sich nach einer Klasse Idee an :mrgreen:

Für die Originalnachricht wurden übrigens 4 Bytes = 32 bits verwendet. Die RLE hat die Nachricht also auf das 4,5 fache aufgebläht!

[Fehlersucher]

Sollte man bei dem Algorithmus lieber mit 0 und 1 arbeiten, oder doch lieber normale chars des Alphabets?

[jfheins]

Tja, das ist jetzt die Frage was du machen möchtest. Ein allgemein anwendbarer Algorithmus zur Datenkompression sollte mit Bytes arbeiten.

Falls du deine Eingabedaten kennst und weißt dass es sich nur um Zeichen des Alphabets handelt kannst du noch mehr machen: Kodiere die Buchstaben in 6 bits (also 64 verschiedene Zeichen) und danach kannst du einen allgemeinen Standardalgorithmus drüberlaufen lassen.

Verlustbehaftete Kompression ist nochmal ein anderes Thema, das braucht man dann hauptsächlich bei Audio und Video, eher nicht bei Text.