Hi Stefan,
Auf jeden Fall ist da ein <s zuviel im QuellCode, das ist ganz klar
ein Bug und möglicherweise ein Hinweis für schrecklichste
Fehlfunktionen im Such- oder Archivskript.... (O Gott!!!)
seit wann führt Bio hier im Forum Selbstgespräche? ;-)
Das Problem entsteht durch die Highlight-Funktion.
Da im Suchausdruck ein einzelnes "P" vorkommt, versucht das Script,
alle p's zu highlighten. Dabei scheint es sich zu verschlucken,
da das Wort "span" im span-Tag, das fuer das Highlighting sorgt,
selber ein p enthaelt. Jedenfalls ist das eine denkbare Erklaerung
dafuer, wie folgender fehlerhafter Quelltext generiert wird (der
vom Mozilla als s-Tag interpretiert wird und fuer die fehlerhafte
Anzeige sorgt):
Hervorragende Analyse.
Ich trau mich aber nicht, an dem Script rumzuschrauben
Ich fürchte, das zu reparieren ist auch keine Sache von zwei Minuten.
Die Funktion "one_hit", welche einen Treffer für die Anzeige vorbereitet,
macht an dieser Stelle etwas relativ Schlichtes (und nicht mal übertrieben
Performantes):
# Lange Form der Trefferanzeige?
my $lang = '';
if ($FORM {'lang'} eq 'on')
{
# -------------------------------------------------
# Anfang des Treffer-Inhalts holen
my $inhalt = $Texte [$i];
# -------------------------------------------------
# Jeden MUST-Term in diesem Text hervorheben
for (my $i = 0; $i <= $#Must_Original; $i++)
{
# -------------------------------------
# Term in die Highlight-Struktur einsetzen
my %strings = ('_COLOR' => farbe ($i),
'_TERM' => $Must_Original [$i]);
my $highlight = style::value ('HIT_HIGHLIGHT', %strings);
# -------------------------------------
# Term durch Highlight-Struktur ersetzen
$inhalt =~ s/$Must[$i]/$highlight/g;
# -------------------------------------
}
# -------------------------------------------------
# Anfang des Treffer-Inhalts in Schablone einsetzen
my %strings = ('_HIT_LONG' => $inhalt);
$lang = style::value ('HIT_PATTERN_LONG', %strings);
# -------------------------------------------------
}
Und in dem Fall, den Bio durch den Suchbegriff "P" provoziert hat,
ist die iterative "Aufbereitung" von $inhalt durch die for-Schleife
um eine Größenordnung zu schlicht.
Um zu verhindern, daß eine eingesetzte Hervorhebung selbst wiederum
hervorgehoben wird, müßte die Analyse des zu highlightenden Texte sehr
viel gründlicher erfolgen. Beispielsweise so:
- in einer Schleife wird jeweils von links der erste Suchbegriff
lokalisiert - die Gesamt-Ausgabe wird dabei in drei Teile zerschnitten (vor dem
Suchbegriff, dieser selbst, danach - der Suchbegriff wird hervorgehoben
- $vorne und $markierter_suchbegriff werden an einen Puffer hinten
angehängt - die Verarbeitung wird mit $hinten fortgesetzt, bis kein weiterer
zu markierender Begriff gefunden wird.
Die Ausgabe müßte also sequentiell "verbraucht" werden, wobei nach
allen Suchbegriffen parallel gesucht werden müßte. Bisher wird ein
Suchbegriff nach dem anderen markiert - genau das verursacht das
Problem, weil spätere Markierungsdurchgänge die bereits eingefügten
Markierungen als Inhalt ansehen und versehentlich nochmal markieren.
(Das können jetzt sicherlich irgendwelche Perl-Hacker wesentlich
schneller in gültigen Code umsetzen als ich ...)
Überhaupt ist es ja noch ein ungelöstes algorithmisches Problem, was
passieren soll, wenn mehrere Suchbegriffe einander überlappend auftreten
- welcher davon soll hervorgehoben werden?
Bisher hätte der jeweils in der Eingabe zuerst stehende Vorrang gehabt,
weil seine Markierung nachfolgende Suchbegriffe "zerrissen" hätte.
aber ich bin sicher, Michael Schroepl wird das hier lesen ... ;-)
Bitte schön.
Das Markierungs-Feature galt von meiner Seite her immer als "experimental";
man könnte man es einfach abschalten, wenn das Bio den Seelenfrieden wieder
geben sollte.
Andererseits kommt das Erkennen dieses Fehlers zu einem günstigen Zeitpunkt
- das ist dann schon mal etwas, das bei der Neu-Implementierung der Suche
nicht wieder verkehrt gemacht werden wird ...
Viele Grüße
Michael