natives RegEx (PCRE) für D2009+

[himitsu]

Tachchen ihr, :angel:

gibt es eigentlich eine einfache, bezahlbare, halbwegs perlkompatible und vorallem unicodefähige Bibliothek für regulärere Ausdrücke?

Bzw. was könnt ihr denn so alles empfehlen?



TPerlRegEx würde zwar nahezu allen Punkten auf diese Beschreibung passen, aber nun das ABER:
- perlkompatibel ist es, daß es die originalen und in Perl verbauten PCREs verwendet
- allerdings muß man dafür immer eine DLL mitliefern.

Bin zwar schon seit 'ner Weile auf Suche, aber hab noch nichts gefunden, welches mir gefällt oder wo überhaupt noch wer dran arbeitet (viele Libs sind schon etwas in die Jahre gekommen).


Nja, bin zwar schon dabei etwas Eigenes zu schreiben (ratet mal, warum ich in lezter Zeit so viel mit kranken Parsern übe und mein Unicode-CharSet so sehr erweitere/überarbeite), aber bis dieses ordentlich läuft, wird es wohl noch 'ne Weile dauern.

[Hawkeye219]

Moin himi,

hast du dir schon einmal den Quelltext der Unit pcre.pas angesehen?

Code:

{$IF COMPILERVERSION >= 21.0}
  // Define PCRE_STATICLINK to link the OBJ files with PCRE 7.9.
  // This works correctly in all cases with Delphi 2010 (and later).
  {$DEFINE PCRE_STATICLINK}
{$ELSE}
  // Delphi 2009 and earlier have a compiler bug that may cause an internal error if install TPerlRegEx
  // into a design time package, and you don't put TPerlRegEx into a runtime package at the same time.
  // With Delphi 2009 and earlier you can use PCRE_STATICLINK if you don't use packages at all
  // (which means you don't install it into the IDE and you don't drop TPerlRegEx on a form)
  // You can also use PCRE_STATICLINK if you put the component into a runtime package

  // Define PCRE_LINKDLL to use pcrelib.dll
  {.$DEFINE PCRE_LINKDLL}
  {$DEFINE PCRE_STATICLINK}
{$IFEND}

Das sollte doch eigentlich ohne DLL gehen, oder?

Gruß Hawkeye

[himitsu]

Nee, das war mir noch nicht aufgefallen.

Die Basis besteht ja aus nur knapp über 30 Dateien und als ich mir das letztens genauer ansah, da gab es nur die Variante mit der DLL.

www.regexguru.com/2008/08/tperlregex-for-delphi-2009

{$IFDEF UNICODE}
type
PCREString = UTF8String;
{$ELSE}
type
PCREString = AnsiString;
{$ENDIF}

The UNICODE directive is defined by default in Delphi 2009, but not in Delphi 2007 or earlier. If you’re using Delphi 2007 or before, TPerlRegEx will work with AnsiString, which has been the default string type since Delphi 2.

When you migrate your application to Delphi 2009, the default string type becomes UnicodeString. PCRE does not support UTF-16. It only supports 8-bit strings (i.e. one byte per character), and UTF-8. Hence my decision to make TPerlRegEx use the new and improved UTF8String in Delphi 2009.

OK, wenn das jetzt geht, dann gibt es ja nur noch den einen Wehrmutstropen, daß es anscheined nicht komplett unicodefähig ist.
Selbst daß die jetzt UTF-8 draus gemacht haben, bedeutet nicht, daß man wirklich mit Unicode arbeiten kann. :?

[s-off]

Du wirst nichts besseres als die TPerlRegEx von Jan Goyvaerts finden. Es ist m.W. nach auch die einzige, auf der PCRE-Lib von P. Hazel basierende und für Delphi verfügbare Komponente - also die einzige wirklich perlkompatible Lösung.

Ich habe immer mal wieder Probleme mit der PCRE_STATICLINK-Direktive (D2007). Mal funktioniert es damit, mal nicht - und ich weiß noch nicht wirklich, woran es liegt - ich habe die Komponente in keine Packages gelinkt... :gruebel:

[himitsu]

Wenn jetzt nicht der vollständige PCRE-Befehlsatz unterstützt wird, dann wäre das noch verkraftbar,

Aber wenn man Unicode als UTF-8 durch eine ANSI-Lib jagt, dann kann man als Suchmuster nur den 7-Bit-ASCII-Bereich nutzen.

Ohne Unicode/UTF-8 wäre damit wenigstens noch das komplette 8-Bit-ANSI möglich.


Also, wenn die PCRE-Lib intern wirklich nur mit ANSI arbeitet, dann ist UTF-8 für Unicode absolut keine Lösung und z.B. [äöü] könnte man damit vergessen. :wall:

