problem mit regular expression in php

[roland müller]

hi,

ich hab ein problem mit der eregi_replace funktion bei der verwendung einer regular expression:

<?php
$ersatz = "ananas";
$suchtext = "banane";
$suchmuster = "(?<!<[^<>]*)banane(?![^<>]*>)";
$ergebnis = eregi_replace($suchmuster, $ersatz, $suchtext);

echo $ergebnis;
?>

ich erhalte folgende fehlermeldung:

"Warning: eregi_replace(): REG_BADRPT in /srv/www/htdocs/t3/typo3conf/ext/test.php(102) : eval()'d code on line 6"

ist das problem hier vielleicht bekannt? danke im voraus, roland.

[Sven Rautenberg]

Moin!

ich hab ein problem mit der eregi_replace funktion bei der verwendung einer regular expression:

Warum verwendet eigentlich alle Welt noch diese ereg-Funktionen? Ist der Hinweis in der Doku, dass die preg-Funktionen schneller, im Gegensatz zu ereg binärsicher und kompatibel zu den regulären Ausdrücken in Perl sind, so abschreckend?

$suchmuster = "(?<!<[^<>]*)banane(?![^<>]*>)";

Dieses Suchmuster ist wohl offensichtlich fehlerhaft. Runde Klammern sind in regulären Ausdrücken (zumindest in denen von Perl) Zeichen mit Sonderbedeutung. Das ist das erste, was mir sofort ins Auge springt.

"Warning: eregi_replace(): REG_BADRPT in /srv/www/htdocs/t3/typo3conf/ext/test.php(102) : eval()'d code on line 6"

ist das problem hier vielleicht bekannt? danke im voraus, roland.

Die Anleitung für ereg-Ausdrücke ist in http://www.tin.org/bin/man.cgi?section=7&topic=regex - ziemlich unlesbar aufbereitet, würde ich meinen. Alleine schon deshalb sollte man sich auf preg stürzen, da gibts wenigstens zwei informative Seiten in der PHP-Doku.

- Sven Rautenberg

[roland müller]

ok warum ist dann in folgendem beispiel aus der phpdoku eine runde klammer?

<?php
// den Hostnamen aus URL holen
preg_match("/^(http://)?([^/]+)/i",
    "http://www.php.net/index.html", $treffer);
$host = $treffer[2];

// die letzten beiden Segmente aus Hostnamen holen
preg_match("/[^./]+.[^./]+$/", $host, $treffer);
echo "Der Domänen-Name lautet: {$treffer[0]}\n";
?>

meine regularen ausdruck habe ich in regexdesigner.net getestet, da geht das problemlos. warum sprichst du von perl? es geht mir hier um php.

[Vinzenz Mai]

Hallo

meine regularen ausdruck habe ich in regexdesigner.net getestet, da geht das problemlos. warum sprichst du von perl? es geht mir hier um php.

Sven verweist doch auf die Hinweise in http://www.php.net/manual/de/ref.regex.php.

Die  PCRE-Funktionen haben gegenüber den POSIX-erweitert-RE nur Vorteile, dazu kommt die bessere Doku. Warum willst Du dennoch die PCRE-Funktionen nicht nutzen?

Freundliche Grüße

Vinzenz

[Patrick Andrieu]

Hallo roland!

ok warum ist dann in folgendem beispiel aus der phpdoku eine runde klammer?

In Regulären Ausdrücken dienen runde Klammer der Gruppierung. Die in runden Klammern gefassten Teilstrings werden in Variablen gespeichert, auf die man bei Bedarf zurückgreifen kann.

Da ich PHP nicht kenne, habe ich diese Erklärung gefunden.

Viele Grüße aus Frankfurt/Main,
Patrick

[dedlfix]

echo $begrüßung;

Warum verwendet eigentlich alle Welt noch diese ereg-Funktionen?

Ganz einfach. Preg(nant) hat zu viele Folgen, die manch einer nicht zu tragen bereit ist, ereg... hingegen ...

echo "$verabschiedung $name";

[seth_not@home]

gudn tach!

