Regex-Problem

[c-bob]

Ich habe folgendes Problem:

Aus einem String wie dem folgenden benötige ich die Angaben aus width und height, wobei aber nicht unbedingt festgelegt ist, in welcher Reihenfolge die Attribute innerhalb des img-Tags stehen (was das eigentliche Problem ist)

<p style="text-align: center;">
##<img style="vertical-align: middle; border: 1px solid #000000;" src="/images/bilder/hund.jpg" alt="ein bild" width="500" height="375" />
</p>
<p>text text text text ... </p> 

Ich habe mit folgendem Ausdruck schon ein wenig erhalten, allerdings zeigt er mir nur was an, wenn die Reiehnfolge von width und height auch stimmt:

!##(<img (.*?).width="(.*?)".height="(.*?)".*?>)! 

Wenn im String die Reihenfolge verstauscht ist, funktioniert es nicht. Was muss ich anders machen?
Geht das überhaupt zu bewerkstelligen?

Vielen Dank schonmal
-C-

[AmicaNoctis]

Hallo,

XML-basierte Dokumente behandelt man nicht mit RegEx sondern mit DOMDocument und DOMXPath. Du wirst feststellen, dass das nicht nur sauberer sondern auch leichter ist.

Gruß,

Amica

[c-bob]

Hm, sieht so nicht schlecht aus, aber ich möchte ja kein ganzes Dokument bearbeiten - es soll lediglich ein definiertes img-Tag sein.
Im Grunde genommen sollte das ja möglich sien. Aber irgendwie komme ich drauf :-/

[AmicaNoctis]

Wenn das Dokument nicht mehrere MB groß ist, kommst du mit XPath trotzdem besser.

Wenn du auf deinem RegEx-Kram bestehen willst, musst du alle möglichen Alternativen notieren (mit |).

[c-bob]

Wenn das Dokument nicht mehrere MB groß ist, kommst du mit XPath trotzdem besser.

Wenn du auf deinem RegEx-Kram bestehen willst, musst du alle möglichen Alternativen notieren (mit |).

JaNein, erstmal nochmal danke für die schnellen Antworten. Ich will garnicht auf die Regex bestehen - bin da offen für alle Alternativen. Kenne XPath nur nicht und beim Überfliegen der Doc kam mir das ähnlich komplex wie Regex vor, aber es scheint mir so zu sein, dass XPath eher für ganze Dateien gedacht. Konnte aber noch nicht testen, ob es schon bei einzelnen Tags sinnvoll einzusetzen ist.

Kannst Du auf die Schnelle mit obigem <img>-tag ein Beispiel geben?

Grüße
_c_

[AmicaNoctis]

// angenommen $doc ist dein bereits geladenes Dokument

// XPath-Objekt erzeugen
$xp = new DomXPath($doc);

// Auf Plaintext-Ausgabe umschalten
header("Content-Type: text/plain");

// alle img-Elemente holen, die width und height besitzen
foreach ($xp->query("//img[@width and @height]") as $k => $elem) {

    // formatierte Plaintext-Ausgabe der Bildinformationen
    echo $k + 1, ". [", $elem->getAttribute("src"), "]\n";
    echo "\tBreite: ", $elem->getAttribute("width"), "px\n";
    echo "\tHöhe: ", $elem->getAttribute("height"), "px\n\n";
} 

[c-bob]

Hm, sag mal, schläfst Du garnicht?! ;-)

Ich habe das mal versucht und etwas abgeändert. Wie gesagt, ich habe kein komplettes html-file, ist nur eine kurze kette von tags, welche aus ner mysql kommt. Daher nicht loadHTMLfile. header() funktioniert demnach auch nicht. Aber es funktioniert dann doch irgendwie nicht:

$doc = new DOMDocument();
$doc->loadHTML($row);
$xp = new DomXPath($doc);

// Auf Plaintext-Ausgabe umschalten
//header("Content-Type: text/plain");
var_dump($xp);
// alle img-Elemente holen, die width und height besitzen
foreach ($xp->query("//img[@width and @height]") as $k => $elem) {

    // formatierte Plaintext-Ausgabe der Bildinformationen
    echo $k + 1, ". [", $elem->getAttribute("src"), "]\n";
    echo "\tBreite: ", $elem->getAttribute("width"), "px\n";
    echo "\tHöhe: ", $elem->getAttribute("height"), "px\n\n";
} 

