Hex Strings schneller bearbeiten

TimBlo

Hi

ich habe nur ein kleines problem, aber es ist möglich dass es keine lösung gibt

ich habe einen String wo der inhalt einer datei drin ist, und das halt in Hexzeichen.
also immer 2 zeichen gehören zusammen.
an diesem string will ich herumbasteln, aber das dauert mit AutoIt im bereich von Megabyten schon sehr lange.
normalerweise werden strings bei StringRegExp, StringRegExpReplace und StringReplace immer ein zeichen nach dem anderen verarbeitet.
aber dabei werden ja halbe Bytes überprüft, und das ist, finde ich, schon ein schrecklicher gedanke.
gibt es iirgend nen ausweg?

**Andy**

Hi,
zunächst einmal: kein normaler Mensch speichert "Hex"-Zeichen in einer Datei ab! Wieso? Weil das doppelt so viel Speicherplatz braucht!

Falls das das aus irgendwelchen seltsamen Gründen doch jemand machen sollte, kannst du mit

[autoit]

binarytostring

[/autoit]

daraus einfach bytes machen.

Oder liest du etwa aus einer Binärdatei Zeichen aus und die erscheinen als "hex"?

TimBlo

memememe

das sind normale dateien, keine textdaten
also sind daten die man mitm editor zb. nicht bearbeiten kann

wenn ich auslese habe ich dann ja nen "0x..." string
mache beim lesen&schreiben einfach binarymode. ich habe ja haufenweise nicht druckbare zeichen

auf jeden fall gehts bei autoit ewig, möchte das wenn möglich schneller haben.
da is mir eben aufgefallen dass nur 2 zeichen aus dem hex-string ein byte geben, aber autoit weiss das doch nicht und kombiniert daher eig jedes zweite mal halbe bytes..

**BugFix**

TimBlo: Leider mal wieder ein absolutes Negativbeispiel der Fragekultur.
Du erzählst, was leider nicht geht, ohne uns zu zeigen mit welchem Code du versuchst an das Problem heranzugehen.
Ein typischer Fall von: Wasch mich - aber mach mich nicht naß. :wacko:

TimBlo

ich stelle meine fragen in etwa immer so.
seid ihr euch eig gewohnt von mir - was auch immer das für gründe haben mag

ausserdem weiss ich nicht wieviel mehr der Code bringen würde...
es geht nur darum bei StringReplace das vergleichen nur alle 2 zeichen zu machen, da ein byte im binärstring 2 zeichen benötigt
das is jetz eig unkompliziert ausgedrückt

der code, den ich zurzeit bearbeite funktioniert schon, hat eigentlich auch nicht viel mit der frage zu tun...

progandy

Leider hat AutoIt keine Funktionen, die auf Binärdaten arbeiten. Daher muss man das immer als ASCII-Strings interpretieren. Ist zwar Speicherlatzmäßg völlig sinnfrei, da AutoIt immer Unicode und damit doppelten Speicher verwendet, aber da ist nichts zu machen.

**Andy**

ok, um mal einiges geradezurücken damit du überhaupt kapierst, was Bugfig und auch ich im einzelnen meinen:

Zitat

das sind normale dateien, keine textdaten

was unterscheidet "normale" Dateien von Textdateien? Sind Textdateien nicht normal?

Zitat

also sind daten die man mitm editor zb. nicht bearbeiten kann

schaff dir einen ordendlichen Editor an, dann kannst du damit auch "normale" Dateien bearbeiten! Schon mal ne EXE oder BMP in Scite geladen? Die kann man dort auch einwandfrei bearbeiten....

Zitat

wenn ich auslese habe ich dann ja nen "0x..." string

Wenn du was wie ausliest, bekommst du einen String, in dem die Bytes hexadezimal dargestellt werden?

Zitat

mache beim lesen&schreiben einfach binarymode. ich habe ja haufenweise nicht druckbare zeichen

Was hat das eine mit dem anderen zu tun? Was haben nicht druckbare Zeichen mit dem binarymode zu tun?

Zitat

auf jeden fall gehts bei autoit ewig, möchte das wenn möglich schneller haben.

