Windows-Scriptsprache mit Binärdatei-Funktionalität ?

Script Host mit VB- oder JScript steht ja zur Verfügung, aber ...

... kein Datei-Zeiger, kein Lesen oder Schreiben von Teilsequenzen.
Schade drum, JavaScript als hinreichend prägnante Sprache und das vorinstalliert auf allen aktuellen Versionen wäre schon 'ne schöne Sache gewesen.

Muss wohl für 'ne wirklich professionelle Lösung ein Drittanbieter her. Irgendwelche Erfahrungen, insbesondere mit den Implementierungen von Perl ( ActivePerl ) oder Php ?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 153166

Url: https://administrator.de/contentid/153166

Ausgedruckt am: 23.11.2024 um 06:11 Uhr

16 Kommentare

Neuester Kommentar

Moin StefanSch,

willkommen im Forum.
Natürlich geht es mich überhaupt nichts an, aber....

Magst du nicht wenigstens andeuten, für welches Vorhaben du ein geeignetes Werkzeug brauchst?

Ich meine, wenn ich in einem Baumarkt an der Information frage "Was haben Sie denn so für Werkzeug sofort zum Mitnehmen?"

... das Gespräch kann dann entweder sehr sehr kurz oder sehr sehr lang werden..

Ich kann dich heute leider nicht direkt in den Papierkorb geleiten, weil ein SpamBot gerade den Einlass dauerblockiert, sorry...

Aber wenn du es innerhalb der nächsten 2 Stunden nicht schaffst, die Frage auf "zielführend beantwortbar" umzuformulieren, dann finde ich ein Hintertürchen.

Grüße
Biber

und um dir mal ne kleine hilfe zu geben:

Perl / PHP sind idR nicht bei Windows dabei...

Warum nicht Java? Ne JRE hast du oftmals schon dabei....

Aber es wäre natürlich hilfreich zu wissen was du möchtest... Und nen kleiner Tipp: VOR deinem nächsten Posting les es bitte nochmal durch! Denn ich verstehe nicht wirklich was du möchtest... Und ich hoffe du schaffst das innerhalb der 2h-Einlass-Sperre von unserem Freund mit den scharfen Zähnen...

JavaScript als hinreichend prägnante Sprache und das vorinstalliert auf allen aktuellen Versionen wäre schon 'ne schöne Sache gewesen.

JavaScript ist vorinstalliert als OS-Scriptsprache.
Das heißt dort nur JScript.

Und mal ehrlich: Mit VBS oder PowerShell hast du Zugriff auf nahezu alle wichtigen Klassen und das betrifft auch Dateien.

Hmmm, OK. Ich versuch's nochmal : Suche für die Windows-Plattform eine Scriptsprache, die die üblichen Funktionen zur Handhabung von Binärdateien unterstützt. Also Datei-Zeiger positionieren, Datensequenzen an beliebiger Stelle auslesen und überschreiben. So wie man das von C eben kennt und das beispielsweise Plattform-übergreifend in Php eingebunden ist. Aber interpretiert, nicht kompiliert.
Und noch besser wäre, wenn auch andere grundlegende C-Funktionalitäten ( z.B. Sockets ) implementiert sind. Ich möchte einfach nicht anfangen, eine Skriptsprache auf Kundenrechner zu installieren und mich damit auseinandersetzen, um dann bei der nächsten Problemstellung zu sehen, dass die Implementierung grundsätzliche Lücken aufweist.

Aber ich denke, Java ist da genau die richtige Idee.

Zum konkreten Anwendungsproblem schreib ich vielleicht noch, da muss ich etwas ausholen.

Dass JavaScript unter Windows als vorinstallierte Skriptsprache eingesetzt wird, fand' ich auch 'ne richtig gute Sache. Die Sprache kann gleichzeitig in einem ganz anderen Bereich ( Webb-Anwendungen ) eingesetzt werden, bietet Objekt-Orientierung und Eleganz.

Hab' aber lang recherchiert, ob nicht irgendwie kleine Datensequenzen in großen Dateien ausgelesen und überschrieben werden können ( AODB oder mit Tricks über FileSystemObject ) - leider aber keine Chance. Vielleicht hab' ich da aber auch was übersehen ...

