AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

TPerlRegEx - stack overflow

Ein Thema von liftoff · begonnen am 12. Jun 2012 · letzter Beitrag vom 14. Jun 2012
Antwort Antwort
Seite 1 von 2  1 2      
liftoff

Registriert seit: 6. Jun 2012
Ort: Frankfurt am Main
11 Beiträge
 
Delphi XE Enterprise
 
#1

AW: TPerlRegEx - stack overflow

  Alt 13. Jun 2012, 11:36
Vielen Dank für die bisherigen Anworten.

Einen eigenen Parser zu schreiben, wäre hier viel zu aufwändig. Das Ganze ist ja bereits ein Parser für Swiftnachrichten auf der Basis von regulären Ausdrücken. In der Tat ist TPerlRegEx ungefähr halb so schnell, wie mein alter Wrapper. Insgesamt ist die Performance aber zufriedenstellend.

Hier dann mal ein Beispielcode:
Code:
var re : TPerlRegEx;
    teststr : UTF8String;
    l1 : integer;
begin
  try
    re := TPerlRegEx.create;
    re.Options := [precaseless];
    re.State := [];

    re.RegEx := '({4:\r\n(?:[^\r\n]*\r\n)*-})';
    re.Compile;

    //    Nun Beispielstring mit Inhalt
    //    {4:
    //    :00X:ABCDEFB0123456789
    //    :00X:ABCDEFB0123456789
    //    :00X:ABCDEFB0123456789
    //    :00X:ABCDEFB0123456789
    //    ...
    //    -}
    //    zusammenbauen

    TestStr := '{4:'+chr(13)+chr(10);

    for l1 := 1 to 500 do
        TestStr := TestStr + ':00X:ABCDEFB0123456789' +chr(13)+chr(10);

    TestStr := TestStr + '-}';


    re.Subject := TestStr;

    re.Match;

    { TODO -oUser -cConsole Main : Code hier einfügen }
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;

  ReadLn;
end.
Es knallt bei re.match.

Angehängt ist auch ein Beipielprojekt. Ist hoffentlich so korrekt. Delphi XE ist übrigens die Enterprise-Edition.

TRegExErr.zip
  Mit Zitat antworten Zitat
ele

Registriert seit: 18. Feb 2009
129 Beiträge
 
Delphi 2010 Professional
 
#2

AW: TPerlRegEx - stack overflow

  Alt 13. Jun 2012, 11:52
Huch, bin etwas überrascht hier noch einen Delphi Programmierer anzutreffen der sich mit SWIFT-Messages herumschlagen muss. Wilkommen im Club

Folgende RegEx funktioniert:

Code:
({4:\r\n(?:[^\r\n]*\r\n)*?-})
P.S: Falls du jemals mit deinem Job unzufrieden wirst. Unsere Firma sucht immer wieder mal Delphi-Programmiere mit SWIFT-Erfahrung. Melde dich einfach per PM bei mir falls du interessiert bist.
  Mit Zitat antworten Zitat
WladiD

Registriert seit: 27. Jan 2006
Ort: Celle
145 Beiträge
 
Delphi 11 Alexandria
 
#3

AW: TPerlRegEx - stack overflow

  Alt 13. Jun 2012, 12:43
Folgende RegEx funktioniert:

Code:
({4:\r\n(?:[^\r\n]*\r\n)*?-})
Ich habe keine Ahnung von SWIFT (zumindest nicht im Detail), aber der reguläre Ausdruck ist definitv nicht richtig.

- Geschweifte Klammern haben in pcre eine spezielle Bedeutung (Quantifizierung) und müssen daher escaped werden, wenn man sie matchen möchte
- Das Fragezeichen vor der Klammer ist auch fragwürdig, denn es ist ein Quantifizierer also ein Kürzel für {0,1} und ein vorhergehendes Char, Set oder Gruppe fehlt demnach

Dieser Ausdruck würde die vorliegenden Daten richtig matchen:

