nicht angemeldet
reg. Expr funktioniert nicht ganz richtig.
Hi,
Dieses Posting ist eine Ergänzung zu meinem Posting von gestern Nachmittag, aber da ich bei meinem Problem dank MudGuard etwas weitergekommen bin, stehe ich jetzt vor einem anderen Rätsel.
Also gesucht wird ein Ausdruck, der Links in einem Text erkennen soll die nicht zwischen [link] und [/link] stehen. Diese Textabschnitte werden dann rot markiert.
Das Problem ist jetzt, dass die rote Markierung bis zum nächsten Textabschnitt einfach weitergeht, wobei sei eigentlich am Ende des Links aufhören sollte (was ich aber nicht verstehe, weil der folgende reg. Expr. Leerzeichen nicht erlaubt).
Das 2. Problem ist, dass wenn ein Link zb mit www.irgendwas.com anfängt, dieser Link zwar rot markiert wird, aber vor dem www wird ein ; plötzlich hingeschrieben, und ich habe keine blassen Schimmer, wie das dort plötzlich hinkommt. Es sieht dann so aus -> ; www.irgendwas.com.
Hier mal der Ausdruck :
$changetext =~ s/(^[link][A-Za-z0-9._-%&?/+=;]+[^[/link]])/<span class="farbmarkierung">$1</span>/ig
$xNeTworKx.
-
Hi,
Dieses Posting ist eine Ergänzung zu meinem Posting von gestern Nachmittag, aber da ich bei meinem Problem dank MudGuard etwas weitergekommen bin, stehe ich jetzt vor einem anderen Rätsel.Also gesucht wird ein Ausdruck, der Links in einem Text erkennen soll die nicht zwischen [link] und [/link] stehen.
Dafür gibt es das URI::Find Modul im CPAN, vgl. http://search.cpan.org/author/ROSCH/URI-Find/lib/URI/Find.pm
Das Problem ist jetzt, dass die rote Markierung bis zum nächsten Textabschnitt einfach weitergeht, wobei sei eigentlich am Ende des Links aufhören sollte (was ich aber nicht verstehe, weil der folgende reg. Expr. Leerzeichen nicht erlaubt).
Das 2. Problem ist, dass wenn ein Link zb mit www.irgendwas.com anfängt, dieser Link zwar rot markiert wird, aber vor dem www wird ein ; plötzlich hingeschrieben, und ich habe keine blassen Schimmer, wie das dort plötzlich hinkommt. Es sieht dann so aus -> ; www.irgendwas.com.Das passiert höchstens dann, wenn das ; schon vorher da war.
Hier mal der Ausdruck :
$changetext =~ s/(^[link][A-Za-z0-9._-%&?/+=;]+[^[/link]])/<span class="farbmarkierung">$1</span>/igDu hast nicht verstanden, dass [] ausschliesslich für Zeichenklassen funktioniert, [^[link] sucht also nach einem Zeichen, dass nicht l, i, n, k, [, oder ] ist. Du solltest dich in
perldoc perlreüber zero-width negative look-ahead und look-behind Ausdrücke informieren.-
Hi,
Dafür gibt es das URI::Find Modul im CPAN, vgl. http://search.cpan.org/author/ROSCH/URI-Find/lib/URI/Find.pm
Hmmm danke, aber Module, die nicht bei der Standardbibliothek dabei sind, versuche ich zu vermeiden, wenn ich ein Script schreibe, das ich auch weitergeben kann.
Das passiert höchstens dann, wenn das ; schon vorher da war.
Es war sicher nicht da :) Das ist ja das seltsame. Ich habe im Text nie und nimmer ein ; eingegeben.
$xNeTworKx.
-
-
Hi,
$changetext =~ s/([^[link]]
dieses matcht auf z.B. "rzG4?", nicht jedoch auf "in][kl". Bedenke bitte, was eine Zeichenklasse ist.
(https?://|\s+www)
Dir ist klar, dass die Zeichenkette "www" nicht die geringste Bedeutung hat? Ja, ich weiß, warum Du das so gemacht hast; aber das ist IMHO suboptimal. Übrigens gibt es auch FTP-URLs.
[A-Za-z0-9._-%&?/+=;]
Dies matcht auch auf ziemlich viel falsches... etwa auf "/%T/" und "abc???".
Dein ursprüngliches Problem liegt übrigens daran, dass dies greedy ist. In 'perldoc perlre' findest Du mit diesem Suchbegriff die Lösung.
[^[/link]])
Selbiges wie oben.
/<
Dies ist, besonders beim Ersetzungsstring, kein Sonderzeichen, dass man maskieren müsste.
[...]/
Regular Expressions in Perl sind auch z.B. in der Schreibweise s!a!b! möglich, was bei Maskierungen von "/" durchaus einen Lesbarkeitsvorteil darstellt.
span>/ig
Falsch. span>/nend ;-) Übrigens brauchst Du, wenn Du durch "i" die case-sensitivity deaktivierst, in Zeichenklassen nicht explizit Groß- _und_ Kleinbuchstaben anzugeben.
Cheatah
-
Hi,
$changetext =~ s/([^[link]]
dieses matcht auf z.B. "rzG4?", nicht jedoch auf "in][kl". Bedenke bitte, was eine Zeichenklasse ist.
habe zuerst nicht verstanden was du meinst, aber durch Björns Posting ist es mir jetzt klar.
(https?://|\s+www)
Dir ist klar, dass die Zeichenkette "www" nicht die geringste Bedeutung hat? Ja, ich weiß, warum Du das so gemacht hast; aber das ist IMHO suboptimal. Übrigens gibt es auch FTP-URLs.
Ja, aber viele Leute tippen www.irgendwas.com ein. Es wär ein Blödsinn, wenn ich nur nach Buchstaben oder dgl. prüfe.
[A-Za-z0-9._-%&?/+=;]
Dies matcht auch auf ziemlich viel falsches... etwa auf "/%T/" und "abc???".
Ja, aber wie kann man unterscheiden, was richtig oder falsch ist ?
Übrigens hat /%T/ eine bestimmte Funktion ?[^[/link]])
Selbiges wie oben.
=(
/<
Dies ist, besonders beim Ersetzungsstring, kein Sonderzeichen, dass man maskieren müsste.
Hab ichs mir doch gedacht. Ich sehe es nur oft so, deswegen dachte ich, da sei was dran. Habe es heute zum ersten Mal gemacht, werds mir gleich wieder abgewöhnen =)
[...]/
Regular Expressions in Perl sind auch z.B. in der Schreibweise s!a!b! möglich, was bei Maskierungen von "/" durchaus einen Lesbarkeitsvorteil darstellt.
ja ich weis, aber ehrlich gesagt hab ich mich an die / so gewöhnt, dass mich das nicht stört.
span>/ig
Falsch. span>/nend ;-) Übrigens brauchst Du, wenn Du durch "i" die case-sensitivity deaktivierst, in Zeichenklassen nicht explizit Groß- _und_ Kleinbuchstaben anzugeben.
Ok, wieder was dazugelernt =)
$xNeTworKx.
-
Hi,
(https?://|\s+www)
Dir ist klar, dass die Zeichenkette "www" nicht die geringste Bedeutung hat? Ja, ich weiß, warum Du das so gemacht hast; aber das ist IMHO suboptimal. Übrigens gibt es auch FTP-URLs.
Ja, aber viele Leute tippen www.irgendwas.com ein. Es wär ein Blödsinn, wenn ich nur nach Buchstaben oder dgl. prüfe.die gleichen Leute tippen aber auch irgendwas.com ein, wenn sie zu faul sind.
[A-Za-z0-9._-%&?/+=;]
Dies matcht auch auf ziemlich viel falsches... etwa auf "/%T/" und "abc???".
Ja, aber wie kann man unterscheiden, was richtig oder falsch ist ?Beispielsweise könntest Du auf "([a-z...]|%[0-9a-f][0-9a-f])+" testen. Damit sind es dann entweder erlaubte Zeichen oder korrekte Kodierungen. Das Fragezeichen-Problem musst Du lösen, indem Du den Searchpart separierst - es ist maximal ein Fragezeichen erlaubt.
Übrigens hat /%T/ eine bestimmte Funktion ?
Nope, nur das "%".
/<
Dies ist, besonders beim Ersetzungsstring, kein Sonderzeichen, dass man maskieren müsste.
Hab ichs mir doch gedacht. Ich sehe es nur oft so, deswegen dachte ich, da sei was dran. Habe es heute zum ersten Mal gemacht, werds mir gleich wieder abgewöhnen =)Gute Wahl ;-)
Regular Expressions in Perl sind auch z.B. in der Schreibweise s!a!b! möglich, was bei Maskierungen von "/" durchaus einen Lesbarkeitsvorteil darstellt.
ja ich weis, aber ehrlich gesagt hab ich mich an die / so gewöhnt, dass mich das nicht stört.Andere aber schon, die das dann lesen müssen oder wollen. Insbesondere deshalb, weil mehrere Slashes vorkommen.
Cheatah
-
Hi,
die gleichen Leute tippen aber auch irgendwas.com ein, wenn sie zu faul sind.
Ja ich weis. Diese faulen Säcke =(
[A-Za-z0-9._-%&?/+=;]
Dies matcht auch auf ziemlich viel falsches... etwa auf "/%T/" und "abc???".
Ja, aber wie kann man unterscheiden, was richtig oder falsch ist ?Beispielsweise könntest Du auf "([a-z...]|%[0-9a-f][0-9a-f])+" testen. Damit sind es dann entweder erlaubte Zeichen oder korrekte Kodierungen. Das Fragezeichen-Problem musst Du lösen, indem Du den Searchpart separierst - es ist maximal ein Fragezeichen erlaubt.
Hmmmm ok.
Übrigens hat /%T/ eine bestimmte Funktion ?
Nope, nur das "%".
Eins verstehe ich aber nichts ganz. Selbst wenn das % oder sogar ein `` darin vorkommt, kann doch eigentlich gar nichts sein, weil all dieser text wird in einer Variable gespeichert, und kann doch auf keine Weise irgendwie "gefährlich" werden, oder ? Belehre mich bitte eines besseren =)
Andere aber schon, die das dann lesen müssen oder wollen. Insbesondere deshalb, weil mehrere Slashes vorkommen.
Is ein Argument, aber ein guter Perler hat damit sicher kein Problem =)
$xNeTworKx.
-
Hi,
Übrigens hat /%T/ eine bestimmte Funktion ?
Nope, nur das "%".
Eins verstehe ich aber nichts ganz. Selbst wenn das % oder sogar ein `` darin vorkommt, kann doch eigentlich gar nichts sein, weil all dieser text wird in einer Variable gespeichert, und kann doch auf keine Weise irgendwie "gefährlich" werden, oder ? Belehre mich bitte eines besseren =)gerne :-) URLs haben mit Variablen nichts, aber auch gar nichts zu tun. Sie sind lediglich ein String, der ganz links Informationen über Art und Position (Protokoll und IP-Adresse, die sich dem Hostnamen ergibt, nebst eventueller Portangabe und ggf. Login-Informationen) des zu kontaktierenden Servers enthält - der Rest ist (abgesehen vom #Anker, der beim Client bleibt) ausschließlich für den Server interessant.
Dieser nimmt den angeforderten String, teilt ihn in seine - streng definierten - Elemente auf, dekodiert die relevanten, sucht daraus die angeforderte Ressource und liefert diese zurück (was u.U. den Aufruf einer Programmlogik erfordert, welche weitere Elemente der URL dekodiert, bevor es sie weiterverwendet). Die Dekodierung ist es, die ein "%T" verbietet, da das %-Zeichen das Symbol für ein hexadezimal kodiertes Zeichen ist. Die Gefahr besteht hier darin, dass der Server mit einer falsch kodierten URL schlichtweg nichts anfangen kann und einen Fehler meldet. Eine andere Gefahr ist, dass das URL-Parsing mit Fehlerkorrekturen arbeitet und somit langsamer wird.
Andere aber schon, die das dann lesen müssen oder wollen. Insbesondere deshalb, weil mehrere Slashes vorkommen.
Is ein Argument, aber ein guter Perler hat damit sicher kein Problem =)Auch wenn Perl ein Musterbeispiel für kryptischen Code darstellt ;-) ist es das Bestreben eines guten Programmierers, lesbaren Code herzustellen - mindestens solange die Effizienz darunter nicht leidet.
Cheatah
-
Hi,
gerne :-) URLs haben mit Variablen nichts, aber auch gar nichts zu tun. Sie sind lediglich ein String, der ganz links Informationen über Art und Position (Protokoll und IP-Adresse, die sich dem Hostnamen ergibt, nebst eventueller Portangabe und ggf. Login-Informationen) des zu kontaktierenden Servers enthält - der Rest ist (abgesehen vom #Anker, der beim Client bleibt) ausschließlich für den Server interessant.
Dieser nimmt den angeforderten String, teilt ihn in seine - streng definierten - Elemente auf, dekodiert die relevanten, sucht daraus die angeforderte Ressource und liefert diese zurück (was u.U. den Aufruf einer Programmlogik erfordert, welche weitere Elemente der URL dekodiert, bevor es sie weiterverwendet). Die Dekodierung ist es, die ein "%T" verbietet, da das %-Zeichen das Symbol für ein hexadezimal kodiertes Zeichen ist. Die Gefahr besteht hier darin, dass der Server mit einer falsch kodierten URL schlichtweg nichts anfangen kann und einen Fehler meldet. Eine andere Gefahr ist, dass das URL-Parsing mit Fehlerkorrekturen arbeitet und somit langsamer wird.
Das klingt ja ganz schön kompliziert, was ich noch wissen will ist, ob man vielleicht durch sowas theoretisch irgendwelche arglistigen Tricks machen könnte, oder ist das schlimmste was passieren kann das, was du geschildert hast ?
$xNeTworKx.
-
Hi,
Das klingt ja ganz schön kompliziert,
eigentlich nicht. Alles, das in irgendeinem Kontext steht, muss für diesen Kontext kodiert werden - in URLs ungültige Zeichen, im HTML-Code z.B. das "&", in Strings Anführungszeichen und so weiter. Egal, was Du wohin packst, Du musst an die dort nötige Kodierung denken. Das ist bei URLs nicht anders als anderswo.
Und genau wie überall sonst führt eine falsche bzw. nicht durchgeführte Kodierung zu Problemen.
was ich noch wissen will ist, ob man vielleicht durch sowas theoretisch irgendwelche arglistigen Tricks machen könnte,
Es geht Dir um die Erkennung einer URL (bzw. eines URL-Rumpfes, wenn es auch ohne "http://" gehen soll). Wenn Du dabei ungültige URLs _nicht_ erkennst, kann Dir niemand einen Vorwurf machen, und Probleme technischer Natur entstehen auch nicht. Also, sorg einfach nur für eine richtige Erkennung, und alles ist gut.
oder ist das schlimmste was passieren kann das, was du geschildert hast ?
Eine Hacker-Natur wird vermutlich noch weitere Gefahren erkennen. Ich kann Dir nur sagen: Was falsch ist, führt früher oder später zu Problemen, also vermeide Falsches.
Cheatah
-
-
-
-
-
-