Register for your free account! | Forgot your password?

Go Back   elitepvpers > Coders Den > AutoIt
You last visited: Today at 19:46

  • Please register to post and access all features, it's quick, easy and FREE!

 

[AutoIt]Selfmade File Container

Reply
 
Old   #1
 
elite*gold: 0
Join Date: Oct 2008
Posts: 428
Received Thanks: 177
[AutoIt]Selfmade File Container

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



RealEmX is offline  
Old   #2
failing on a final level
 
elite*gold: 46130
Join Date: Jun 2009
Posts: 28,528
Received Thanks: 24,629
#moved


MrSm!th is offline  
Old   #3
 
elite*gold: 0
Join Date: Oct 2008
Posts: 428
Received Thanks: 177
Naja, weiß nicht ob der move so richtig ist.. geht ja auch um DLL's die sicherlich nicht mit AutoIt geschrieben werden ^^
RealEmX is offline  
Old   #4
failing on a final level
 
elite*gold: 46130
Join Date: Jun 2009
Posts: 28,528
Received Thanks: 24,629
Quote:
Originally Posted by RealEmX View Post
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.


MrSm!th is offline  
Thanks
1 User
Old   #5
 
elite*gold: 0
Join Date: Oct 2008
Posts: 428
Received Thanks: 177
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!
RealEmX is offline  
Old   #6
failing on a final level
 
elite*gold: 46130
Join Date: Jun 2009
Posts: 28,528
Received Thanks: 24,629
Quote:
Originally Posted by RealEmX View Post
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.
MrSm!th is offline  
Thanks
1 User
Old   #7
 
elite*gold: 2
Join Date: Mar 2008
Posts: 1,778
Received Thanks: 1,221
@ MrSmith

Code:
FileOpen("Pfad", 16)
öffnet jede Datei binär, und dann halt einfach mit

Code:
FileRead
den Binärstring auslesen

MfG

OT: Wie schauts mit der DLL aus? ;O
PenGuin :O is offline  
Old   #8
 
elite*gold: 1
Join Date: Feb 2009
Posts: 1,726
Received Thanks: 728
Schau dir mal einen Ressourceneditor an.
HardCore.1337 is offline  
Old   #9
 
elite*gold: 280
Join Date: May 2007
Posts: 2,817
Received Thanks: 3,479
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
lolkop is offline  
Thanks
1 User
Old   #10
 
elite*gold: 0
Join Date: Oct 2008
Posts: 428
Received Thanks: 177
Quote:
Originally Posted by MrSm!th View Post
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.

Quote:
Originally Posted by lolkop View Post
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

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)
RealEmX is offline  
Old   #11
failing on a final level
 
elite*gold: 46130
Join Date: Jun 2009
Posts: 28,528
Received Thanks: 24,629
Quote:
Originally Posted by lolkop View Post
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
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

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)
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.
MrSm!th is offline  
Old   #12
 
elite*gold: 280
Join Date: May 2007
Posts: 2,817
Received Thanks: 3,479
Quote:
Originally Posted by MrSm!th View Post
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:
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.
lolkop is offline  
Old   #13
failing on a final level
 
elite*gold: 46130
Join Date: Jun 2009
Posts: 28,528
Received Thanks: 24,629
Quote:
Originally Posted by lolkop View Post
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.
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


MrSm!th is offline  
Reply



« Previous Thread | Next Thread »

Similar Threads
Selfmade Bot Mt2 v1.1
Der neue Selfmade Bot Mt2 v1.1 ist da! Also, ich möchte hier jetzt nicht alle Funktionen aufzählen, sondern nur ein bisschen beschreiben, denn der...
10 Replies - Metin2 Hacks, Bots, Cheats, Exploits & Macros
Truecrypt Container?
Huhu, ich habe soeben meine Festplatte per Truecrypt 32 stellig verschlüsselt. Ich habe gehört das durch das encrypten einer Art Container...
2 Replies - Main
WoW Selfmade 3.1.3
#edit by Gordge
3 Replies - WoW PServer Hosting
AutoIt text file open?
Hi, bin noch recht neu im bezug scripten mit autoit, bzw. alg. . Mein Frage ist ob es irgentwie möglich ist auch Text.txt filex per Interface zu...
2 Replies - AutoIt



All times are GMT +1. The time now is 19:46.


Powered by vBulletin®
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.

Support | Contact Us | FAQ | Advertising | Privacy Policy | Abuse
Copyright ©2017 elitepvpers All Rights Reserved.