Konkret hab' ich auf der einen Seite einen Rechner, auf dem regelmäßig inkrementelle Sicherungen durchgeführt werden. Die inkrementellen Sicherungen werden dann über eine relativ langsame Verbindung auf einen Server übertragen.
Ich kann nun in größeren Abständen mit dem Archivierungsprogramm die fortlaufenden Sicherungen zusammenfassen. Das macht den Sicherungsvorgang wieder deutlich schneller und reduziert die Archiv-Größe soweit, dass der vorhandene Speicherplatz auf Jahre reichen dürfte. Das neue Basis-Archiv jetzt auf den Server zu übertragen, ist allerdings keine Option - das würde über's Netz Wochen brauchen oder erfordern, dass ich immer wieder für Stunden vor Ort erscheine.

Auf dem Server kann ich aber die gleiche Zusammenfassung durchführen und als Basis für die neu erstellten inkrementellen Sicherungen einsetzen - wenn ich die wenige Byte großen Kopf- und Fußbereiche der Klienten-Datei auf die knapp 100GB große Server-Datei übertrage.

Jetzt brauche ich für Windows eine interpretierte Programmiersprache, die die dazu notwendigen 5 Zeilen Quelltext umsetzen kann. Und nach Möglichkeit auch bei Dingen wie dem Starten von Programmen, der Entgegennahme von Ausgaben, der Einbindung der GUI und der Verwendung der Socket-Schnittstelle nicht den Löffel abgibt.

So gut in manchen Dingen die Microsoft-eigene JScript Implementierung ist, bei Binärdaten scheint sie komplett zu versagen. Mit Java dürfte ich dahingegen durchweg auf der sicheren Seite sein. Und wie Du erwähnt hast, die Laufzeitumgebung ist häufig schon vorhanden.
Perl müsste prinzipiell auch den Funktionsumfang haben. Wie gut die - auf jeden Fall erst zu installierende - Implementierung unter Windows ( ggf. als ActivePerl in Windows Script Host eingebunden ) ist, kann ich aber kaum abschätzen.

Hallo StefanSch!

Hier mal ein VBS-Beispiel, wie man per FileSystemObject und ADODB.Stream auch binäre Dateien bearbeiten kann.

Schritt 1: Eine 256-Byte große Test.Bin-Datei erzeugen mit den Werten von 00h - FFh
Schritt 2: Eine 16-Byte große Kopf.Bin-Datei erzeugen Hex-Werte von Ascii-Zeichen A-P
Schritt 3: Eine 16-Byte große Fuss.Bin-Datei erzeugen Hex-Werte von Ascii-Zeichen a-p
Schritt 4: Binary-Kopf.Bin-Datei in Byte-Array einlesen
Schritt 5: Binary-Test.Bin-Datei ab Position SkipBeg bis SkipEnd in Byte-Array einlesen
Schritt 6: Binary-Fuss.Bin-Datei in Byte-Array einlesen
Schritt 7: Byte-Arrays Ausgabe.Bin-Datei schreiben

Const TestFile = "E:\Test\Test.Bin"  
Const KopfFile = "E:\Test\Kopf.Bin"  
Const FussFile = "E:\Test\Fuss.Bin"  
Const BinFile = "E:\Test\Ausgabe.Bin"  

Const SkipKopf = 16
Const SkipFuss = 16

Const adTypeBinary = 1
Const adSaveCreateOverWrite = 2

Dim Fso, File, BinStream, TextStream, BinArray, KopfArray, FussArray, i
    
Set Fso = CreateObject("Scripting.FileSystemObject")  

'Schritt 1 (Test.Bin erstellen)  
For i = 0 To &HFF&  'Ergibt Bin 00h - FFh (256-Byte)  
    TextStream = TextStream & Chr(i)
Next
    
Set File = Fso.CreateTextFile(TestFile)

File.Write TextStream:  File.Close
    
'Schritt 2 (Kopf.Bin erstellen 16-Byte)  
TextStream = ""  

For i = 0 To SkipKopf - 1  'Ergibt Bin 41h(A), 42h(B), 43h(C)...50h(P)  
    TextStream = TextStream & Chr(i + Asc("A"))  
Next

Set File = Fso.CreateTextFile(KopfFile)

File.Write TextStream:  File.Close

'Schritt 3 (Fuss.Bin erstellen 16-Byte)  
TextStream = ""  
For i = 0 To SkipFuss - 1  'Ergibt Bin 61h(a), 62h(b), 63h(c)...70h(p)  
    TextStream = TextStream & Chr(i + Asc("a"))  
Next

Set File = Fso.CreateTextFile(FussFile)

File.Write TextStream:  File.Close
    
Set BinStream = CreateObject("ADODB.Stream")  
    