das var_dump war nur zur überprüfung drin - da kommt aber nichtmal etwas raus?!

[AmicaNoctis]

Wenn deine $row wie der Name vermuteln lässt, ein ganzer Datensatz ist, kann ich mir schon vorstellen, warum es nicht funktioniert. Dreh mal dein Error-Reporting auf, so wie es in den Regeln steht.

Wie kommt man eigentlich auf die unsinnige Idee, HTML-Schnipsel in einer DB zu speichern?

[Quetschi]

Wie kommt man eigentlich auf die unsinnige Idee, HTML-Schnipsel in einer DB zu speichern?

Offtopic:
Was ist daran so unsinnig?

[AmicaNoctis]

In eine DB gehören reine Nutzdaten, also Informationen. Daten mit einer internen Struktur lassen sich auf SQL-Ebene nicht vernünftig verwalten (filtern, sortieren, ...) und sind potentiell gefährlich, weil sie einer Sonderbehandlung beim regulären Kontextwechsel bedürfen. Unnötig ist es außerdem, weil es keine Datenstruktur gibt, die sich nicht auch relational in einer Datenbank abbilden ließe.

Zu c-bobs Fall: es ist ja offensichtlich, dass es sinnlose Arbeit ist, die Bildinformationen jedes Mal aus dem HTML-Code in der DB rauszupicken. Würdest du diese Infos in einer Tabelle mit den Spalten (id, src, alt, width, height) speichern, müsstest du sie nur einmal beim Insert aus dem Quelltext lesen und dann kannst du sie beliebig oft bequem abrufen.

[Quetschi]

Zu c-bob:
Ich würde hier eigentlich keinen Quelltext befragen, sondern dass Bild selbst, wenn ich wissen will, wie groß es ist.

AmicaNoctis:
Ich stimme dir mit dem Argument mit den reinen Nutzdaten prinzipiell zu, aber bei einfachen Artikeln mache ich mir beim besten Willen nicht die Arbeit, dass ganze Html aufzudröseln und relational abzubilden um dann den Weg wieder umgekehrt gehen zu können, wenn ich das Html wieder brauche.

Andersrum gefragt:
Du hast irgendwo einen Html-Editor mit dem du Artikel verfasst - kein ganzes Html-Dokument, sondern eben nur ein Fragment. Dieses willst du speichern und später einfach wieder nutzen können. Wie gehst du vor?

Evtl. kannst du die Diskussion hier ausgliedern und verschieben.

[AmicaNoctis]

Andersrum gefragt:
Du hast irgendwo einen Html-Editor mit dem du Artikel verfasst - kein ganzes Html-Dokument, sondern eben nur ein Fragment. Dieses willst du speichern und später einfach wieder nutzen können. Wie gehst du vor?

Entweder in der DB als Nested Sets abbilden oder als XML im Dateisystem ablegen und in der DB den Pfad/Dateinamen speichern.

[Quetschi]

Xml-Files mit Pfad dazu in DB:
Würde bedeuten, dass ich je nach Seite nach dem DB-Zugriff nochmal eine kleinere oder größere Anzahl an Zugriffen auf das Dateisystem brauche - können durchaus mal 50 Zugriffe oder mehr sein. Einen richtigen Vorteil für diese Vorgehensweise gegenüber der direkten Speicherung des Fragments in der DB kann ich nicht wirklich erkennen.

Abbildung als Nested Sets:
Natürlich die schönere Variante, vor allem im Hinblick mit den Daten ggf. auch mal "arbeiten" zu können (Suche usw.). Allerdings vermute ich, dass das bei größeren Artikeln und/oder einer größeren Anzahl an Artikeln in einer Seite für das Auslesen und Zusammensetzen der Html-Struktur doch unnötig Rechenleistung draufgeht.

[AmicaNoctis]

Im Normalfall hab ich in der DB die Nutzdaten und im Dateisystem XSLT-Templates, die dann mit diesen Nutzdaten gefüttert werden. Nehmen wir mal an, dass die Templates modular aufgebaut sind, sich also gegenseitig includieren, dann hat man vielleicht 1 bis 4 Dateizugriffe. Tut das PHP weh? Ich glaube nicht. In vielen Fällen ist es sogar schneller als eine komplexe DB-Abfrage.

[Quetschi]

Nein, Templates includieren bei mir keine anderen Templates - was wo hinkommt, ist bei mir rein in der DB geregelt.