ansaurus

Question

Delphi - TPerlRegEx / RegExBuddy Problem

Answer 1

+3 A:

Not being acquainted with Delphi, I couldn't make sense of your Delphi-flavored regex, so I went back to RegexBuddy to recreate it. Here's my original:

criteria\.push\(new\s+kpCriterion\(
'(?P<keyword>.*?)',
\s*(?P<number1>.*?),
\s*'(?P<localsearch>.*?)',
\s*'(?P<globalsearch>.*?)',
\s*(?P<localsearchnum>.*?),
\s*(?P<globalsearchnum>.*?),
[^,]*,
\s*'\$(?P<price>.*?)',
\s*(?P<number2>.*?),
\s*'(?P<range>.*?)',
\s*(?P<number3>.*$)

...and here's Delphi-string version RegexBuddy generates:

'criteria\.push\(new\s+kpCriterion\(
'(?P<keyword>.*?)',
\s*(?P<number1>.*?),
\s*''(?P<localsearch>.*?)'',
\s*''(?P<globalsearch>.*?)'',
\s*(?P<localsearchnum>.*?),
\s*(?P<globalsearchnum>.*?),
[^,]*,
\s*'\$(?P<price>.*?)',
\s*(?P<number2>.*?),
\s*'(?P<range>.*?)',
\s*(?P<number3>.*$)'

I split them up for readability, obviously. To reassemble them, just remove the line breaks; there should be no literal whitespace of any kind in the regex.

The biggest problem I saw with your regex was this bit: '#13#10'. I'm not familiar with Delphi syntax, but that's the only thing I can see that might make the regex fail to compile. RegexBuddy seems to think \r\n will work, but I skirted the issue by using \s* instead; it's the commas that delimit the fields anyway, not the line breaks.

I also got rid of the redundant parentheses inside the named groups; unless TPerlRegEx is radically different from other flavors, they were just clutter. Does this regex work for you?

Alan Moore 2010-03-08 05:20:54

Thank you for the information, I am not that familiar with RegEx, and I knew the #13#10 were bad to have in the regex. I will try your RegEx code.

Brad 2010-03-08 07:43:44

Brad, if you're not familiar with regular expressions, what in the world made you think they'd be the right tool for parsing Javascript?

Rob Kennedy 2010-03-08 08:56:35

Because I know the power of RegEx, and I knew I could figure it out with a little help from here and there. If your afraid to use something you don't know yet how will you ever learn anything? I had used parsing before, but It had it had it's share of problems.

Brad 2010-03-09 06:56:53

Alan, that RegEx code works GREAT! Thank you for the incite, I wish I could give two answers the correct answer on stackoverflow.

Brad 2010-03-09 08:24:08

Answer 2

+4 A:

The runtime error "TPerlRegEx.Compile() - Please specify a regular expression in RegEx first" means you called TPerlRegEx.Compile or another method that calls this (such as TPerlRegEx.Match) without setting the TPerlRegEx.RegEx property. You can't get that error with the code in your question.

Your file Unit2.pas fails to compile with an error "string literals may have at most 255 elements". This is something that RegexBuddy does not yet take into account when generating Delphi code. (The next free minor update will.) If you manually split up the string into pieces shorter than 255 characters (e.g. 'longstring' becomes 'long' + 'string') then the code runs. It does not find any matches though.

To make your code find matches, I made it load your file googleresultstestdata.txt from disk instead of using the memo to make sure that the memo's word wrapping does not add any line breaks to the text. I also removed all instances of #13 from the regex. Your file googleresultstestdata.txt uses UNIX-style line breaks which are matched with \n or #10 only. \r\n or #13#10 matches Windows-style line breaks.

In Delphi strings, #13 represents CR and #10 represents LF. There is absolutely no problem with using literal line breaks in regular expressions. If you type a literal line break into RegexBuddy then RegexBuddy codes that as #13#10 in Delphi. If you type \r\n into RegexBuddy then RegexBuddy codes that as '\r\n' in Delphi. PCRE (used internally by TPerlRegEx) interprets \r and \n as CR and LF.

Your regex uses redundant capturing groups. (?<name>(.*?)) puts the .*? inside a numbered capturing group and that inside a named capturng group "name". There's no point in doing that. If you want the named group, just use (?<name>.*?)

This does not affect what your regex matches, but will affect its performance. A bigger problem though is that all those .*? can result in catastrophic backtracking. Whether this is a concern depends on how you'll be using the regex. If you're only using it on your own data and it doesn't cause problems, you can leave it. But if this is going into an application that handles user-provided data, then you'll need a regex that fails more gracefully if it can't match the user's data.

unit Unit2;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, PerlRegEx;

type
  TForm2 = class(TForm)
    Memo1: TMemo;
    Memo2: TMemo;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form2: TForm2;

implementation

{$R *.dfm}

procedure TForm2.Button1Click(Sender: TObject);
var
    Regex: TPerlRegEx;
    GroupIndex: Integer;
  FS: TFileStream;
  S: UTF8String;
begin
  Regex := TPerlRegEx.Create(nil);
  Regex.RegEx := 'criteria\.push\(new kpCriterion\(&#39;(?P<keyword>(.*?))&#39;, (?P<number1>(.*?)),' +
                 #10'''(?P<localsearch>(.*?))'', ''(?P<globalsearch>(.*?))'', (?P<localsearchnum>(.*?)), (?P<globalsearchnum>(.*?)), (.*+)'#10','#10'&#39;\$(?P<price>(.*?))&#39;, (?P<number2>(.*?)),'#10'&#39;(?P<range>(.*?))&#39;, (?P<number3>(.*+))';
  Regex.Options := [preMultiLine];
  FS := TFileStream.Create('g:\temp\googleresultstestdata.txt', fmOpenRead);
  SetLength(S, FS.Size);
  FS.Read(S[1], Length(S));
  FS.Free;
  Regex.Subject := S;
  if Regex.Match then begin
    memo2.Lines.Add('Matches Found');
    repeat
      for GroupIndex := 0 to Regex.SubExpressionCount do begin
           memo2.lines.add( Regex.SubExpressions[GroupIndex]); //Add Results to memo
        // backreference text: Regex.SubExpressions[GroupIndex];
        // backreference start: Regex.SubExpressionOffsets[GroupIndex];
        // backreference length: Regex.SubExpressionLengths[GroupIndex];
      end;
    until not Regex.MatchAgain;
  end
  else
    memo2.Lines.Add('No-Matches Found');
end;

end.

Jan Goyvaerts 2010-03-08 12:29:46

ansaurus

tags:

views:

answers:

Delphi - TPerlRegEx / RegExBuddy Problem

related questions