Reverse und HTML-Tags

[Christian Michel]

Hallo,

für die Suchmaschine Swish-e habe ich bereits für verschiedene Bereiche einer Webseite Indices erstellt.
Mittels Wildcard (Begriff*) kann ich den Suchbereich auch erweitern

Nun soll die Suche noch einen Schritt weiter gehen.
Es sollen auch Wildcards der Art *Begriff* gefunden werden.
Dafür ist es aber notwendig einen Reverse-Index aufzubauen, da swish-e von Haus  aus keine Reverse-Indices kennt.

Das ganze läuft über die Prog-Schnittstelle und wird an ein Perlscript übergeben.
Dieses soll jede Datei aus dem Suchmuster öffnen und den reinen Text umdrehen.
Dabei müssen aber die Tags gleich bleiben, da swish-e xml-typisch sucht und damit natürlich Fehler auswirft, wenn Tags nicht richtig stehen.

Das Script, bzw. die Regex muss also folgendes leisten:
1. jede Zeile durchgehen
2. den reinen Text umdrehen (reverse)
3. jeden Tag stehen lassen.

Bisher habe ich es aber nur geschafft, Tags auszublenden.
Da ich aber den <font>-Tag benötige, da er als Property definiert ist, ist es also problematisch, alle Tags zu entfernen.

Nun suche ich Ideen, die das Reverse mit einer Regex verbinden.

Wäre für Hilfe bzw. Ansätze sehr dankbar

MfG

CM

[Cheatah]

Hi,

Es sollen auch Wildcards der Art *Begriff* gefunden werden.
Dafür ist es aber notwendig einen Reverse-Index aufzubauen,

bei "*Begriff*" kann Dir auch kein Reverse-Index helfen. Bei "*Begriff" vielleicht, aber nicht mit Wildcard vorne _und_ hinten.

Dabei müssen aber die Tags gleich bleiben,

Ich denke, Du musst Deinen Suchalgorithmus und die verwendeten Techniken noch mal neu bewerten, wenn Du obiges ermöglichen möchtest. Derzeit würdest Du Dich bei der Tag-Geschichte (für die übrigens DOM-Zugriffe ein Ansatz wären) IMHO verrennen.

Cheatah

[Christian Michel]

Hi,

Es sollen auch Wildcards der Art *Begriff* gefunden werden.
Dafür ist es aber notwendig einen Reverse-Index aufzubauen,

bei "*Begriff*" kann Dir auch kein Reverse-Index helfen. Bei "*Begriff" vielleicht, aber nicht mit Wildcard vorne _und_ hinten.

Es war hier ja auch das "*Begriff" gemeint, ich habe es für den Endeffekt nur auf "*Begriff*" verallgemeinert.
Ich brauche eben  nur einen Index in dem Begriff als ffirgeB gelistet ist, damit ich dort ebenfalls eine Wildcardsuche machen kann, um z.B. im Wort Autoversicherung den Teil versicherung auch finden zu können.

Dabei müssen aber die Tags gleich bleiben,

Ich denke, Du musst Deinen Suchalgorithmus und die verwendeten Techniken noch mal neu bewerten, wenn Du obiges ermöglichen möchtest. Derzeit würdest Du Dich bei der Tag-Geschichte (für die übrigens DOM-Zugriffe ein Ansatz wären) IMHO verrennen.

Bzgl. DOM werde ich mal schauen.
Wie gesagt, die Tags müssen erhalten bleiben.
Auch an der Technik wird es wenig zu rütteln geben, Perl bleibt das Mittel zum Zweck
Der Algorithmus an sich kann zwar im Ablauf geändert werden, soll aber im Endeffekt das gleiche Ergebnis bringen.

Inzwischen habe ich außerdem probiert das mittels :
=~ s/alles außer TAGS/Funktionsaufruf(Suchmuster)/g

abzugreifen, aber leider macht er dies mit:
$line =~ s/[^<[^>]+>]/&reverse_text($_)/ig;

noch ned wirklich.

Leider ist Perl nicht meine Stärke, da ich damit bisher wenig gearbeitet habe.
Regex sind sowieso ein Fall für sich. Aber ne Lösung muss es doch für diese Problematik geben.

MfG

CM

Cheatah

[Cheatah]

Hi,

Es war hier ja auch das "*Begriff" gemeint, ich habe es für den Endeffekt nur auf "*Begriff*" verallgemeinert.

bei der Verallgemeinerung versagt aber Dein Index, so dass die Suche auf anderem Weg stattfinden muss - der vermutlich auch die Suche nach "Begriff*" und "*Begriff" trivial ermöglicht.

Inzwischen habe ich außerdem probiert das mittels :
=~ s/alles außer TAGS/Funktionsaufruf(Suchmuster)/g

Regular Expressions sind spätestens ab komplexen Strukturen wie XML oder HTML unbrauchbar; zumindest wenn sie das einzige Mittel sind.

$line =~ s/[^<[^>]+>]/&reverse_text($_)/ig;

Eine Zeichenklasse, bestehend aus allem außer "<", "[", "^" und ">", derer mindestens eins, dann die Zeichenkette ">]". Ich bin nicht ganz sicher, ob es hier nicht sogar einen Parse-Error geben müsste.

Leider ist Perl nicht meine Stärke, da ich damit bisher wenig gearbeitet habe.

Regular Expressions kannst Du hier allenfalls als Hilfsmittel einsetzen. Sie reichen keinesfalls aus, um die Lösung alleine zu liefern. Ich denke, dass Du hier mit DOM (oder vielleicht sogar noch einfacher und performanter: einem SAX-Parser) am ehesten zum Ziel kommst. Suche nach einem passenden CPAN-Modul.

Regex sind sowieso ein Fall für sich. Aber ne Lösung muss es doch für diese Problematik geben.

Nicht mit RegExp. Ich möchte Dir aber noch mal dringend anraten, die grundlegende Wahl von Indexen im Hinblick auf "*...*"-Suchmuster zu überdenken.

Cheatah

[Christian Michel]

Nicht mit RegExp. Ich möchte Dir aber noch mal dringend anraten, die grundlegende Wahl von Indexen im Hinblick auf "*...*"-Suchmuster zu überdenken.

Wenn es aber Kundenwunsch ist, dass ein Begriff auch als Wortteil in Wörtern gefunden wird, dann gibt es nichts zu überdenken.
Wenn der Kunde ein Wildcard vor dem und hinter dem Begriff haben will, dann bekommt er ihn auch.
Ich als Programmierer bin dann nur die ausführende Gewalt.
Schließlich bezahlt der Kunde ja.
Und solange es technisch möglich ist, wird sowas nun mal auch umgesetzt.

Der Hinweis mit dem Parser ist hilfreich, obwohl ich zwischenzeitlich bereits selbst begonnen habe, danach zu suchen.
Trotzdem danke

MfG

CM

[Cheatah]

Hi,

Wenn es aber Kundenwunsch ist, dass ein Begriff auch als Wortteil in Wörtern gefunden wird, dann gibt es nichts zu überdenken.

nicht dies sollst Du überdenken, sondern ob Dir _wegen_ dieser Anforderung ein Index überhaupt helfen kann. Sprich: Das von Dir entschiedene (angestrebte) Vorgehen ist vermutlich nicht zielführend.

Ich als Programmierer bin dann nur die ausführende Gewalt.
Schließlich bezahlt der Kunde ja.
Und solange es technisch möglich ist, wird sowas nun mal auch umgesetzt.

Vergiss trotz alledem nicht, dass Du als Entwickler eine Beratungspflicht hast.

Cheatah

[Christian Michel]

Hi,

Wenn es aber Kundenwunsch ist, dass ein Begriff auch als Wortteil in Wörtern gefunden wird, dann gibt es nichts zu überdenken.

nicht dies sollst Du überdenken, sondern ob Dir _wegen_ dieser Anforderung ein Index überhaupt helfen kann. Sprich: Das von Dir entschiedene (angestrebte) Vorgehen ist vermutlich nicht zielführend.

Die prog-Schnittstelle ist leider die einzige, über die man Swish-E von extern ansprechen kann.
Und die Variante den zu indizierenden Text reverse vorliegen zu haben ist die einzige, um eine Wildcardsuche auch vor einem Wort zu ermöglichen.
Solange swish-e diese Funktionalität nicht mitbringt, muss es so laufen.
Und die Anforderung an diese Funktion ist Standard einer Suchmaschine.

Ich als Programmierer bin dann nur die ausführende Gewalt.
Schließlich bezahlt der Kunde ja.
Und solange es technisch möglich ist, wird sowas nun mal auch umgesetzt.

Vergiss trotz alledem nicht, dass Du als Entwickler eine Beratungspflicht hast.

Das ist klar.
Trotzdem muss es technisch ja möglich sein, Text aus einer HTML-Datei zu nehmen und dann diesen ohne die Tags mit reverse() zu behandeln.
In Teilen habe ich das mit HTML::TokeParser auch schon geschafft.
Er schreibt mir jetzt den reversed-Text aber noch nicht alle anderen Tags etc, sprich den Rest der Datei.
Da ist vermutlich noch ein wenig Feinarbeit angesagt, also die Tokens richtig rausholen.

CM

[Cheatah]

Hi,

Und die Variante den zu indizierenden Text reverse vorliegen zu haben ist die einzige, um eine Wildcardsuche auch vor einem Wort zu ermöglichen.

ich fürchte nur, Dir wird der Text weder in normaler, noch in umgedrehter, noch in geshuffelter oder sonstiger Richtung etwas bringen, wenn Du Wildcards gleichzeitig vor _und_ nach dem Wort erlauben möchtest. Dies muss auf eine völlig andere Weise behandelt werden.

Solange swish-e diese Funktionalität nicht mitbringt, muss es so laufen.
Und die Anforderung an diese Funktion ist Standard einer Suchmaschine.

Ich kenne Swish-E nicht, aber aufgrund Deiner Beschreibung befürchte ich, dass es diese Anforderung nicht zu erfüllen in der Lage ist.

Vergiss trotz alledem nicht, dass Du als Entwickler eine Beratungspflicht hast.
Das ist klar.

Das dachte ich mir :-)

Trotzdem muss es technisch ja möglich sein, Text aus einer HTML-Datei zu nehmen und dann diesen ohne die Tags mit reverse() zu behandeln.

Ja. Nur stehst Du - wenn ich nicht irre - nachdem Du dies geschafft hast vor der nächsten Wand, die Du auf keine Weise überwinden kannst, bei der die geleistete Arbeit nicht für den Papierkorb wäre.

In Teilen habe ich das mit HTML::TokeParser auch schon geschafft.
Er schreibt mir jetzt den reversed-Text aber noch nicht alle anderen Tags etc, sprich den Rest der Datei.
Da ist vermutlich noch ein wenig Feinarbeit angesagt, also die Tokens richtig rausholen.

Damit müsstest Du Recht haben.

Cheatah