Code:
(\{4:\r\n(:\w{3}:.*\r\n)*-\})
PS: Reguläre Ausdrücke sind (richtig angewendet) in 99% aller Fälle schneller (weil sie direkt in Maschinencode übersetzt werden) als ein selbstgeschriebener Parser, eine bestimmte Komplexität an den zu matchenden Daten vorausgesetzt.
Waldemar Derr
Profil bei GitHub
  Mit Zitat antworten Zitat
liftoff

Registriert seit: 6. Jun 2012
Ort: Frankfurt am Main
11 Beiträge
 
Delphi XE Enterprise
 
#4

AW: TPerlRegEx - stack overflow

  Alt 13. Jun 2012, 13:14
Der reguläre Ausdruck hat schon viele fehlerfreie Jahre auf dem Buckel.
Macht halt eben Mucken nach der Portierung von 2007 nach XE.

Also mit geschweiften Klammern hatte ich in pcre noch nie Probleme. Nur wenn daraus tatsächlich eine Quantifizierung entsteht. Dann ist ein \ angesagt. Werde den Einwand aber auf jeden Fall mal im Hinterkopf behalten.

Noch ein Frage zu dem *? (was wirklich prima funktioniert. Danke !)

Bedeutet dies, dass pcre bei nongreedy quantifiers immer nur einen Match auf den Stack legt?
Derart ins Eingemachte bin ich da nie gegangen.
  Mit Zitat antworten Zitat
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#5

AW: TPerlRegEx - stack overflow

  Alt 13. Jun 2012, 13:42
@WladiD:
Ein auf eine geöffnete Klammer folgendes Fragezeichen markiert den Beginn eines Subpatterns und ist gültige PCRE-Syntax. Die geschweiften Klammern sollte man allerdings besser escapen.

Abgesehen davon sollte ein selbstgeschriebener Parser eigentlich immer schneller sein als Regex, zumindest in einer kompilierenden Sprache wie Delphi.

@liftoff:
Hatte ich mit Greedy/Non-Greedy wohl doch den richtigen Riecher

Geht der String denn nach dem -} noch weiter? Denn die Sub-Expression [^\r\n]*\r\n matcht ja auch auf Anfang und Ende eines solchen Konstrukts, d.h. die Engine geht immer erst mal bis zum Ende des Strings, weil ja immer noch ein -} folgen könnte; erst am Ende merkt sie dann, dass dort keines ist, und geht schrittweise zurück. Das könnte also, gerade in Kombination mit Sub-Patterns, die vielleicht rekursiv implementiert sind, die Ursache für den Überlauf sein.
  Mit Zitat antworten Zitat
liftoff

Registriert seit: 6. Jun 2012
Ort: Frankfurt am Main
11 Beiträge
 
Delphi XE Enterprise
 
#6

AW: TPerlRegEx - stack overflow

  Alt 13. Jun 2012, 14:02
Ja, gutes Näschen.

Es folgt am Anfang der letzten Zeile immer ein '-}'

Eine Swiftnachricht besteht aus mehreren Blöcken.
Code:
{1:...}{2:...}{3:...}{4:
Nachrichteinhalt
-}{5:}
Der Block 4 (Textblock) muss immer mit '{4:'+Zeilenumbruch anfangen und mit Zeilenumbruch+'-}' enden.

Blöcke 1+2 enthalten Adressinformationen (Absender+Empfänger), 3 Userinfos und 5 Checksummen und son Zeuchs. 1+3+5 sind optional.

Ich habe eben auch noch einen anderen funktionierenden Konstrukt gebastelt

Code:
{4:\R(?:[[:ascii:]]+\R)+-}
  Mit Zitat antworten Zitat
liftoff

Registriert seit: 6. Jun 2012
Ort: Frankfurt am Main
11 Beiträge
 
Delphi XE Enterprise
 
#7

AW: TPerlRegEx - stack overflow

  Alt 13. Jun 2012, 15:33
So. Nach einigen Tests habe ich mich für die non-greedy Variante entschieden.
Performance liegt bei etwa 22000 Nachrichten/h, also parsen, zerlegen und strukturiert in der DB ablegen.
Auf den produktiven Systeme geht das noch ne ganze Ecke flotter.
Ist zwar langsamer als vorher, jedoch vollkommen zufriedenstellend.
Nun lass ich die Bibliothek auf die anderen Prozesse los.