WAS möchtest du schneller haben?

Zitat

da is mir eben aufgefallen dass nur 2 zeichen aus dem hex-string ein byte geben, aber autoit weiss das doch nicht und kombiniert daher eig jedes zweite mal halbe bytes..

du liest eine Datei falsch aus, und gibst dem Programm die Schuld an deiner Unfähigkeit....

Um das ganze mal abzukürzen:
Stell deine Frage so, dass man kapiert um was es geht, stell dein Script und einen Teil der Beispieldatei ein damit man kapiert was du "herumbasteln" willst und investiere einige Minuten Zeit darin, deine Frage so zu stellen, dass auch jemand, der es gewöhnt ist, ganze verständliche Sätze mit richtiger Groß/Kleinschreibung und Interpunktion zu lesen dich nicht sofort auf die Ignorliste stellt.
Denn genau da führt so ein Geschreibsel in der Regel auch hin.....

@progandy
Selbstverständlich kann man in AutoIt in Binärdateien arbeiten. s. FileGetPos/FileSetPos
Ob der String, der dabei gelesen wird, AutoIt-INTERN als Unicode (und somit doppelt so groß als eigendlich benötigt, da hast du recht) verarbeitet wird, ist doch schnurz. Das was du binär "siehst" ist doch sowieso ascii....und nur weil das stringregexp() nicht kann heisst das ja nicht, dass die anderen stringfunktionen das nicht können

Spoiler anzeigen

[autoit]

filedelete("test.bin");datei löschen
$b=chr(68)&chr(0)&chr(65)&chr(65); binärstring erstellen mit nullbyte
Filewrite("test.bin",$b);binärdatei schreiben
$a=fileread("test.bin");binärdatei lesen
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : stringlen($a) = ' & stringlen($a) & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
$pos=stringinstr($a,"AA");position des suchstrings ermitteln, TROTZ nullbyte
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $pos = ' & $pos & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console

[/autoit]

progandy

Zitat von Andy

Selbstverständlich kann man in AutoIt in Binärdateien arbeiten. s. FileGetPos/FileSetPos
Ob der String, der dabei gelesen wird, AutoIt-INTERN als Unicode (und somit doppelt so groß als eigendlich benötigt, da hast du recht) verarbeitet wird, ist doch schnurz. Das was du binär "siehst" ist doch sowieso ascii....

Ich meinte, dass es keine Funktionen wie für Strings gibt. Ich hätte halt gern ein BinaryReplace und BinaryFind. Dann könnte man direkt auf Binärdaten arbeiten ohne dies blöden speicherfressenden Umwandlungen (oder eine langsame Implementierung per BinaryMid). Dass binäres Lesen und Schreiben mit Dateien funktioniert, das weiß ich. Übrigens wäre ein BinaryRegExp nicht schlecht, das auch Nullbytes richtig unterstützt nicht so wie StringRegExp, das bei Nullchars Probleme bekommt.

**Andy**

Zitat

Übrigens wäre ein BinaryRegExp nicht schlecht, das auch Nullbytes richtig unterstützt nicht so wie StringRegExp, das bei Nullchars Probleme bekommt.

da ich nicht der Regex-Crack bin, reichen mir die "normalen" Stringbefehle (welche auch idR keine Probleme mit Nul-Bytes haben)

Mit Binaryreplace kann ich dir (noch) nicht dienen (wobei man das mit Schreiben in eine Struct wohl hinbekäme, jedenfalls bei gleicher Größe von Suchstring/Replacestring)
BinaryFind, da benutze ich StringInstr(), aber guck mal hier, da hatten wir das Thema bzgl Geschwindigkeit beim Suchen schon einmal.

TimBlo

Zitat von Andy

du liest eine Datei falsch aus, und gibst dem Programm die Schuld an deiner Unfähigkeit....

Manche leute sind auch unfähig im lesen oder?
ich habe bereits gesagt, dass es funktioniert, aber da du wohl nichtmal ein par sätze "geschreibsel" richtig interpretierst, kann alles seinen sinn verlieren.