[mirage228]

Zitat:

Zitat von s-off

Du wirst nichts besseres als die TPerlRegEx von Jan Goyvaerts finden. Es ist m.W. nach auch die einzige, auf der PCRE-Lib von P. Hazel basierende und für Delphi verfügbare Komponente - also die einzige wirklich perlkompatible Lösung.

Es gibt noch: http://www.renatomancuso.com/software/dpcre/dpcre.htm

Allerdings ist das noch für D7 und mit einer "älteren" Version von PCRE, für D2009+ müsste man die string/PChar Aufrufe nach AnsiString/PAnsiChar umwandeln...

[ULIK]

Schon mal DiRegEx angeschaut? Kostet nicht die Welt und hat es bisher bei mir ohne Klagen getan.

Grüße,
Uli

[s-off]

Zitat:

Zitat von mirage228

Zitat:

Zitat von s-off

Du wirst nichts besseres als die TPerlRegEx von Jan Goyvaerts finden. Es ist m.W. nach auch die einzige, auf der PCRE-Lib von P. Hazel basierende und für Delphi verfügbare Komponente - also die einzige wirklich perlkompatible Lösung.

Es gibt noch: http://www.renatomancuso.com/software/dpcre/dpcre.htm

Allerdings ist das noch für D7 und mit einer "älteren" Version von PCRE, für D2009+ müsste man die string/PChar Aufrufe nach AnsiString/PAnsiChar umwandeln...

Die Komponente hatte ich früher mal im Einsatz. Da daran aber schon seit mehr als zwei Jahren nichts mehr getan worden ist, ist sie aus meiner Sicht für diesen Thread irrelevant.

Zitat:

Zitat von ULIK

Schon mal DiRegEx angeschaut? Kostet nicht die Welt und hat es bisher bei mir ohne Klagen getan.

Die Komponente kenne ich noch gar nicht. Der Preis scheint erstmal ok. Ich frage mich nur, welche Einschränkungen man in Kauf nehmen muss.

Zitat:

DIRegEx is a library of Delphi components and procedures that implement regular expression pattern matching using the same syntax and semantics as Perl 5.10, with just a few differences.

Man achte auf den letzten Teil. Oftmals sind es die Kleinigkeiten, die man schmerzlich vermisst ;)

Wie dem auch sei; solltest Du, himitsu, die Komponente testen, so würde ich mich über einen Erfahrungsbericht sehr freuen :)

[himitsu]

Bekommt man eigentlich die Quellcodes zu deren Units, wenn man es kauft,
bzw. was passiert, wenn die mal nicht weiterentwickeln?

OK, auch hier muß man selbst erstmal das Suchpattern auf UFT8 umstellen, aber wenigstens sucht der intern anscheinend "teilweise" richtig.

Auch hier kommt es mal vor, daß Unicodezeichen zerstört werden, da sie intern nicht als UTF-8, sondern ihre UTF-8-Bestandteile jeweils als einzelzeichen angesehn werden. :wall:

Zum Glück liefern die ihre eigenes UTFDecode mit, da man sonst mit den Ergebnissen manchmal garnichts anfangen könnte.
Denn das von Delphi reagiert bei "ungültigem" UTF-8 ja sehr rabiat.

Zitat:

Die Komponente kenne ich noch gar nicht. Der Preis scheint erstmal ok. Ich frage mich nur, welche Einschränkungen man in Kauf nehmen muss.

Bei der Testversion poppt alle paar Minuten innerhalb der IDE ein Fenster auf > vonwegen unregistrierte Version (ob das im Compilat dann auch passiert ... k.A., hab nicht so lange gewartet)

Das Setup ist istgendwie ... nja.
eigentlich nur eine selbstentpackende EXE und die Komponenten installieren, samt Suchpfade einrichten darf man selber machen.

Für Unicode gibt es hier allerdings, so wie bei den Anderen auch, gewisse Einschränkungen, da sie dieses auch nur als UTF-8 durch einen ANSI-Code jagen.

'{ein unicodezeichen}' > '{mehrere utf8-zeichen}' > Maske '\w' oder '.' liefert aber nur das erste UTF8-Zeichen und nicht alle Zusammengehörenden ... also nach der UTF-8-Dekodierung zurück nach Unicode, kommt nur noch Schrott raus.

[s-off]

Zitat:

Zitat von himitsu

Bekommt man eigentlich die Quellcodes zu deren Units, wenn man es kauft [...]

Zitat:

Euro 79.99 with sources

:zwinker:

Edit: mit Einschränkungen bezog ich mich auf den Satz

Zitat:

[...] using the same syntax and semantics as Perl 5.10, with just a few differences

Nutzt die gleiche Syntax wie Perl, mit einigen Einschränkungen... :roll:

Die Featurelist sieht auf jeden Fall okay aus.

[himitsu]

OK, bei den Preisen war ich noch nicht ... wollte erst mal schauen, was die Demo kann und mich danach von den Preisen "schocken" lassen :lol:

[add]
@s-off: 15 Beiträge? ich dachte ich hätte dich hier schon öfters gesehn :gruebel:


PS: 80 € für das "kleine" RegEx ... das ist ja en 5-tel meines Delphis ... aber OK, andere Firmen übertreiben bei ihren Preisen dann doch noch mehr.

[s-off]

Zitat:

Zitat von himitsu

@s-off: 15 Beiträge? ich dachte ich hätte dich hier schon öfters gesehn :gruebel:

Ähm, ja - ich habe letztens aus Versehen den Reset-Knopf gedrückt, und -schwupp- stand der Beitragszähler auf 0 :cry:
Nee, habe mir vor zwei Jahren eine kleine Auszeit genommen. Ich brauche immer so lange, bis ich mich nach einer Meinungsverschiedenheit wieder abgeregt habe :zwinker:

Zitat:

Zitat von himitsu

PS: 80 € für das "kleine" RegEx ... das ist ja en 5-tel meines Delphis [...]

Für das, was Du durch sinniges Einsetzen von RegExen an Arbeitszeit sparst, ein Klacks :)

Ich kann mir diese kleinen Dinger aus meinem Tagesgeschäft jedenfalls nicht mehr wegdenken - auch wenn ich sie direkt in meinen Quellcodes weniger nutze.
Häufiger gebrauche ich sie für Search&Replace-Arbeiten; hier dann vorzugsweise mit diesem unschlagbaren Tool (*werbung mach*) ;)
(Lass Dich durch den preis nicht irritieren - es ist jeden Cent wert).

[himitsu]

So, ich war nun endlich mal wieder dazu gekommen.

Und nachdem ich die Generics wieder rausgeworfen hab, läßt sich nun endlich wieder alles kompilieren. :firejump:
http://www.delphipraxis.net/154469-g...erfuegbar.html
http://www.delphipraxis.net/154472-g...klarieren.html


Die Header stehen nun auch endlich.
Hab inzwischen auch die Ansi- und die Unicode-Version in einer Klasse vereiniget.
Die gekürzten Header hab'sch mal angehängt > "RegEx - gekürzte Header.pas"
Überall wo ein {Ansi} in diesen Headern vorkommt, dort kann Unicode (String/UnicodeString) und/oder ANSI (AnsiString, UTF8String oder andere AnsiString mit unterschiedlichen CodePages) übergeben werden.



Und ein Großteil der kleinen Funktionen scheint auch soweit OK.
Muß "nur" noch ein paar Funktiönchen prüfen, bzw. neu implementieren.
(man sieht ja wo im Quellcode noch ein paar Funktionen mit 'nem {*} gekennzeichnet sind)

[himitsu]

Ich hab hier noch ein logistisches Problem.
Und zwar überlege ich, wie ich die Character-Klassen organisiere.

Da diese klasse auf Unicode und nicht nur auf ASCII vergleicht, wären diese Klassen ebenso Unicode.

z.B ist dieses

Delphi-Quellcode:

[A-Za-z0-9_]

nur ASCII (da nur die ASCII-Zeichen angegeben sind)

Nun gibt es aber logisch gesehen noch diese

PHP-Quellcode:

\p{IsWord}

,

Delphi-Quellcode:

\w

und

Delphi-Quellcode:

[:word:]

.

Um es zu vereinfachen würde ich Eines/Einiges davon ebenso als ASCII anlegen und den Rest als Unicode.
Aktuell tendiere ich dazu

Delphi-Quellcode:

[:word:]

als ASCII zu machen
und die Anderen würden dann alle Buchstaben und Zahlen aller Sprachen/Formatierungen enthalten.

Oder würde jemand etwas anderes empfehlen?
Ich versuche zwar die beste Kombination der PERL- und der POSIX-Syntax hinzubekommen, aber Änderungen, bzw. Erweiterungen wären schon möglich. (falls jemand eine Idee hat, wie man z.B. alles als ASCII und Unicode anlegt und dann einen "Umschalter" integriert)

[Assarbad]

Zitat:

Zitat von s-off (Beitrag 997703)

Zitat:

DIRegEx is a library of Delphi components and procedures that implement regular expression pattern matching using the same syntax and semantics as Perl 5.10, with just a few differences.

Man achte auf den letzten Teil. Oftmals sind es die Kleinigkeiten, die man schmerzlich vermisst ;)

Na dann Vorsicht mit PCRE, denn auch die sind nicht semantisch völlig kompatibel zu denen in Perl selbst, trotz des Namens!