Hi,
$name =~ s/;//gi;
$name =~ s/<//gi;
$name =~ s/>//gi;
$name =~ s/*//gi;
$name =~ s/|//gi;
$name =~ s/[//gi;
$name =~ s/]//gi;
$name =~ s/{//gi;
$name =~ s/}//gi;
$name =~ s/@//gi;Nur als Beispiel der ersten übergebenen CGI-Information. Dieser von mir entwickelte Code (hehe) sollte $name nach zwischen den Slashes stehenden Zeichen (erstes ist ein Semikolon) durchsuchen und gegen ein Leerzeichen ersetzen. -> Soweit die Theorie.
Deine Theorie ist falsch. Es wird nicht durch ein Leerzeichen ersetzt, sondern durch nichts.
Quantifier follows nothing in regex; marked by <-- HERE in m/* <-- HERE / at GuestBookManager.pl line 26. ->Fehlermeldung
Natürlich. * ist ein Quantifier, der im Regex sagt, daß das vorherige Regex-Element 0 bis unendlich oft vorkommen soll - es gibt aber kein vorheriges Element im Regex ==> Fehlermeldung.
Wenn Du Regex-spezifische Zeichen als normale Zeichen verwenden willst, mußt Du sie escapen mit einem \ oder aber das Zeichen in eine Zeichenklasse packen: [*]
Die Verwendung einer Zeichenklasse würde sich sowieso anbieten:
$name = s/[;<>*|[{}@]]//g;
Innerhalb der Zeichenklasse haben nur noch ganz wenige Zeichen Sonderbedeutung (das ^ falls es an erster Stelle steht, das - wenn es nicht an erster Stelle (bzw. an zweiter, falls an erster Stelle ein ^ steht) oder letzter Stelle steht, ])
Das i ist nicht notwendig, da ja keine Buchstaben in Deinem Regex vorhanden sind, es also egal ist, ob Groß- oder Kleinschreibung vorliegt.
http://de.selfhtml.org/perl/sprache/regexpr.htm#beispiel7
Warum die Fehlermeldung?
Weil ein einziges Beispiel nicht den kompletten Leistungsumfang von Regulären Ausdrücken zeigen kann.
Wenn ich dich richtig verstehe (und das ist nicht immer einfach), ist mein Datenbank-Kontext ein Semikolon.
Nein. Es sind im Datenbank-Kontext all die Zeichen zu berücksichtigen, die für die Datenbank eine Sonderbedeutung haben.
Zumindest der \ ist meist auch noch zu beachten.
Üblicherweise bietet das Datenbank-Interface aber Methoden, die sich um das passende Escaping kümmern.
Das und einige andere HTML und Steuerzeichen für Schadcode muss ich allso schon vorher entfernen.
Für die Datenbank ist HTML-Code (wenn Datenbank-Kontext-gerecht escaped) überhaupt kein Problem.
HTML-Code muß dann gesondert behandelt werden, wenn eine Ausgabe in ein HTML-Dokument erfolgt.
Allgemeiner:
Strings müssen immer dann kontext-gerecht behandelt werden, wenn sie in einen anderen Kontext gebracht werden.
cu,
Andreas
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.