Ist der Hinweis in der Doku, dass die preg-Funktionen schneller, im Gegensatz zu ereg binärsicher und kompatibel zu den regulären Ausdrücken in Perl sind, so abschreckend?

das steht in dem manual zu eregi_replace() nicht. erst wenn man sich dort zu ereg_replace() durchklickt, liest man am ende, das "preg" oft schneller ist. von binary-unsafe steht aber leider auch dort nichts.

$suchmuster = "(?<!<[^<>]*)banane(?![^<>]*>)";

Dieses Suchmuster ist wohl offensichtlich fehlerhaft. Runde Klammern sind [...]

nein. bei ereg fallen die delimiter weg; siehe manual: eregi_replace()

allerdings weiss ich nicht, ob ereg mit den zero-width... assertions zurecht kommt.

prost
seth

[Vinzenz Mai]

Hallo,

Ist der Hinweis in der Doku, dass die preg-Funktionen schneller, im Gegensatz zu ereg binärsicher und kompatibel zu den regulären Ausdrücken in Perl sind, so abschreckend?

das steht in dem manual zu eregi_replace() nicht. erst wenn man sich dort zu ereg_replace() durchklickt, liest man am ende, das "preg" oft schneller ist. von binary-unsafe steht aber leider auch dort nichts.

siehe CXXVI. Regular Expression Functions (POSIX Extended).

Freundliche Grüße

Vinzenz

[seth_not@home]

gudn tach!

Ist der Hinweis in der Doku, dass die preg-Funktionen schneller, im Gegensatz zu ereg binärsicher und kompatibel zu den regulären Ausdrücken in Perl sind, so abschreckend?

das steht in dem manual zu eregi_replace() nicht. erst wenn man sich dort zu ereg_replace() durchklickt, liest man am ende, das "preg" oft schneller ist. von binary-unsafe steht aber leider auch dort nichts.

siehe CXXVI. Regular Expression Functions (POSIX Extended).

_dass_ es im manual steht, wollte ich ja gar nicht bestreiten; sondern bloss, dass der hinweis gut sichtbar angebracht ist. imho sollten die hinweise bei allen ereg_befehlen stehen. (deswegen ja auch oben das "leider").

prost
seth

[Tom]

Hello,

$suchmuster = "(?<!<[^<>]*)banane(?![^<>]*>)";

Sag doch mal, was es bezwecken soll.
Ich übe auch gerade dran herum...

(?<!          folgende Zeichengruppe soll nicht vorangegangen sein
   <[^<>]*)   lessthen aber nicht lessthen oder greaterthen 0 bis n Mal

banane
(?!
[^<>]
*>)

Da ist doch irgenwie was dopelt zweimal oder so?

http://regexp-evaluator.de/

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[roland müller]

es soll im htmlquellcode das wort banane überall ersetzt werden nur nicht in attributen und tags!

Hello,

$suchmuster = "(?<!<[^<>]*)banane(?![^<>]*>)";

Sag doch mal, was es bezwecken soll.
Ich übe auch gerade dran herum...

[Tom]

Hello,

es soll im htmlquellcode das wort banane überall ersetzt werden nur nicht in attributen und tags!

Was hältst Du dann davon?

'@(?<!<)(?:[^<>]*)(banane)(?:[^<>]*)(?!>)@is'

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

Was hältst Du dann davon?

'@(?<!<)(?:[^<>]*)(banane)(?:[^<>]*)(?!>)@is'

Berücksichtigt leider nicht

Die Banane ist gelb, aber nicht wenn die <gelbe Banane als >Tag
   notiert ist "-> das ist alles Banane." gelle?

wenn die Spitzen Klammern in einem begrenzten String vorkommen...

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[roland müller]

hi danke für deine antwort, leider erhalte ich immer noch die gleiche fehlermeldung!

Was hältst Du dann davon?

'@(?<!<)(?:[^<>]*)(banane)(?:[^<>]*)(?!>)@is'

das ganze sieht jetzt so aus:

$ersatz = "ananas";
$suchtext = "banane";
$suchmuster = "(?<!<[^<>]\)banane(?![^<>]\>)";
$ergebnis = eregi_replace($suchmuster, $ersatz, $suchtext);

