[AutoIt]Selfmade File Container

[RealEmX]

N'abend,

Ich würde gerne zum Test einen File Container basteln.
Sprich eine Datei, in der mehrere Dateien lagern:

Container.res =>
****- Bild.jpg
****- Sound.wav
****- /Dir/ =>
********-Bild2.jpg

Ich hoffe ihr versteht was ich mein x)

Aufjedenfall bin ich nach längerem googlen auf kein gutes Ergebnis gestoßen, und hab mich mal selbst dran versucht.
Alles zusammen in eine ZIP, und die ZIP (ziemlich billig) verschlüsseln, und natürlich die Dateiendung ändern.
Das funktioniert auch wunderbar auf beiden wegen (Packen/entpacken)

Nochmal zur Errinerung: Alles zum Test und auf Sicherheit leg ich hier 'noch' keinen Wert.

Aber jetzt such ich eine bessere Methode als dieses vorgehäuchle von einem Format :P
Kennt ihr einen schöneren, besseren Weg?
Natürlich in AutoIt realisierbar oder per externen DLL.

Und ja, ich lerne zurzeit VC++ also das "AutoIt-ist-kaka-bubu" Posting muss hier nicht sein :P

[MrSm!th]

#moved

[RealEmX]

Naja, weiß nicht ob der move so richtig ist.. geht ja auch um DLL's die sicherlich nicht mit AutoIt geschrieben werden ^^

[MrSm!th]

Originally Posted by RealEmX

N'abend,

Ich würde gerne zum Test einen File Container basteln.
Sprich eine Datei, in der mehrere Dateien lagern:

Container.res =>
****- Bild.jpg
****- Sound.wav
****- /Dir/ =>
********-Bild2.jpg

Ich hoffe ihr versteht was ich mein x)

Aufjedenfall bin ich nach längerem googlen auf kein gutes Ergebnis gestoßen, und hab mich mal selbst dran versucht.
Alles zusammen in eine ZIP, und die ZIP (ziemlich billig) verschlüsseln, und natürlich die Dateiendung ändern.
Das funktioniert auch wunderbar auf beiden wegen (Packen/entpacken)

Nochmal zur Errinerung: Alles zum Test und auf Sicherheit leg ich hier 'noch' keinen Wert.

Aber jetzt such ich eine bessere Methode als dieses vorgehäuchle von einem Format :P
Kennt ihr einen schöneren, besseren Weg?
Natürlich in AutoIt realisierbar oder per externen DLL.

Und ja, ich lerne zurzeit VC++ also das "AutoIt-ist-kaka-bubu" Posting muss hier nicht sein :P

Also du willst dein eigenes Format machen und keins vorheucheln und auch nicht ZIP benutzen?
Dann machs doch einfach so wie in deinem Beispiel.

Du liest jede Datei stumpf ein und schreibst die Inhalte nacheinander in dein Container File rein.
Dann kannst du zb. ganz am Anfang eine Art File Header machen, in dem enthalten ist, was alles im Container ist.
Also Name, Endung und Größe der Dateien.
Dann kannst du zum entpacken den Container auslesen, dann den Header und alle Files wieder erstellen und dann mithilfe der gespeicherten Größen die einzelnen Dateien im Container trennen.
Das ist natürlich recht ineffizient und es gibt sicher diverse bessere Header Methoden und man könnte auch noch Komprimierung einbauen und und und...aber das würde ja hier den Rahmen sprengen, du willst es ja nur erstmal testen.

Sicher muss so ein Container btw nicht sein, sicher soll er ja nur sein, wenn es ein verschlüsselter Container, wie .RAR mit PW o.Ä. ist, ansonsten ist eine Verschlüsselung, selbst wenn sie kompliziert ist, relativ sinnfrei, wenn es nur um nen simplen Container geht.

[RealEmX]

Hmm..
Schöne Idee.. wieso bin ich da nicht drauf gekommen *vor'n Kopf hau*
Aber gehen dabei nicht Informationen recht schnell flöten?
Im Grunde ist es ja nicht andres als wenn ich einem Bild die Endung .txt gebe.. Kann mir nicht vorstellen das alle Informationen erhalten bleiben. Aber ich probiere es sicherlichlich aus, den schwer zu realisieren ist's ja auch nicht.
Danke!

[MrSm!th]

Originally Posted by RealEmX

Hmm..
Schöne Idee.. wieso bin ich da nicht drauf gekommen *vor'n Kopf hau*
Aber gehen dabei nicht Informationen recht schnell flöten?
Im Grunde ist es ja nicht andres als wenn ich einem Bild die Endung .txt gebe.. Kann mir nicht vorstellen das alle Informationen erhalten bleiben. Aber ich probiere es sicherlichlich aus, den schwer zu realisieren ist's ja auch nicht.
Danke!

1. nein, du kannst auch eine .exe in eine .txt umbenennen, es ist ja nur der name. wenn du sie im editor öffnest und dann speicherst, wird evtl. was verloren gehen, ich weiß nicht, wie der windows editor das händelt, ob er daten, die er nicht anzeigen kann trotzdem beibehält oder dann nur den text speichert, aber das ist ja egal. du liest die binären daten ein und schreibst sie in eine eigene datei.
2. was du natürlich nicht machen darfst, ist die daten in einen text in deinem programm zu formatieren. du musst sie natürlich binär einlesen und so auch in den container schreiben.
ich weiß nicht, ob autoit standardmäßig jede datei als textdatei behandelt, aber selbst wenn, man wird ja sicher auch irgendwie binär arbeiten können.

[PenGuin :O]

@ MrSmith

FileOpen("Pfad", 16)

öffnet jede Datei binär, und dann halt einfach mit

FileRead

den Binärstring auslesen

MfG

OT: Wie schauts mit der DLL aus? ;O

[HardCore.1337]

Schau dir mal einen Ressourceneditor an.

[lolkop]

ein container ist relativ leicht zu realisieren. ich würde das ganze immer mit header teil aufbauen, indem alle im container vorhandenen files gelistet werden, mit startadresse, größe und dateiname. das ganze dann noch in einem schönen format unterbringen und man kann sogar sehr schnell auf die files im container zugreifen.

beispiel für max 255 files (mit jeweils max 4gb größe) im container:

Header
   [Allgemein]
    1 Byte -> Anzahl enthaltener files
   [Für jedes file]
    4 Byte -> Namenslänge
    Namenslänge Byte -> Name
    4 Byte -> Position
    4 Byte -> Größe
Files

man könnte das ganze auch ohne header teil machen, und einfach alle files getrennt durch bestimmte hex combos speichern, hat dann aber unter umständen bei großen containern effizienzprobleme

[RealEmX]

Originally Posted by MrSm!th

1. nein, du kannst auch eine .exe in eine .txt umbenennen, es ist ja nur der name. wenn du sie im editor öffnest und dann speicherst, wird evtl. was verloren gehen, ich weiß nicht, wie der windows editor das händelt, ob er daten, die er nicht anzeigen kann trotzdem beibehält oder dann nur den text speichert, aber das ist ja egal. du liest die binären daten ein und schreibst sie in eine eigene datei.
2. was du natürlich nicht machen darfst, ist die daten in einen text in deinem programm zu formatieren. du musst sie natürlich binär einlesen und so auch in den container schreiben.
ich weiß nicht, ob autoit standardmäßig jede datei als textdatei behandelt, aber selbst wenn, man wird ja sicher auch irgendwie binär arbeiten können.

Das Informationen verloren gehen wenn ich datei mit einem Texteditor speichere war mir schon klar^^ Ging nur um den Weg, den AutoIt da nimmt, aber wenn alles Binär abläuft ist ja alles in Ordnung.

Originally Posted by lolkop

ein container ist relativ leicht zu realisieren. ich würde das ganze immer mit header teil aufbauen, indem alle im container vorhandenen files gelistet werden, mit startadresse, größe und dateiname. das ganze dann noch in einem schönen format unterbringen und man kann sogar sehr schnell auf die files im container zugreifen.

beispiel für max 255 files (mit jeweils max 4gb größe) im container:

Header
   [Allgemein]
    1 Byte -> Anzahl enthaltener files
   [Für jedes file]
    4 Byte -> Namenslänge
    Namenslänge Byte -> Name
    4 Byte -> Position
    4 Byte -> Größe
Files

man könnte das ganze auch ohne header teil machen, und einfach alle files getrennt durch bestimmte hex combos speichern, hat dann aber unter umständen bei großen containern effizienzprobleme

Ich werd's ersteinmal der Einfachheit ohne Header machen, dann später versuchen einen Header reinzuhau'n. Wobei ich lieber den Header extern lagern würde... Warum auch immer x)

[MrSm!th]

Originally Posted by lolkop

ein container ist relativ leicht zu realisieren. ich würde das ganze immer mit header teil aufbauen, indem alle im container vorhandenen files gelistet werden, mit startadresse, größe und dateiname. das ganze dann noch in einem schönen format unterbringen und man kann sogar sehr schnell auf die files im container zugreifen.

beispiel für max 255 files (mit jeweils max 4gb größe) im container:

Header
   [Allgemein]
    1 Byte -> Anzahl enthaltener files
   [Für jedes file]
    4 Byte -> Namenslänge
    Namenslänge Byte -> Name
    4 Byte -> Position
    4 Byte -> Größe
Files

man könnte das ganze auch ohne header teil machen, und einfach alle files getrennt durch bestimmte hex combos speichern, hat dann aber unter umständen bei großen containern effizienzprobleme

Und man könnte das ganz große Pech haben, dass die Hex Combo in einem der Files enthalten ist ;O

Nein, nein, die Header Methode ist schon recht sinnvoll und so, wie du ihn aufgebaut hast, finde ich das recht gut für ne Anfangsübung
Man kanns natürlich immer komplizierter machen ;O

Ich werd's ersteinmal der Einfachheit ohne Header machen, dann später versuchen einen Header reinzuhau'n. Wobei ich lieber den Header extern lagern würde... Warum auch immer x)

Glaub mir, einfacher ists mit Header.
Zumindest die Größe der Files und Namen (Namen sowieso, sonst weißte ja nicht, wie die Files heißen und was sie sind o.ô), damit kannst du ganz einfach die Files trennen.
Wenn man noch die Anzahl der Files einbaut, ists noch besser.
Jedenfalls einfacher als ohne Header...reicht ja was ganz simples, wenn du es nicht Byte genau machen willst, schreibst du einfach nacheinander Anzahl und dann File Name, File Size, File Name, File Size, ... rein und kannst dann immer die Files durch Addition der Größen trennen.

[lolkop]

Originally Posted by MrSm!th

Und man könnte das ganz große Pech haben, dass die Hex Combo in einem der Files enthalten ist ;O

Nein, nein, die Header Methode ist schon recht sinnvoll und so, wie du ihn aufgebaut hast, finde ich das recht gut für ne Anfangsübung
Man kanns natürlich immer komplizierter machen ;O


Glaub mir, einfacher ists mit Header.
Zumindest die Größe der Files und Namen (Namen sowieso, sonst weißte ja nicht, wie die Files heißen und was sie sind o.ô), damit kannst du ganz einfach die Files trennen.
Wenn man noch die Anzahl der Files einbaut, ists noch besser.
Jedenfalls einfacher als ohne Header...reicht ja was ganz simples, wenn du es nicht Byte genau machen willst, schreibst du einfach nacheinander Anzahl und dann File Name, File Size, File Name, File Size, ... rein und kannst dann immer die Files durch Addition der Größen trennen.

ohne anzahl der files kann man die file liste schlecht bis garnicht durchlaufen.
dadurch das die namenslänge keine feste größe hat, kann man auch nicht einfach provisorisch eine größe für den header festlegen.
genau deswegen sind die größenvariablen schon mit das wichtigste. das ganze kann man natürlich noch einmal mehr verschachteln, indem man noch die ordner mit einbaut. denke mal das braucht man hier nichtmehr zu erklären, da es quasi der selbe aufbau ist, wie der der files, mit dem unterschied das diese halt nur logisch vorhanden sind, und nicht mit im container hinterlegt werden müssen.
was noch eine überlegung wert wäre, wäre vielleicht eine checksumme, die packfehler verhindern könnte.

naja und zu dem thema ohne header meinte ich eher, das man vor dem file nur die größe als integer (4 byte) angibt und vielleicht noch name. so können dabei keine fehler auftreten.

quasi:

[File1]
4byte -> größe
4byte -> namenslänge
namenslänge byte -> name
File1
[File2]
4byte -> größe
4byte -> namenslänge
namenslänge byte -> name
File2
...

der nachteil an dieser methode wäre, dass man viele jumps einbauen muss, von file zu file um allein den inhalt aufzulisten.
desweiteren ist auch das löschen/bearbeiten von files so recht umständlich, dafür aber das hinzufügen neuer files deutlich schneller.

[MrSm!th]

Originally Posted by lolkop

ohne anzahl der files kann man die file liste schlecht bis garnicht durchlaufen.
dadurch das die namenslänge keine feste größe hat, kann man auch nicht einfach provisorisch eine größe für den header festlegen.
genau deswegen sind die größenvariablen schon mit das wichtigste. das ganze kann man natürlich noch einmal mehr verschachteln, indem man noch die ordner mit einbaut. denke mal das braucht man hier nichtmehr zu erklären, da es quasi der selbe aufbau ist, wie der der files, mit dem unterschied das diese halt nur logisch vorhanden sind, und nicht mit im container hinterlegt werden müssen.
was noch eine überlegung wert wäre, wäre vielleicht eine checksumme, die packfehler verhindern könnte.

naja und zu dem thema ohne header meinte ich eher, das man vor dem file nur die größe als integer (4 byte) angibt und vielleicht noch name. so können dabei keine fehler auftreten.

quasi:

[File1]
4byte -> größe
4byte -> namenslänge
namenslänge byte -> name
File1
[File2]
4byte -> größe
4byte -> namenslänge
namenslänge byte -> name
File2
...

der nachteil an dieser methode wäre, dass man viele jumps einbauen muss, von file zu file um allein den inhalt aufzulisten.
desweiteren ist auch das löschen/bearbeiten von files so recht umständlich, dafür aber das hinzufügen neuer files deutlich schneller.

1. man könnte eine maximale länge an zeichen für den namen nehmen und den rest mit 0en füllen, dann sollte das kein problem sein
2. wenn man das in ner schleife macht kann man einfach bis EndOfFile auslesen und die files entpacken
aber wie gesagt, zumindest größe der files, name und anzahl sollte drin sein, länge des namens ist optional (man kann sich ja auch ein trennzeichen machen, das den namen vom nächsten header trennt)

wie gesagt, das ist eben alles sachen der eigenen vorstellung, was unumgänglich ist, ist aber der name und entweder die file size oder eine trennkombination zwischen den files