[GastForen Programmierung/Entwicklung PHP und MySQL Parseroptimierung für Hilfdirselbst (preg_match)

  • Suche
  • Hilfe
  • Lesezeichen
  • Benutzerliste
Themen
Beiträge
Moderatoren
Letzter Beitrag

Parseroptimierung für Hilfdirselbst (preg_match)

Miro Dietiker
Beiträge gesamt: 699

24. Sep 2003, 15:54
Beitrag # 1 von 18
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo zusammen!

In diesem Forum möchte ich eine Kleine Quizfrage ins Zentrum stellen.

Für das Forum wird in nicht allzuferner Zeit ein Parser eingesetzt,
welcher bestimmte Formatierungen erlaubt (Bekannt aus bsp. bbCode).
Der Parser steht, er arbeitet auch ganz gut, jedoch sind da einige
paar Fragen die ich hier in die Runde werfen will :)

Ein Formatierungszeichen wird in Eckige Klammern geschrieben
[fett] oder [bold] oder wie es dann auch immer heisst wäre ein
solches. Diese können aber auch Optionen haben nach Vorbild HTML
[bild quelle='' formatierungsoption1 option2='']

Das Problem jedoch zeigt sich wie folgt:
Verwende ich im jetzigen Code Die Delimiter '' für Optionen,
kann dieses Zeichen im Inhalt der Option nicht verwendet werden.

Die Schleife welche die Optionen in einen Assoziativen Array packt
sieht wie folgt aus.
// Für den obigen Fall gilt:
$options = "quelle='' formatierungsoption1 option2=''";
// Die Funktion macht nun:

$options .= " ";
while(preg_match("#^( *)([a-zA-Z0-9]*)(=[\']{0,1}(.*?)[\']{0,1})? +(.*)#s", $options, $regs))
{
if($regs[2]=='') { $optarr['default'] = $regs[4]; }
else if($regs[3]=='') { $optarr[$regs[2]] = 1; } // Just a SET-OPTION
else { $optarr[$regs[2]] = $regs[4]; }
$options = $regs[5]; $i++; // Restructurate / Next element
}

Wer kann mir Die Lösung für den Regulären Ausdruck dafür sagen,
dass man im Optionsinhalt selbst auch Zeichen "'" verwenden kann
(und diese dann halt Escapen kann!) bsp. option='bla\'bla\'bla'
oder allenfalls auch escapen durch doppelanwendung 'bla''bla''bla'
wobei zu beachten, dass eine leere Option ''auch als leer matchen
muss! Achtung: die Delimiters ' sollen nicht Pflicht sein, sondern
man kann auch Optionen option=name so schreiben, sofern kein blank
und andere ' delimiter im name enthalten sind!

Für Hilfe hierzu wäre ich echt dankbar .. und ihr werdet auch
etwas davon haben - nämlich ein verbessertes Forum!

Ich arbeite unterdessen am ganzen Rest weiter denn da gibt es noch
viel anderes zu tun :)

Besten Dank!

GrEeZ: Miro Dietiker
X

Parseroptimierung für Hilfdirselbst (preg_match)

oesi50
  
Beiträge gesamt: 2315

24. Sep 2003, 18:27
Beitrag # 2 von 18
Beitrag ID: #52111
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
hi Miro,

solche Ausdrücke
[bild quelle='' formatierungsoption1 option2='']
musst Du recursiv (bzw. iterativ) zerlegen. Mit regulären Ausdrücken alleine wird das zu unübersichtlich und fehleranfällig.

Bsp.
[
bild
quelle=''
Formatierungsoption1
option2=""
option3="der "kleine" Text"
]

Hier siehst Du dann die verschiedenen Möglichkeiten zur Weiterverarbeitung.
1. Beginn [ und Ende ]
2. Schlüsselwort

aus 2. ergibt sich eine weitere Recursion(Iteration)

2.1. Schlüsselwort
2.2. Schlüsselwort = Wert

bei 2.2. gehts weiter

2.2.1. " oder ' Start Quotierung
2.2.2. der Wert selbst
2.2.3. " oder ' Ende Quotierung (passend zum Start abprüfen)

für 2.2.2 kann das dann beliebig oft wiederholt werden (muss aber nicht)