With BinStream
    'Schritt 4 (Kopf.Bin einlesen)  
    .Type = adTypeBinary
    .Open
    .LoadFromFile KopfFile
     KopfArray = .Read
    .Close
   
    'Schritt 5 (Test.Bin einlesen 224-Byte)  
    .Open
    .LoadFromFile TestFile
    .Position = SkipKopf
     BinArray = .Read(.Size - SkipKopf - SkipFuss)
    .Close
   
    'Schritt 6 (Fuss.Bin einlesen)  
    .Open
    .LoadFromFile FussFile
     FussArray = .Read
    .Close
    
    'Schritt 7 (Ausgabe.Bin schreiben)  
    .Open
    .Write KopfArray
    .Write BinArray
    .Write FussArray
    .SaveToFile BinFile, adSaveCreateOverWrite
    .Close
End With

Gruß Dieter

Danke für Deine Antwort. Mein Problem dabei : 'BinArray' ist knapp 100 GB groß. Das schafft kein Arbeitsspeicher

Ich brauche also definitiv einen Datei-Zeiger bzw. eine Positionsangabe für Lese- bzw. Schreibvorgänge.

Ganz abgesehen davon erspart uns das ja auch jede Menge Schreibarbeit. Mit Rexx ( auf Os/2, stammt noch aus der Betriebssystem-Steinzeit, war aber von Anfang an eine vollwertige Skriptsprache ) sieht die Lösung der Aufgabe beispielsweise so aus :

   iFnS = '\\klient\pfad\in.tib' ; oFnS = '\\server\pfad\out.tib' ;  
   hzI = 36 ; fzI = 32 ; /*## Groesze Kopf- und Fuszbereich ##*/
   rS = Stream( iFnS, 'c', 'open read' ) ; rS = Stream( oFnS, 'c', 'open write' ) ;  
   fpI = Stream( iFnS, 'c', 'query size' ) + 1 - fzI ;   /*## Position Fusz ##*/  
   rS = CharOut( oFnS, CharIn( iFnS, 1, hzI ), 1 ) ;    /*## Transfer Kopf ##*/
   rS = CharOut( oFnS, CharIn( iFnS, fpI, fzI ), fpI ) ;    /*## Transfer Fusz ##*/
   rS = Stream( iFnS, 'c', 'close' ) ; rS = Stream( oFnS, 'c', 'close' ) ;  

Hallo StefanSch!

Das war auch nur als generelles Beispiel gedacht. Und mal davon abgesehen, dass kein Arbeitsspeicher 100 GB schafft, ist auch der Dateizeiger auf Long begrenzt.

Gruß Dieter

Wie ? Aber bitte doch nicht auf einem Betriebssystem das Dateien > 2GB unterstützt ? Das muss doch als longlong implementiert sein !

Hallo StefanSch!

Ok, wenn Du Recht hast und es ein LongLong-Zeiger ist, kannst Du mit ADODB trotzdem keine so großen Dateien einlesen.

Gruß Dieter

Hmmm. Wenn ich die Dokumentation von 'ADODB.Stream' aber richtig verstanden habe, lädt die Methode
'.LoadFromFile' beim Aufruf die gesamte Datei in den Arbeitsspeicher ( siehe z.B.
http://msdn.microsoft.com/en-us/library/m ... ). Kann mich natürlich irren.
Ansonsten wär' das mit dem Block-weisen einlesen 'ne Idee. Werd's mal ausprobieren und berichten ...

Hallo StefanSch!

Zitat von @StefanSch:
Hmmm. Wenn ich die Dokumentation von 'ADODB.Stream' aber richtig verstanden habe, lädt die Methode
'.LoadFromFile' beim Aufruf die gesamte Datei in den Arbeitsspeicher ( siehe z.B.
http://msdn.microsoft.com/en-us/library/ms677570(VS.85).aspx ). Kann mich natürlich irren.
Ansonsten wär' das mit dem Block-weisen einlesen 'ne Idee. Werd's mal ausprobieren und berichten ...

Meinen letzten Kommentar oben geändert:
Habe das mit dem Blockweisen einlesen mit einer Image-Datei versucht (ca 17GB), aber das funktioniert nicht, weil ADODB offensichtlich versucht, die komplette Datei in den Arbeitsspeicher zu laden

Gruß Dieter

Hallo nochmal!

Andere Möglichkeit wäre vielleicht die Datei erst mit einem Datei-Splitter in 1-GB Blöcke zu zerlegen, zu ändern und wieder zusammenzufügen?

Hab's mal mit Windows-GSplit 3.0.1 und einer ca 21 GB-großen Datei in 1GB-Blöcken versucht und funktioniert recht gut.

http://software-portal.faz.net/windows/dateien-splitten-664

Gruß Dieter