progandy hat längst verstanden worum es geht.
so wie autoit binärdaten verarbeitet ist es langsam!
und sorry dass ich mir nicht die mühe mache shift zu drücken wenn ich auf einer uralten PS2 Tastatur mit scheizer tastaturlayout und deutschem PC schreibe, die tasten sind beinahe schon richtig verklemmt -.-

also es gibt kein BinaryRegExp oder BinaryReplace und damit wäre der fall schon klar. war ja nich so schwer oder?

**Andy**

Zitat

Manche leute sind auch unfähig im lesen oder?

mitnichten, ich habe den ersten Post sorgfältig mehrmals (gezwungenermaßen) gelesen.

Zitat

progandy hat längst verstanden worum es geht.

aha, Autoit benutzt ein "langsames" und für Binärdateien nicht geeignetes StringRegExp(). Was hat das mit deiner "Frage" (aber dabei werden ja halbe Bytes überprüft, gibt es iirgend nen ausweg? ) zu tun?
Es werden keine halben Bytes überprüft! Weder macht das StringRegExp() noch sonst irgendeine der "langsamen" AutoIt-Funktionen. Du bist nur nicht in der Lage, eine Datei richtig einzulesen, dazu benutzt man nämlich NICHT den binarymode, sondern öffnet die Datei ganz normal, s. Beispielscript im Post Nr. 7.
Den Stringfunktionen (bis auf Regex) ist es nämlich völlig schnurz, welchen Inhalt die Strings haben....daher ist deine Aussage

Zitat

so wie autoit binärdaten verarbeitet ist es langsam!

definitiv falsch!

Du kannst mit den "normalen" Stringbefehlen einwandfrei Daten sehr schnell bearbeiten. Wie schnell das gehen kann, zeigt übrigens der von mir gepostete Link in Post 9., u.a. mit Hinweis auf Optimierung der Suchmodi.
Viel schneller funktioniert das auch mit optimierten Suchroutinen (C++/asm) nicht. Wzbw....
Die reine Suchzeit für z.B. StringInstr() beträgt auf einem 2-Ghz-Rechner ca. 10 MB/s, also ca. 200 Prozessortakte pro Byte (incl. Vergleich, Daten nachladen, Caching usw). Die aus der Prospeed.dll entliehene in Assembler geschriebene Funktion Findbyte() ist nicht einmal annähernd so leistungsfähig wie Stringinstr() sondern vergleicht nur simpel 2 Bytefolgen und ist daher etwas schneller. Das physikalische Geschwindigkeitslimit ist hier erreicht.

Wenn du also "schneller" Bytes suchen/bearbeiten willst, bleibt dir nichts anderes übrig, als dir einen wesentlich schnelleren Rechner zu kaufen! Oder das gesamte Programmkonzept zu überdenken. Übrigens hast du immer noch kein Script gezeigt bzw beschrieben, was du überhaupt genau machen willst. Meistens hängt es nämlich nicht an der Ausführungsgeschwindigkeit, sondern am "langsamen" Konzept des Programms!

TimBlo

okay, wie müsste folgendes aussehen, wenn der Binary Mode nicht verwendet wird? (nicht das du mir das neu schreiben musst, aber wenn du mir iwie ein par tipps hast)

[autoit]

$pattern = "73656C65637400000000[0-9A-F]{2}000000[0-9A-F]{2}00000000000000(?:0000(?:[1-9A-F]{2}|[1-9A-F]0|0[1-9A-F])0\d0000|[0-9A-F][0-9A-F]00736F756E645F6B6579203[0-9](?:[1-9A-F]{2}|[1-9A-F]0|0[1-9A-F])0\d0000)*"
$founds = StringRegExp($FileSource, $pattern, 3)

[/autoit]

für die variable $FileSource kannst du inen inhalt einer datei nehmen...
das beispiel soll halt betimmte bytes finden und wenn ich nicht weiss wie man in einem normalen string ein zeichen mit dem null wert findet, dann wärs ma zeit es zu lernen.

für den vorgang brauche ich diese funktionen : StringReplace, StringRegExpReplace und StringRegExp
wenn es mit diesen geht, wirds mit StringLeft usw. auch gehen...

ich glaube jetzt sind wir dem ziel doch näher gekommen