Als Ergebnis sollte dann so ein assoziatives Array enstehen:

bild => ''
quelle => ''
Formatierungsoption1 => ''
option2 => ''
option3 => 'Der "kleine" Text'

Mit dem Array kannst Du jetzt machen was Du willst.

Wenn Deine Ideen noch umfangreicher sind, läuft die ganze Sache auf einen echten Parser (mit Zustandsgraph bzw. Syntaxdiagramm)hinaus.

Eine einfache Übung dazu wäre: Programmiere einen Taschenrechner !

Ich hoffe, ich habe Dich richtig verstanden und konnte Dir weiterhelfen.

Grüße Oesi


als Antwort auf: [#52064]
(Dieser Beitrag wurde von oesi50 am 24. Sep 2003, 18:29 geändert)

Parseroptimierung für Hilfdirselbst (preg_match)

oesi50
  
Beiträge gesamt: 2315

24. Sep 2003, 18:41
Beitrag # 3 von 18
Beitrag ID: #52113
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
@miro

Da Du ja gerade am Forum programmierst, hätte ich noch einen "request for features".

- Beim Antworten soll der Beitrag eingeblendet werden, auf den sich die Antwort bezieht
- Der Link von der Benachrichtigungsmail soll genau auf den jeweiligen Beitrag zeigen
- wenn man sich einloggt soll anschließend wieder genau zur vorherigen Stelle gesprungen werden

Grüße Oesi


als Antwort auf: [#52064]

Parseroptimierung für Hilfdirselbst (preg_match)

Miro Dietiker
Beiträge gesamt: 699

24. Sep 2003, 19:32
Beitrag # 4 von 18
Beitrag ID: #52121
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo lieber oesi!

Zu deinem Kommentar folgendes..

Es handelt sich um einen "echten" Parser, welcher auch über ganz
normale Syntaxdiagramme verfügt ... Der Code ist recht umfangreich
und um einiges mächtiger als man auf den ersten Blick denken würde.

Bei dem von mit geposteten Quellcode handelt es sich um eine
Rekursive Zerlegung des Inhaltes. Die Basisanalyse wird dabei sauber
"von Hand" geparst, wurde schon tausendmal verwendet, getestet,
optimiert, und das Ding zeigt sich sehr schnell!

Ich bin dabei der Meinung, dass Reguläre Ausdrücke für die
Detailanalyse (in diesem Fall Optionen) sehr sauber sind, denn
mit Hochsprachen wie PHP kann man nicht einen effektiven Parser
bauen, welcher auch die Geschwindigkeitsanforderungen erfüllt.
Mein Vergleich (Implementation diverser Teile in meinem Parser)
zeigt mir, dass bei korrekter Anwendung von preg eine extreme
Geschwindigkeitssteigerung erreicht werden kann.

Reguläre ausdrücke unterstützen auch Notationen die Zustände
im Parsing implizieren, wobei man also dasselbe erreichen kann.
Mit einiger Übung lesen sich Reguläre Ausdrücke auch ganz gut
und die Fehleranfälligkeit ist damit reduzierbar.

Das Effektive Problem hast Du dabei leider überlesen. Du machst
nämlich im ersten Schritt einfach eine Option:
option3="der "kleine" Text"
Dass diese Trennung rekursiv nicht ein-eindeutig ist hast du leider
übersehen..
Das Syntaxdiagramm für dieses Escapen von In-quote-quotes
(wie oben notiert) in beiden Varianten ist mir bekannt.
Ich bin einfach in der notation dieser Spezialitäten in regulären
Ausdrücken noch nicht ganz so gewandt.
(Dieses Quoting sollte sich mittels "lookahead"- und "lookbehind"-assertions korrekt behandeln lassen!!!)

Die alternative Implementation (parsing mir stringfunktionen in PHP)
wollte ich auf dieser Ebene nicht einsetzen und würde ich auch erst
als letzte Lösung nehmen. (Wenn alle anderen Probleme gelöst sind)

sorry, wenn ich mich zu "unüberlegt" ausgedrückt habe...

:) so jetzt muss ich aber weg ....

GrEeZ: Miro Dietiker


als Antwort auf: [#52064]

Parseroptimierung für Hilfdirselbst (preg_match)

oesi50
  
Beiträge gesamt: 2315

25. Sep 2003, 17:27
Beitrag # 5 von 18
Beitrag ID: #52318
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
hi Miro,

ich hab mich wohl auch etwas verquer ausgedrückt.

Meine Überlegungen gingen mehr in der Richtung, das ganze recursiv zu erledigen.
Dazu gibt es bei preg_replace den e modifier, hier wird der replacement string als PHP-code evaluiert. Wenn jetzt darin preg_replace wieder mit e auftritt, erhält man eine schöne Recursion.
Somit kann die Verschachtelung so tief sein, wie der Speicher reicht.
Zusätzlich kann man ja auch div. Subroutinen mit einbauen, die je nach Zustand die Verarbeitung von preg_replace steuern.

Die Trennung von option3="der "kleine" Text" ist sehr wohl eindeutig.

Tiefe 1

option3
=
"der "kleine" Text"

Tiefe 2

"der "kleine" Text"

Tiefe 3
der
"kleine"
Text

Tiefe 4
kleine

Bei welcher Recursionstiefe abgebrochen wird, ist natürlich steuerbar.

Grüße Oesi


als Antwort auf: [#52064]
(Dieser Beitrag wurde von oesi50 am 25. Sep 2003, 17:37 geändert)

Parseroptimierung für Hilfdirselbst (preg_match)

Miro Dietiker
Beiträge gesamt: 699

25. Sep 2003, 17:48
Beitrag # 6 von 18
Beitrag ID: #52321
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Da habe ich offenbar etwas nicht begriffen!

Wenn ich meine Syntaktischen überlegungen anwende auf den Ausdruck:
[tag op1="test" bla" test" op2="anderer_test"]

So würde nach dem zweiten Delimiter der Zustand "optionsbezeichner
gefunden, suchen nach argumenten" verlassen. bla würde er dann
versuchen als optionsbbezeichner zu nehmen, wobei dann " kommt,
was komplett gegen die Syntax verstösst. Allenfalls würde er 'bla"'
und 'test"' noch als SET-Option interpretieren können..

Nach meiner auffassung müss man hier ein Escapecharakter einführen:
VAR A: Mit Charakterverdoppelung '"' ist Escapecharakter für '"'
[tag op1="test"" bla"" test" op2="anderer_test"]
VAR B: Mit Fester Escapesequenz
[tag op1="test\" bla\" test" op2="anderer_test"]

Der Escapecharakter für das Tag selbst bsp. ist auch der Charakter
selbst (das tönt jetzt beschissen)..
Konkret: will ein user, dass sein Tag nicht interpretiert wird,
so schreibe er es als [. (D.H. "[" ist Escapecharakter für "[")

Was mache ich jetzt zu kompliziert?

GrEeZ: Miro Dietiker


als Antwort auf: [#52064]

Parseroptimierung für Hilfdirselbst (preg_match)

oesi50
  
Beiträge gesamt: 2315

25. Sep 2003, 18:12
Beitrag # 7 von 18
Beitrag ID: #52328
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
achso, der User soll quotieren können

wie wärs denn damit:
'' oder
'[spezial option="der "kleine" Text]'

da trifft dann einfach /^'([^']*)'$/ irgendwann nach der Zerlegung in beliebiger Recursionstiefe.

Grüße Oesi


als Antwort auf: [#52064]
(Dieser Beitrag wurde von oesi50 am 25. Sep 2003, 18:20 geändert)

Parseroptimierung für Hilfdirselbst (preg_match)

Miro Dietiker
Beiträge gesamt: 699

25. Sep 2003, 20:38
Beitrag # 8 von 18
Beitrag ID: #52349
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Irgendwie habe ich das Gefühl, wir reden aneinander vorbei ;)

Wie sagt man so schön: Der Teufel steckt im Detail..

Aber wenn ich jetzt den ganzen code hier posten würde, dann
würd' wohl niemand mehr weiterlesen ;) denn nach n'paar hundert
Zeilen würde sich wohl jeder geschlagen geben (ich würde eine
solche Diskussion ja auch nicht weiterverfolgen) .)

Vielleicht verfolgt ja sonst jemand die Diskussion und meldet sich
plötzlich zu wort ...

GrEeZ: Miro Dietiker


als Antwort auf: [#52064]

Parseroptimierung für Hilfdirselbst (preg_match)

oesi50
  
Beiträge gesamt: 2315

25. Sep 2003, 20:58
Beitrag # 9 von 18
Beitrag ID: #52352
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
ich merk schon, das soll alles auf einmal gehen.

/\[([^ ]*?) *([^ ]*?) *([^ ]*?) *([^ ]*?) *([^ ]*?)\]/

trifft z.B. alle folgenden
[fett]
[bild quelle='' formatierungsoption1 option2='']
[tag op1="test" bla" test" op2="anderer_test"]

beim Letzten ensteht allerdings:

tag
op1="test"
bla"
test"
op2="anderer_test"

ob das überhaupt so sein soll, ist fraglich.

Wenn Du mal von JEDER Möglichkeit die vorgesehen ist, ein korrektes Beispiel postest, bau ich Dir ein Code-Beispiel.

Grüße Oesi


als Antwort auf: [#52064]
(Dieser Beitrag wurde von oesi50 am 25. Sep 2003, 20:59 geändert)

Parseroptimierung für Hilfdirselbst (preg_match)

Miro Dietiker
Beiträge gesamt: 699

26. Sep 2003, 00:10
Beitrag # 10 von 18
Beitrag ID: #52368
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Irgendwie habe ich das Gefühl, dass die Problemstellung nicht ganz
rübergekommen ist.

Um mal ganz grundlegend und ausholend zu erläutern:
Es handelt sich um ein Parsermodul (genannt "parser"), welcher ein
Textabschnitt analysiert und ein Strukturabbild macht. Er selbst
führt keine Befehle aus, sondern kennt nur generische "Arten" von
Tags. Diese Arten sind nicht durch ihre konkreten Namen oder
inhalte definiert, sondern abstrakt und rekursiv!
Zur Interpretation nimmt er ein Modul (genannt "interpreter")
bei welchem er sich laufend während des parsens meldet und anfragt,
ob diese generischen tags existieren. der interpreter verarbeitet
und liefert die antworten dem parser zurück, der parser wiederum
entfernt die ursprünglichen tags und ersetzt diese durch die vom
Interpreter neu errechneten. Speziell ist, dass es tags geben kann,
welche rekursionen enthalten - also das durch den interpreter
interpretierte und eingesetzte nochmals geparst wird. Bei jedem
Ersetzen eines tags durch den interpreter wird die ersetzungsart
definiert.

Der Parser also weiss nichts über den genauen Laut der Tags,
kennt nur deren Struktur und weiss auch nicht wieviele Optionen
es sind. Er baut anhand der Struktur von jedem Tag ein Options-
Array auf und liefert dieses dem Interpreter, der mit diesem
Array Entscheidungen treffen kann.


Ein Tag kann bsp. so aussehen:

// Einfaches Tag (SingleTag)
ich werde italic // Standard Tag (Zwangsabschluss)

Jedes Tag kann also weiter nach dem Namen einen Abstand haben
und dahinter BELIEBIG viele Optionen! Jede Option kann wiederum
vom Typ "SET" sein, also nur ein Optionsname, kann aber auch ein
Wert zugewiesen haben! Der zugewiesene Wert kann dabei
entweder gequotet werden, oder aber auch nicht. Das Quoting ist
dabei eindeutig, das heisst In-Quoting muss geescaped werden!

[absatz fett] // Könnte ein Absatz sein, mit Attribut fett gesetzt
[absatz schrift=Arial] // Könnte ein Absatz sein, beidem eine Option
namens Schrift mit den Attribut Arial gesetzt wurde
[absatz schrift="Arial"] // Wie oben, nur gequotet!

Natürlich kann aus Sicht des Parsers (Da er ja kein TAG kennt)
jedes Tag beliebig viele Optionen haben!
[absatz fett kursiv schrift="Arial" size=7]
Müsste also korrekt analysiert werden.

Der Parser nun kann das schon alles seit ewigkeiten, der Interpreter
auch (Saubere Klassenimplementationen, wobei man je nach Anwendung
einfach durch Ableiten des generischen Interpreters ein angepassten
Wortschatz (Tag-Library) machen kann.

Das Problem liegt darin, dass wenn beim oberen Beispiel der text:
[absatz fett kursiv schrift="Arial" size=7]
erkannt wurde, die Variable "options" folgenden Inhalt hat:
$options=' fett kursiv schrift="Arial" size=7'

Dies kann effizienter mit einem regulären Ausdruck zerlegt werden,
als mit einem handgeschriebenen Parser in PHP, da regexp einfach
schneller ist (Implementation der core auf tieferer ebene).

Es handelt sich dabei um einen ausdruck, welcher rekursiv auf
diesen obigen $options-string angewendet wird! Dabei muss allerdings
das Problem Optionales Quoting, als auch In-Quote-Quoting (ge-
escaped) via regexp korrekt gehandlet werden!
'schrift="The ""Ultrafont"""'
Dabei heisst die Schrift selber 'The "Ultrafont"'
Der einheitliche Ausdruck muss also:
- Rekursiv anwendbar sein
- SET-Options matchen
- Einfache Optionen matchen (unquoted)
- Gequotete Optionen matchen, und geescapte Quotes überlesen
Pro Option gilt es, einen Match rekursiv auszuführen und dieselben
nicht nachträglich zusammenzusetzen!

Ohne Lookahead und Lookbehind Assertions keine chance, und wenn
ich deine Reg-Ausdrücke ansehe, scheinst du nicht zu wissen von
was ich rede .. Ein hochinteressantes Thema mit welchem man
sich ein Leben lang auseinandersetzen kann!!

Die jetzige Lösung (Siehe mein erstes Posting) kann das auch alles,
erlaubt einfach keine In-Quote-Quotes. Mit anderen Worten, es ist
nicht möglich ein Optionsinhalt zu definieren, welcher das Zeichen
' enthält, da er immer gleich das Ende des Optionsinhalts annimmt.

"#^( *)([a-zA-Z0-9]*)(=[\']{0,1}(.*?)[\']{0,1})? +(.*)#s"
entspricht dabei der definition dieses Matchings!

Da lass ich mich einmal mehr überraschen auf die Antwort ;)

GrEeZ: Miro Dietiker


als Antwort auf: [#52064]

Parseroptimierung für Hilfdirselbst (preg_match)

oesi50
  
Beiträge gesamt: 2315

27. Sep 2003, 10:13
Beitrag # 11 von 18
Beitrag ID: #52511
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
hi Miro,

In der Hoffnung, dich jetzt richtig verstanden zu haben, poste ich einfach mal folgenden Code:

$options = "quelle='' formatierungsoption1 option2='xy\'uhu\'abc'";
$options .= " ";
while(preg_match("#^( *)([a-zA-Z0-9]*)(=[']?(.*?)[']?)? +(.*)#s", $options, $regs))
{
$options = $regs[5];
if($regs[2]=='') { $optarr['default'] = $regs[4]; }
else if($regs[3]=='') { $optarr[$regs[2]] = 1; } // Just a SET-OPTION
else {
$temp1 = preg_replace("/(\\(.)){1}","/$2/",$regs[4]);
$temp2 = $regs[2];
$optarr[$temp2] = $temp1;
}
$i++; // Restructurate / Next element
}

Hier kann innerhalb der Werte ($4) jedes Zeichen mit \ escaped werden. Das \ muß natürlich jetzt zwingend escaped werden.

Grüße Oesi


als Antwort auf: [#52064]
(Dieser Beitrag wurde von oesi50 am 27. Sep 2003, 11:07 geändert)

Parseroptimierung für Hilfdirselbst (preg_match)

Miro Dietiker
Beiträge gesamt: 699

27. Sep 2003, 14:46
Beitrag # 12 von 18
Beitrag ID: #52525
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Oesi

Ja, der Weg trifft schon eher..

Das Problem jedoch (ohne es zu testen) sehe ich mit deinem
Ansatz jedoch noch lange nicht gelöst!

Im äusseren rekursiven/iterativen Teil hast du als Matching für
die Option folgendes Teil: (=[']?(.*?)[']?)? +
Nach meiner Kenntni von Regexp trifft dies ungenügend die
Anforderungen. Änderst du doch die Greedyness mit '?', sind jedoch
die Quotes so nicht Optional, als auch der Inhalt nicht beliebig
Escapebar und In-Quote-Quotebar

Eine Option die wie folgt aussieht:
option2='xy\' u hu\' abc'
(Also auch innerhalb der zu erwartenden zulässigen optionswerte)
würde zerstückelt und als erste Option NUR option2='xy\' genommen!
Da bringt alles spätere Feilen am gematchten der Escapes nichts..

Wie bereits angesprochen: Dieses Problem ist nicht ohne
Lookbehind und Lookahead assertions lösbar!
Schau doch mal im Handbuch Thema Pettern Syntax unter diesem Begriff
nach.. Dabei muss man folgendes definieren:
1. dass am Beginn der Option ein Quote sein kann
2. dass am Ende zwingend das quote steht das auch am Anfang
gestanden hat (nämlich eines oder keines)
3. Machen dass jedes im Inhalt gesichtete Quote nicht vorher ein
\ hatte (wenn denn mit \ geescapet wird) was nach meiner
Auffassung einem Lookbehind entspricht, oder umkehren und
nach \ suchen und dieses überlesen, solange ein Quote danach kommt

Und das Ganze im äusseren Teil der rekursion..

Aber trotzdem danke :)

GrEeZ: Miro Dietiker


als Antwort auf: [#52064]

Parseroptimierung für Hilfdirselbst (preg_match)

oesi50
  
Beiträge gesamt: 2315

27. Sep 2003, 17:03
Beitrag # 13 von 18
Beitrag ID: #52537
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
hi Miro,

wie wärs denn damit?

$options = " $options";
while( preg_match("/(.*) +(([\w\d]+)(=(.*))?)?$/s", $options, $regs) ) {
$options = $regs[1];
$k = $regs[3];
$v = $regs[5];
preg_replace("/^['](.*)[']$/", "/$1/" , $v);
preg_replace("/(\\(.)){1}/g", "/$2/" ,$v);
$optarr[$k] = $v || 1;
$i++;# // Restructurate / Next element
}

Grüße Oesi

PS.: Das ist eine Iteration
PPS.: Schau mal in Dein Handbuch was der Unterschied zw. [']{0,1} und [']? ist.


als Antwort auf: [#52064]
(Dieser Beitrag wurde von oesi50 am 27. Sep 2003, 17:04 geändert)

Parseroptimierung für Hilfdirselbst (preg_match)

Miro Dietiker
Beiträge gesamt: 699

28. Sep 2003, 22:39
Beitrag # 14 von 18
Beitrag ID: #52621
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Re!

Zum Thema [']{0,1} und [']? gebe ich mich geschlagen

Zum anderen jedoch - Auch wenn du die rekursion jetzt von hinten
nach vorne machst (fine ich ein interessanter Ansatz) ändert es
nichts am grundlegenden Problem:

Wenn eine Option so aussieht (und auch da sohne zu testen, doch
denke ich die regexp aus meinen leseverständnissen anzuwenden)
obwohl ich mich irren könnte ;) :
"/(.*) +(([\w\d]+)(=(.*))?)?$/s"

Matcht leider auch bei folgender Option falsch!
[meintag option='text=anderertext']

Und weshalb sollte ich jemandem verbieten und einem Optionsinhalt
die Text " wortoderzahl=" drin zu haben?

Auf alles weiter nehme ich deshalb noch keine weitere Stellung,
da es meines Erachtens dieses Problem nicht nachträglich lösen kann.

Ich bleibe noch immer beim Lookahead / Lookbehind! *smile*

GrEeZ: Miro Dietiker


als Antwort auf: [#52064]

Parseroptimierung für Hilfdirselbst (preg_match)

oesi50
  
Beiträge gesamt: 2315

28. Sep 2003, 22:49
Beitrag # 15 von 18
Beitrag ID: #52622
Bewertung:
(3894 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
hi Miro,

teste doch mal, dann siehst Du was geht und was nicht. :-)

Grüße Oesi
PS. Das ist immer noch ein Iteration


als Antwort auf: [#52064]
(Dieser Beitrag wurde von oesi50 am 28. Sep 2003, 22:51 geändert)
X