Definition String in "StringRegExp()" und "StringMid()" nicht gleich?

  • Ich glaube zwar einiges an Hilfe und Tutorials gelesen zu haben aber etwas Grundlegendes dürfte ich übersehen zu haben. Ich hoffe irgendjemand kann mir helfen. Ich möchte eine Menge JPG-Files untersuchen die nicht DPI 72/72 haben. Schien einfach mit Regexp zu lösen sein. Bin dabei auf folgendes Problem gestoßen. Ich wollte Bytes 15-16 und 17-18 enthaltene Werte auslesen.
    (In Byte 14 wird definiert in welchen Maßeinheiten die Werte sind also Byte 14=0x01 steht für "Dots per Inch" wenn =0x02 dann sind die Werte "Dots per cm")
    Hier ein kleines Script zur Veranschaulichung:


    Bei StringRegExp gehen Werte kleiner 256 verloren, da dieser String mit 0x00 beginnt, also mein $aW[1] endet offensichtlich vor 0x00, also Länge = 0. Hingegen "StringMid" liefert korrekt 2 Bytes als 0x0048, also 72.
    Handelt es hier um einen Fehler oder sind die Definitionen für String verschieden?

    P.S: Übrigens mein Vorschlag, "Feature Request Ticket#1889" auf https://autoit.de/www.autoitscript.com, welches hier sehr hilfreich gewesen wäre, wurde aber abgelehnt.

  • Schau dir das mal an:

    [autoit]

    _GDIPlus_ImageGetPixelFormat

    [/autoit]

    Andy hat mir ein Schnitzel gebacken aber da war ein Raupi drauf und bevor Oscar das Bugfixen konnte kam Alina und gab mir ein AspirinJunkie.

  • Hab angesehen, hat aber mit meiner Frage absolut nichts zu tun. Ich wollte wissen warum wird bei "StringRegExp" der String mit 0X00 beendet wird. Wie man sieht, bei Wert 300 (=0X012c) wird ja ein Wert zurückgegeben. Bei Werten mit 0x00xx jedoch nicht, da offensichtlich Strings mit 0x00 terminiert werden. Wissen wollte ich ob dies ein Fehler sei oder ich bei "StringRegExp" irgend eineOption oder was auch immer übersah.

  • Dieser Befehl ist aber genau für das gedacht was du haben willst und erspart dir das komplette selbstschreiben des RegExp.

    Andy hat mir ein Schnitzel gebacken aber da war ein Raupi drauf und bevor Oscar das Bugfixen konnte kam Alina und gab mir ein AspirinJunkie.

  • Sorry, Frage noch immer nicht verstanden. Ich wollte wissen wieso bekomme ich 2 verschiedene Lösungen. Unabhängig vom Beispiel, beziehungsweise wobei ich es entdeckt habe. Ich habe ein grundsätzliches Problem. Wenn ich ein RegExp schreibe was muss ich beachten damit ich tatsächlich das bekomme was ich erwarte. Ich durchsuche nicht immer JPG's. Ich bin verwirrt, wieso hartnäckig am Beispiel festgehalten wird.

  • Das liegt vermutlich an der verwendeten RegEx-Engine, PCRE. Die arbeitet an einigen Stellen eben mit nullterminierten Strings und daher können dort keine Null-Chars ausgegeben werden. Für Binärdaten braucht man normalerweise auch kein StringRegExp.

    Im Beispiel ist die beste Lösung immer noch Datei im Binärmodus auslesen, dabei mit FileSetPointer an die richtigen Stellen springen. Oder erst binär auslesen und dann mit BinaryMid die Zeichen auslesen. String-Funktionen sind hier nicht ganz richtig am Platz ;)

  • Habe es richtig verstanden, BinaryMid wäre korrekt, da die Stringfunktionen Binärdaten jeweils verschieden verarbeiten. Zwar liefert StrigMid auch das richtige, aber es ist nicht genau definiert/bekannt welche Funktion wie die binäre Daten verarbeiten, also Finger weg. (Hatte zwar während meiner Suche irgendwo so etwas wie " [\x00-\xff]" als Pattern gesehen . Scheint aber bei der Befüllung des Arrays der String verloren zu gehen.)
    Wie auch immer, danke.

  • So ungefähr. Die meisten Stringfunktionen funktionieren mit Chr(0), aber das sind nicht alle. Außerdem finde ich es nicht gerade effizient, Binärdaten in einen String umzuwandeln, um damit zu arbeiten. Strings sind in AutoIt Unicde, d.h. 2 Bytes pro Zeichen, also wird der benötigte Speicherplatz verdoppelt. Ansonsten wäre es schin möglich, die Stringfunktionen zu verwenden.

    StrinRegExp nimmt Strings mit Nullchars an, aber bei der Ausgabe funktioniert es hier nicht. Das könnte zwar ein Bug in AutoIt sein, ich vermute aber eher, dass wie schon gesagt, die REgex-Engine bei der Ausgabe nicht wirklich damit umgehen kann.