stayInside

Moinsen,

mit Hilfe von diesem Artikel: BBCode-Parser mit noparse-Tag selbst gemacht - Developer's Guide

habe ich ich mir mein eigenen BBCode Parser gebastelt. Den großen RegExp habe ich fast 1:1 übernommen. Das Problem ist nun allerdings, das er bei bestimmten BBCodes den Apache totschiest.

Also der RegExp:

Sobald der BBCode wie folgt aussieht:

haut der den Apache rund über Kopp.

Hat jemand vielleicht eine Lösung für mein Problem?

Gruß
Benny

Mister Ad

mepeisen

Was genau bedeutet "zerschießen"? Steigts mit einem SegFault aus? Wenn ja: Sind die installierten Versionen aktuell? Wenn Ja: Bug erfassen auf Php.net

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

nikosch

Als erstes würde ich empfehlen, statt [^]] immer [^\]] zu verwenden.

Und hier, was macht der dort

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

stayInside

Den Fehler hatte ich beim Testen auch schon behoben, jedoch ohne Erfolg.

Was mir aufgefallen ist, wenn ich die Delimitter von # auf ° ändern, stürzt Apache zwar nicht ab, aber der Parser erkennt dann auch nichts mehrs.

Edit: hab den übeltäter gefunden:

Dieser Abschnitt macht Probleme, ich denke bis morgen werden damit fertig sein xD

nikosch

Da würde ich das letzte ] auch escapen.

Das: !/ weiss ich nicht, was das da soll
Das: \1 ist imho falsch, weil Du ja Subelemente auch anderer Tags (nicht) matchen willst

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Mati_

Ist nicht nötig. Wenn kein öffnendes (oder ein maskiertes) [ vorhanden ist, bleibt ] ohne Wirkung.
Das Rufzeichen ist Teil des Beginns eines negativen Lookaheads, das / dann wieder ein optionales Zeichenliteral.
Bei Lookarounds wird nichts gematcht. In diesem Fall wird bei dieser Alternative nur geprüft ob ein weiteres, bzw. schließendes Tag von dem aktuell gematchtem [ aus vorhanden ist, und wenn ja, wird zur nächsten Alternative gesprungen, wenn nein, ist die Alternative erfolgreich, und der Matching-Vorgang beginnt aufgrund des +-Quantifiers wieder am Anfang der Gruppe. Solange bis alle Alternativen einmal fehlschlagen.

Der reguläre Ausdruck selbst ist aufgrund dem vorhanden sein von einer schließenden Klammern, die keine zugehörige öffnende Klammer hat, nicht ganz richtig. Ausschnitt aus der letzten Alternative:

nikosch

Naja, schon klar. Ich weiss kein anderes Wort dafür. Intern matcht der Ausdruck erstmal schon den Teilausdruck, um dann festzustellen: Ist Teil eines negativen Lookaround und fällt damit weg.
Gerade /? versehe ich an dem Ausdruck nicht. Prüfung auf schliessendes Tag wäre ja ok, aber ein weiteres öffnendes? Wäre der Ausdruck ungreedy würde zudem das erste schliessende Komplement sowieso durch das abschliessende \1 abgedeckt.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Mati_

Er prüft deswegen auch auf zugehörige öffnende Tags, um die Verschachtelung korrekt zu handhaben. Wird ein weiterer zugehöriger öffnender Tag gefunden, wird zur nächsten Alternative gesprungen, in welcher der gesamte reguläre Ausdruck nochmal aufgerufen wird (und wenn wieder öffnende Tags gefunden wieder. Und dann wieder. Und dann wieder :p). Betrachten wir das etwas näher am indent-Beispiel der Funktionsreferenz zu preg_replace_callback.

Gegeben ist "plain[indent] deep[indent] deeper [/indent]deep [/indent]plain".
Der zugehörige reguläre Ausdruck ist \[indent]((?:[^[]|\[(?!/?indent])|(?R))+)\[/indent].

Das Matching startet beim ersten[indent], dann geht’s weiter bis zum nächsten [. Es ist ein zugehöriger öffnender Tag, die nächste Alternative wird durchgeführt in welcher der Ausdruck nochmal rekursiv aufgerufen wird.

Wieder wird[indent] gematcht, es geht wieder bis zum nachfolgenden [. Diesmal ist es ein zugehöriger schließender Tag, es wird eine erneute Rekursion durchgeführt, die erfolglos ist, da es kein[indent] ist.

In der aktuellen, ersten Rekursion sind nun alle Alternativen abgearbeitet, das [/indent]wird gematcht, und die erste Rekursion war auf „[indent] deeper [/indent]“ erfolgreich.

Nun sind wir wieder im „Hauptlauf“ – die dritte Alternative, also der erste rekursive Aufruf war erfolgreich also geht es weiter, bis zum nächsten [ - das ist das letzte [/intent] im String. Wieder rekursiver Aufruf, dieser schlägt fehl, es geht weiter im „Hauptlauf“ mit dem schließenden [/indent]und der reguläre Ausdruck ist komplett abgearbeitet.

Naja, dass soll es aber bei verschachtelten Tags nicht - bei [b]a[b]b[/b]c[/b] soll der "a[b]b[/b]c"-Teil und nicht "a[b]b" gematcht werden.

nikosch

Da muss ich morgen noch mal drüber nachdenken. Aber cool, ?R kannte ich noch gar nicht.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

Mati_

Ja, das würde ich auch empfehlen ;). Die Sache ist dann mmn. schon wirklich das komplexeste was reguläre Ausdrücke zu bieten haben (gut, in Perl geht's dann noch extremer, da man damit wirklich *alles* machen kann). Muss man sich aufjedenfall über einen längeren Zeitraum mal durch den Kopf gehen lassen.

Achso - bzgl. (?R) - es gibt auch (?<num>) wobei <num> sich auf den Inhalt einer einfangenden Klammer bezieht. Praktisch, wenn der Rekursiv-Teil nur ein Teil eines größeren regulären Ausdruckes ist. Aber man muss sagen, ich verwende diese Elemente eigentlich nie.