Dank Euch bis hierhin für die Hilfe.

@ele
Bin sehr zufrieden mit meinem Arbeitgeber. Aber vielleicht kann man sich ja auf fachlicher Ebene ein wenig austauschen.
Bei mir steht beispielweise demnächst die Erweiterung auf ISO20022 (XML) an.
  Mit Zitat antworten Zitat
ele

Registriert seit: 18. Feb 2009
129 Beiträge
 
Delphi 2010 Professional
 
#8

AW: TPerlRegEx - stack overflow

  Alt 14. Jun 2012, 14:51
Folgende RegEx funktioniert:

Code:
({4:\r\n(?:[^\r\n]*\r\n)*?-})
Ich habe keine Ahnung von SWIFT (zumindest nicht im Detail), aber der reguläre Ausdruck ist definitv nicht richtig.

- Geschweifte Klammern haben in pcre eine spezielle Bedeutung (Quantifizierung) und müssen daher escaped werden, wenn man sie matchen möchte
- Das Fragezeichen vor der Klammer ist auch fragwürdig, denn es ist ein Quantifizierer also ein Kürzel für {0,1} und ein vorhergehendes Char, Set oder Gruppe fehlt demnach
Du hast recht, es ist besser die geschweiften Klammern zu escapen. Trotzdem ist es eine absolut gültige RegEx:

Zitat von http://perldoc.perl.org/perlre.html:
If a curly bracket occurs in any other context and does not form part of a backslashed sequence like \x{...} , it is treated as a regular character.
Zur aktuellen Diskussion:
Das debuggen von PCRE willst du dir nicht antun - selbst wenn der code in Delphi geschreiben wäre. Regular Expression Engines sind ein ziemlich komplizierte Dinger und die PCRE ist ein Monster. Da schreibst du lieber deinen eigenen Parser - das benötigt weniger Zeit.
  Mit Zitat antworten Zitat
WladiD

Registriert seit: 27. Jan 2006
Ort: Celle
145 Beiträge
 
Delphi 11 Alexandria
 
#9

AW: TPerlRegEx - stack overflow

  Alt 14. Jun 2012, 15:25
Du hast recht, es ist besser die geschweiften Klammern zu escapen. Trotzdem ist es eine absolut gültige RegEx:
Zitat von http://perldoc.perl.org/perlre.html:
If a curly bracket occurs in any other context and does not form part of a backslashed sequence like \x{...} , it is treated as a regular character.
Ja, du hast Recht, das habe ich im Nachhinein auch erfahren. Ich persönlich escape generell alle Zeichen, die irgendeine anderweitige Bedeutung im Ausdruck haben, so ist man auf der sicheren Seite. Vor allem wenn man den Punkt an sich matchen möchte, sollte man ihn tunlichst nicht vergessen zu escapen

Zur aktuellen Diskussion:
Das debuggen von PCRE willst du dir nicht antun - selbst wenn der code in Delphi geschreiben wäre. Regular Expression Engines sind ein ziemlich komplizierte Dinger und die PCRE ist ein Monster. Da schreibst du lieber deinen eigenen Parser - das benötigt weniger Zeit.
Keine Software ist perfekt, aber die PCRE halte ich für eines der solidesten Projekte, die die IT-Branche zu bieten hat. Sodass man zuerst an der eigenen Expression zweifeln sollte, bevor man einen Bug in der PCRE vermutet.
Waldemar Derr
Profil bei GitHub
  Mit Zitat antworten Zitat
liftoff

Registriert seit: 6. Jun 2012
Ort: Frankfurt am Main
11 Beiträge
 
Delphi XE Enterprise
 
#10

AW: TPerlRegEx - stack overflow

  Alt 14. Jun 2012, 15:36
Also einen Bug habe ich auch nie vermutet.

Eingangs wollte ich nur die Stackbehandlung in pcre allgemein und an diesem Punkt jetzt die unterschiedliche Stackbehandlung von greedy- und nongreedy Ausdrücken ein wenig besser verstehen. Wenn nongreedy sich bei gleichem Matchergebnis ressourcenschonender verhält, wäre das ja auch mal eine wichtige Erkenntnis.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:50 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz