[AutoIt]Selfmade File Container

Quote:

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

Quote:

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!

Quote:

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.

Quote:

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

Quote:

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

Quote:

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)

Quote:

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.

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

Quote:

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