Reguläre Ausdrücke - Zeichenkette ausschließen - preg_match

[einermeiner]

Ich möchte eine Zeichenkette aussschließen:

    preg_match('/(.*)\<div id="top"\>([^(<\/div)]*)\<\/div\>(.*)/', $str, $treffer ); 

Nach dem div id="top"\> soll jedes beliebige Zeichen in beliebiger Häufigkei vorkommen dürfen, außer die Zeichenkette "<\/div>".
Wie muss ich den Code ändern, möchte nachher die beliebigen Zeichen in dem Array haben.

[h3ll]

Warum verwendest du nicht einen HTML-Parser dafür? Sowas ist doch besser geeignet als eine Regex.

[TobiaZ]

Prüf doch einfach, ob '<div id="top"></div>' enthalten ist. Dafür braucht man weder preg noch irgendwelche parser zu bemühen.

[fireweasel]

Ich möchte eine Zeichenkette aussschließen:

    preg_match('/(.*)\<div id="top"\>([^(<\/div)]*)\<\/div\>(.*)/', $str, $treffer ); 

Nach dem div id="top"\> soll jedes beliebige Zeichen in beliebiger Häufigkei vorkommen dürfen, außer die Zeichenkette "<\/div>".
Wie muss ich den Code ändern, möchte nachher die beliebigen Zeichen in dem Array haben.

Du hast die Beschreibung selbst geliefert. So wird sie umgesetzt:

.*?(?=<\/div>)/s

.* ein beliebiges Zeichen, beliebig oft
? aber bitte nur die kürzestmögliche Version
(?=<\/div>) direkt gefolgt von '<\/div>'
/s sorgt dafür, dass '.' auf ein beliebiges Zeichen passt

Google-Stichwort: "lookahead assertion"

[AmicaNoctis]

Hallo,

das Problem dabei ist, dass in dem div#top kein weiteres div sein darf, sonst wird dessen schließendes Tag gematcht:

<div id="top">...<div>...</div>...</div>
\_____________________________/

Es geht zwar mit Regulären Ausdrücken trotzdem, aber es ist einfacher, es als DomDocument zu laden und mit XPath zu suchen.

Wenn es trotzdem unbedingt sein muss, kommt man bei sowas raus:

$name = "[\\w:\\-]+";
$atts = "(?:\\s+" . $name . "=(?:'[^']*'|\"[^\"]*\"|" . $name . "))*";
$begin = "<div\\s+id=\"top\"\\s*>";
$end = "</div>";
$startTag = "<(" . $name . ")" . $atts . "\\s*>";
$emptyTag = "<" . $name . $atts . "\\s*/>";
$regex = "!" . $begin . "([^<>]+|" . $emptyTag . "|" . $startTag . "(?1)</\\2>)*" . $end . "!"; 

Gruß,

Amica

[einermeiner]

Danke, funktioniert soweit auch, ich verstehe es zwar nicht mehr aber egal.

Wo müssen Klammern gesetze werden, damit ich die verschiedenen Teile jeweils in das Array bekomme?
Also das vor dem <div id=..., das dazwischen ist ja schon im Array und alles was danach steht, damit ich es dann wieder zusammensetzen kann?

[AmicaNoctis]

Vergiss es. Wenn du den Regex schon nicht verstehst, solltest du ihn nicht in deinen Code einbauen. Du wirst das später nicht mehr warten, nachvollziehen, debuggen, ändern, erweitern können und damit sollte an dieser Stelle Schluss sein mit Regex. Um XML zu verarbeiten, gibt es entsprechende eingebaute Klassen. Diese dafür nicht zu nützen wäre schlichtweg bescheuert.

Sieh dir im Handbuch DOMDocument und DOMXPath an und nimm bitte bitte diese beiden dafür.

[einermeiner]

Der Code wird nur einmal gebraucht.
Es soll in einem Dokument mit vielen div id=top
danach gesucht werden und ein bestimmtes Wort, das sich in diesem div befindet, soll ersetzt werden.

Jetzt weiß ich jedenfalls, was ich lernen muss --> reguläre Ausdrücke.
Dieses DOMDocument kenne ich überhaupt nicht.

[AmicaNoctis]

Ein Dokument mit vielen <div id="top"> darf es gar nicht geben. In HTML muss das id-Attribut eindeutig sein.

Wenn dazwischen nur ein Wort steht und definitiv keine Tags mehr, sollte auch '!<div\\s+id="top">([^<]*)</div>!' ausreichen, aber trotzdem würde ich nicht mit Regex arbeiten, wenn es um XML/HTML geht (und ich halte mich für ziemlich erfahren was Regex angeht).

[einermeiner]

OK
Ist jetzt auch nicht so wichtig, dieses Skript.

Kannst du mir eine deutsche Seite empfehlen, mit der ich Reguläre Ausdrücke lernen kann?
Die sind in allen Sprachen weitgehend gleich aufgebaut oder?

[AmicaNoctis]

Kannst du mir eine deutsche Seite empfehlen, mit der ich Reguläre Ausdrücke lernen kann?

regenechsen.de

Die sind in allen Sprachen weitgehend gleich aufgebaut oder?

So ziemlich. Nicht überall sind alle Features verfügbar, aber die Grundlagen bleiben gleich. In PHP sind sie aber noch etwas mächtiger (da Perl-kompatibel) als z. B. in JavaScript. Daher gibt es im PHP-Bereich durchaus schon mal etwas komplexere Sachen zu finden, wo man dann als Einsteiger doch nochmal das PHP-Handbuch konsultieren sollte, auch wenn der Teil auf englisch ist.

[einermeiner]

Den Kurs werde ich durchgehen, da ich in PHP wohl noch öfters RexEx benötige.

[fireweasel]

Hallo,

das Problem dabei ist, dass in dem div#top kein weiteres div sein darf, sonst wird dessen schließendes Tag gematcht:

<div id="top">...<div>...</div>...</div>
\_____________________________/

Klar. Möglicherweise könnte man hier mit Rekursion was machen. Ich wollte das Ganze aber nicht weiter verkomplizieren.

Es geht zwar mit Regulären Ausdrücken trotzdem, aber es ist einfacher, es als DomDocument zu laden und mit XPath zu suchen.

Ein Dokument mit vielen <div id="top"> darf es gar nicht geben. In HTML muss das id-Attribut eindeutig sein.

Hier stellt sich mir die Frage: Wie baut ein (X)(HT)ML-Parser (regelwidrige) multiple IDs in seinen DOM-Baum ein und komme ich einfach an sie ran?
(Ich hatte den Fall noch nicht und war zu faul es auszuprobieren)

[AmicaNoctis]

Hier stellt sich mir die Frage: Wie baut ein (X)(HT)ML-Parser (regelwidrige) multiple IDs in seinen DOM-Baum ein und komme ich einfach an sie ran?

Solange du es nicht gegen die DTD validierst und keine mehrdeutigen Attribute mit dem Namen xml:id gibt, weiß der Parser nicht, dass das id-Attribut eindeutig sein muss und wird nichts zu meckern haben (solange es sonst wohlgeformt ist).

[wahsaga]

Hier stellt sich mir die Frage: Wie baut ein (X)(HT)ML-Parser (regelwidrige) multiple IDs in seinen DOM-Baum ein

Hier wären zwei Fälle zu unterscheiden:
Ein XML-Parser hat nicht nur das Recht, sondern die Pflicht, dir dafür beim Parsen einen Fehler um die Ohren zu hauen und das Erstellen eines DOM-Baumes zu verweigern - sofern das id-Attribut auch in der DTD bzw. dem Schema als vom Typ ID deklariert ist; ohne das wäre es nämlich nur ein Attribut wie jedes andere.
Ein HTML-Tag-Soup-Parser hingegen wird das idR. einfach ignorieren, und erst mal alle Elemente unter Verwendung dieser ID ins DOM einbauen.

HTML5 fängt an, das Verhalten dieser Tag-Soup-Parser im Fehlerfalle zu spezifizieren (um den Wildwuchs aus der Praxis etwas unter Kontrolle zu kriegen) - aber in Bezug auf speziell dieses Szenario konnte ich darin auf die Schnelle keine Aussage finden.

und komme ich einfach an sie ran?

In meinem Test mit drei DIV-Elementen mit gleicher id="test" wenden alle meine Testbrowser eine simple Formatierung über
#test { background:red; }
auf alle drei DIV-Elemente an.

Bei komplexeren Selektoren mag das aber u.U. anders aussehen (Kombinationen mit :first-child oder was weiß ich).

Beim Zugriff über JavaScript bekomme ich das Verhalten, das zu erwarten wäre - da liefert mir
document.getElementById("test").innerHTML
jeweils nur den Inhalt des ersten dieser DIVs (ebenfalls übergreifend). Der Test auf eine .length-Eigenschaft der Rückgabe von getElementById verlief in allen Browsern negativ - dass da irgendeiner eine NodeList o.ä. draus zusammenstellt, scheint also auch nicht der Fall zu sein.

Sogar gegenüber DOM-Manipulationen verhält es sich relativ „robust“ in der Hinsicht, dass das Verhalten konsistent bleibt - erzeuge ich ein weiteres DIV-Element mit der gleichen ID und hänge es per insertBefore als neues erstes Kindelement in body ein, erhalte ich anschließend beim Zugriff über die ID wie oben dessen innerHTML-Inhalt.
Auch das Clonen dieser DIV-Elemente behält die gesetzte ID bei, und Zugriff auf „weiter hinten“ im DOM liegende Elemente über getElementsByTagName o.ä. gibt den Inhalt von deren ID-Attributen immer noch als "test" aus.

Zugriff auf die „weiteren“ Elemente ist aber verständlicher weise nicht über getElementById möglich.


Von dem ganzen abgesehen ist und bleibt es in der Praxis aber natürlich eine dumme Idee, diesen Fehler mutwillig zu produzieren.