echo $ergebnis;

[Tom]

Hello,

hi danke für deine antwort, leider erhalte ich immer noch die gleiche fehlermeldung!

Was hältst Du dann davon?

'@(?<!<)(?:[^<>]*)(banane)(?:[^<>]*)(?!>)@is'

das ganze sieht jetzt so aus:

$ersatz = "ananas";
$suchtext = "banane";
$suchmuster = "(?<!<[^<>]\)banane(?![^<>]\>)";
$ergebnis = eregi_replace($suchmuster, $ersatz, $suchtext);

Ich habe auch preg_replace() benutzt.
Hatte ich wohl vergessen, dazuzuschreiben *sorry*

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[EisFuX]

(Hallo|Hi(ho)|Tag) roland müller,

es soll im htmlquellcode das wort banane überall ersetzt werden nur nicht in attributen und tags!

Und dann glaubst du, dass dieses Suchmuster funktioniert?

$suchmuster = "(?<!<[^<>]*)banane(?![^<>]*>)";

Ich würde das dann andersrum lösen und nebenbei auf die negative
Lookbehind-Assertion verzichten, weil die in PHPs PCRE in beliebiger Länge nicht erlaubt sind:

  
// nur ein Beispiel:  
$heuhaufen = '<tomate banane >banane</tomate>  banane zitrone banane gurke banane erdbeere<banane >orange banane</banane>';  
$muster = '/banane(?=[^>]*<[^>]+>)/i';  
$ersatz = 'ananas';  
$ergebnis = preg_replace($muster, $ersatz, $heuhaufen);  

Noch ne kurze Erklärung (nur für den Umstieg von eregi_replace(), den Rest musst du dir schon aus der Doku holen):

Die Schrägstriche "/" am Anfang und am Ende des Musterstrings sind für PCRE notwendig, sonst gibts ne Fehlermeldung.

Das kleine "i" am Ende des Suchmusters sorgt dafür, dass Groß- und Kleinschreibung ignoriert wird.

Die Lookahead-Assertion geht (vereinfachend) davon aus, dass in einem "Tag" keine "kleiner-als"-Zeichen vorkommen.

http://de.php.net/manual/de/reference.pcre.pattern.syntax.php
http://de.php.net/manual/de/reference.pcre.pattern.modifiers.php

B.T.W.: Die Funktion function preg_replace() arbeitet mit "Perl-kompatiblen Regulären Ausdrücken" -- und davon sprach Sven Rautenberg -- und nicht von Perl. ;-)

MffG
EisFuX

[roland müller]

das glaube ich nicht das hatte ich getestet in meinem regeex tool RegexDesigner.net!
aber ich danke dir jetzt hat mit deiner hilfe auch php verstanden was ich will. nicht umsonst ist halt .net teurer als php aber wenn man php machen muss dann muss man dass halt.

Und dann glaubst du, dass dieses Suchmuster funktioniert?

$suchmuster = "(?<!<[^<>]*)banane(?![^<>]*>)";

[seth_not@home]

gudn tach!

Und dann glaubst du, dass dieses Suchmuster funktioniert?

$suchmuster = "(?<!<[^<>]*)banane(?![^<>]*>)";

angenommen ereg haette keine probleme mit negative assertions variabler laenge (so wie z.b. der texteditor vim, der kann naemlich in dieser hinsicht erstaunlicher mehr als perl), dann sollte diese regexp imho funzen.

in vim waere das regexp-pattern uebrigens
  s/(<[^<>]*)@<!banane([^<>]*>)@!/abbl/g
und hat einen kleinen test von mir bestanden. (iow: vim ist toll!)

kurzer versuch einer erklaerung; ich denke, dass der parser folgendermassen vorgeht:
1. "banane" suchen.
2. schauen, ob davor irgendwie das pattern <[^<>]* angewendet werden kann.
3. falls ja: doofe "banane"; weiter bei punkt 2. (naechste "banane" suchen)
4. falls nein: oha, kanditat gefunden. ueberpruefe restliches pattern.
5. ist es moeglich, nach der "banene" das pattern [^<>]*> matchen zu lassen?
6. falls ja: doofe "banane"; weiter bei punkt 2. (naechste "banane" suchen)
7. falls nein: yeah, die "banane" erfuellt alle kriterien, um ersetzt zu werden.

$muster = '/banane(?=[^>]*<[^>]+>)/i';
$ersatz = 'ananas';
$ergebnis = preg_replace($muster, $ersatz, $heuhaufen);

scheitert an
  "banane"
weil danach nie mehr eine spitze klammer kommt.

besser:
http://www.php-faq.de/q/q-regexp-ersetzen.html

prost
seth

[EisFuX]

(H(all|ih)o|(Gudn\s)?Ta(g|ch)) seth_not@home,

Vorweg: Interessant, was aus einem schlecht strukturiertem PHP-Handbuch
so alles für Probleme entstehen. Wären die POSIX-kompatiblen RegEx dort
so umfangreich abgehandelt worden wie die PCRE, hätte sich die Verwirrung
sicher in Grenzen gehalten, und man hätte hier wahrscheinlich wieder nur
die Einschränkungen bei den negativen Lookbehind-Assertions breitgetreten.

Und dann glaubst du, dass dieses Suchmuster funktioniert?

$suchmuster = "(?<!<[^<>]*)banane(?![^<>]*>)";

angenommen ereg haette keine probleme mit negative assertions variabler laenge (so wie z.b. der texteditor vim, der kann naemlich in dieser hinsicht erstaunlicher mehr als perl), dann sollte diese regexp imho funzen.

Ich hatte angenommen, dass die ereg-Funktionen überhaupt nichts mit
Assertions am Hut haben. Diese Annahme beruht aber lediglich auf
der Tatsache, dass ich das im PHP-Handbuch verlinkte Dokument zu
den Posix-Regexen erfolglos nach "assert"
durchsucht habe ...
http://www.tin.org/bin/man.cgi?section=7&topic=REGEX

in vim waere das regexp-pattern uebrigens
  s/(<[^<>]*)@<!banane([^<>]*>)@!/abbl/g
und hat einen kleinen test von mir bestanden.

Umfasst der Test auch HTML-Kommentare?

(iow: vim ist toll!)

Ooch, wenn dein erster Computer serienmäßig eine Maus gehabt hätte,
wärst du so bequem wie ich und würdest zum Wechseln auch wesentlich
mehr Anreize benötigen. ... und ich wette, über kurz oder lang kann
PSPad das auch. Vielleicht kann er das schon, ich hab nur den passenden
Menüpunkt noch nicht gefunden.
;-)

kurzer versuch einer erklaerung; ich denke, dass der parser folgendermassen vorgeht:

Man könnte natürlich auch Google nach "reguläre ausdrücke in c# assertion" fragen
und dann bspw. das hier finden:
http://mojo-corp.de/regulaere_ausdruecke_c_sharp.html

Ich gehe davon aus, dass der irgendwo in diesem Thread erwähnte
RegexDesigner.NET diese RegEx-Sprache spricht.

1. "banane" suchen.
2. schauen, ob davor irgendwie das pattern <[^<>]* angewendet werden kann.
3. falls ja: doofe "banane"; weiter bei punkt 2. (naechste "banane" suchen)
4. falls nein: oha, kanditat gefunden. ueberpruefe restliches pattern.
5. ist es moeglich, nach der "banene" das pattern [^<>]*> matchen zu lassen?
6. falls ja: doofe "banane"; weiter bei punkt 2. (naechste "banane" suchen)
7. falls nein: yeah, die "banane" erfuellt alle kriterien, um ersetzt zu werden.

$muster = '/banane(?=[^>]*<[^>]+>)/i';
$ersatz = 'ananas';
$ergebnis = preg_replace($muster, $ersatz, $heuhaufen);

scheitert an
  "banane"
weil danach nie mehr eine spitze klammer kommt.

Ich zitiere mal, worauf sich meine "Lösung" bezieht:

es soll im htmlquellcode das wort banane überall ersetzt werden nur nicht in attributen und tags!

In halbwegs validem HTML sollte es eigentlich immer ein "</html>" am Ende des Dokuments geben, oder?

In dem Falle würde der RegEx aber sicher über Kommentare stolpern.

Um 100-prozentig sicher zu gehen, müsste man wahrscheinlich das HTML in Tokens (Tag, Nicht-Tag, Kommentar, ...)
zerlegen und dann nur in den Nicht-Tag-Bereichen ersetzen.

besser:
http://www.php-faq.de/q/q-regexp-ersetzen.html

Ich bin Fan sowohl von "/e" als auch von preg_replace_callback().
Allerdings hat mein Ansatz den Vorteil, dass er bis auf einen
geänderten RegEx und den Austausch von eregi_replace() durch
preg_replace() keinerlei Änderungen am Script braucht. Und somit
hab ich mir auch eine Menge Erklärungen erspart, denn spätestens,
wenn im Ersetzen-String wundersame Zeichen auftauchen, die "escape[dt]"
werden müssen, wird die Variante mit "/e" erklärungsintensiv oder
zumindest unpraktisch.

MffG
EisFuX

[seth_not@home]

gudn tach EisFuX!

angenommen ereg haette keine probleme mit negative assertions variabler laenge (so wie z.b. der texteditor vim, der kann naemlich in dieser hinsicht erstaunlicher mehr als perl), dann sollte diese regexp imho funzen.

Ich hatte angenommen, dass die ereg-Funktionen überhaupt nichts mit Assertions am Hut haben.

das mag ja auch stimmen. im php-handbuch steht ebenfalls (allerdings eher implizit), das ereg das nicht kann. da ich nicht wusste, ob ereg damit klarkommt, sprach ich ja absichtlich im konjunktiv II.

in vim waere das regexp-pattern uebrigens
  s/(<[^<>]*)@<!banane([^<>]*>)@!/abbl/g
und hat einen kleinen test von mir bestanden.
Umfasst der Test auch HTML-Kommentare?

ja. in kommentaren wurde auch brav nicht ersetzt.

(iow: vim ist toll!)

Ooch, wenn dein erster Computer serienmäßig eine Maus gehabt hätte,

hatte er! sie war zwar noch etwas eckiger als die heutigen. aber ansonsten war's ne richtige mouse.

wärst du so bequem wie ich und würdest zum Wechseln auch wesentlich mehr Anreize benötigen.

ich bin noch viel bequemer, weil ich die hand nicht immer zur mouse bewegen will. ;-p
ich bin uebrigens von notepad ueber homesite ueber proton und ultraedit zu vim gewechselt.

... und ich wette, über kurz oder lang kann
PSPad das auch. [...] ;-)

pspad wird aufgrund seiner konzeption niemals vim erreichen koennen.
naja, ok, von firefox dachte ich das auch mal; aber siehe da: "First there was..."

kurzer versuch einer erklaerung; ich denke, dass der parser folgendermassen vorgeht:

Man könnte natürlich auch Google nach "reguläre ausdrücke in c# assertion" fragen
und dann bspw. das hier finden:
http://mojo-corp.de/regulaere_ausdruecke_c_sharp.html

aeh, was meinst du? ich versteh' deinen kommentar im kontext nicht.

$muster = '/banane(?=[^>]*<[^>]+>)/i';

scheitert an
  "banane"
weil danach nie mehr eine spitze klammer kommt.

In halbwegs validem HTML sollte es eigentlich immer ein "</html>" am Ende des Dokuments geben, oder?

oh, stimmt natuerlich.

In dem Falle würde der RegEx aber sicher über Kommentare stolpern.

kommt darauf an, ob man darin uebersetzen will oder nicht.

Um 100-prozentig sicher zu gehen, müsste man wahrscheinlich das HTML in Tokens (Tag, Nicht-Tag, Kommentar, ...)
zerlegen und dann nur in den Nicht-Tag-Bereichen ersetzen.

das waere sicherlich die beste loesung, weil der code dann noch halbwegs gescheit wartbar sein sollte. (fertige html-parser gibt es ja bereits.)
mit regexp ginge es bestimmt auch, aber wuerde wohl zu einem monster fuehren.

prost
seth

[seth_not@home]

gudn tach!

$suchmuster = "(?<!<[^<>]*)banane(?![^<>]*>)";

Sag doch mal, was es bezwecken soll.

ich habe in https://forum.selfhtml.org/?t=161925&m=1053473 versucht, es zu erklaeren.

prost
seth

[Tom]

Hello Seth,

gudn tach!

$suchmuster = "(?<!<[^<>]*)banane(?![^<>]*>)";

Sag doch mal, was es bezwecken soll.

ich habe in https://forum.selfhtml.org/?t=161925&m=1053473 versucht, es zu erklaeren.

Du hattest zwar in https://forum.selfhtml.org/?t=161925&m=1053473 gut erklärt, was Assertions bewirken, aber Roland hatte nicht erklärt, was er eigentlich mit dem Pattgern bezweckte. :-)

Hätte leicht sein können, dass er 'was ganz anderes wollte, als Bananen zu tauschen.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[seth_not@home]

gudn tach!

Du hattest zwar in https://forum.selfhtml.org/?t=161925&m=1053473 gut erklärt, was Assertions bewirken, aber Roland hatte nicht erklärt, was er eigentlich mit dem Pattgern bezweckte. :-)

ach so, ok, dann habe ich wohl schlecht zitiert. ich bezog mich mehr auf deinen kommentar

Da ist doch irgenwie was dopelt zweimal oder so?

und wollte erklaeren, dass da nix doppelt ist. problem ist eigentlich bloss das unvermoegen von php und perl, variable laengen bei negative look-behind assertions zuzulassen.
mit perl6 wird das besser. damit sollte der urspruengliche regexp (plus delimiter) funzen.

prost
seth

[Tom]

Hello,

und wollte erklaeren, dass da nix doppelt ist. problem ist eigentlich bloss das unvermoegen von php und perl, variable laengen bei negative look-behind assertions zuzulassen.
mit perl6 wird das besser. damit sollte der urspruengliche regexp (plus delimiter) funzen.

Inzwischen habe ich auch durchschaut, was Roland erreichen wollte,
aber auch schon die netten Fehlermeldungen kassiert bei preg_replace()

Warning: preg_match_all() [function.preg-match-all]: Compilation failed: lookbehind assertion is not fixed length at offset 11 in ...

Das ist wohl das, was Du meintest.

Das ist 'ne echte Denksportaufgabe. Meinst Du, dass man das hinbekommen kann mit den gegenwärtigen Mitteln?

Ersetzt werden muss dann aber, wenn der gesuchte Text in Spitzen Klammer steht, aber innerhalb eines Substrings

'<banane>  < ..."banane">und noch eine: "Die <banane> ist krumm"  Bananenbrot'

nicht         nicht                       ersetzen             ersetzen

Ich les mich erstmal weiter durch das Tutorial von http://regexp-evaluator.de

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[seth_not@home]

gudn tach!

Warning: preg_match_all() [function.preg-match-all]: Compilation failed: lookbehind assertion is not fixed length at offset 11 in ...

Das ist wohl das, was Du meintest.

genau.

Das ist 'ne echte Denksportaufgabe. Meinst Du, dass man das hinbekommen kann mit den gegenwärtigen Mitteln?

oehm, die von mir in https://forum.selfhtml.org/?t=161925&m=1053473 bereits genannte loesung der faq gefaellt dir nicht?

Ersetzt werden muss dann aber, wenn der gesuchte Text in Spitzen Klammer steht, aber innerhalb eines Substrings

'<banane>  < ..."banane">und noch eine: "Die <banane> ist krumm"  Bananenbrot'

nicht         nicht                       ersetzen             ersetzen

naja, wenn man von html-code ausgeht, sollten doch literale spitze klammern stets als &lt; und &gt; geschrieben werden, oder?

Ich les mich erstmal weiter durch das Tutorial von http://regexp-evaluator.de

hab's mir gerade mal angeschaut. das ist teilweise doch sehr oberflaechlich. waere nicht weiter schlimm, wenn dadurch nicht auch falsche infos vermittelt wuerden. ich kann dir allerdings aus dem stehgreif auch kein besseres online frei verfuegbares tutorial empfehlen.

prost
seth