Problem mit URL Parsing
-
nman schrieb:
dEUs schrieb:
was spricht dagegen, es ohne anführungszeichen zu machen? Alles was zwischen [url= und ] steht, gehört zur URL.
Die Tatsache, dass eckige Klammern in URLs vorkommen können.
hm... das ist ein Punkt.
-
Lass doch die Runden-Klammern einfach weg. Das finde ich eh die blödeste Erfindung von MS... Der Link geht auch ohne das (VS.80)!
-
Jochen Kalmbach schrieb:
Lass doch die Runden-Klammern einfach weg. Das finde ich eh die blödeste Erfindung von MS... Der Link geht auch ohne das (VS.80)!
Bei Wikipedia-Links tritt das Problem auch auf.
-
Das Problem wurde schon einige Male diskutiert, aber eine probate Lösung steht noch aus. Es gibt dann immer irgendeine URL, die wieder falsch codiert wird.
-
dEUs schrieb:
nman schrieb:
dEUs schrieb:
was spricht dagegen, es ohne anführungszeichen zu machen? Alles was zwischen [url= und ] steht, gehört zur URL.
Die Tatsache, dass eckige Klammern in URLs vorkommen können.
hm... das ist ein Punkt.
Und wenn man den entsprechenden PHP-Code so anpasst, dass er auf die letzte ']' prüft, die in der eingegebenen URL vorkommt?
Ist zwar ein bisschen umständlicher, aber machbar.
Grüße, NewProggie
-
Wo genau ist denn dann deine URL zu Ende? Am Ende des gesamten Postings?
MfG SideWinder
-
Nein. Eine URL muss wohlgeformte Klammerausdrücke beinhalten (oder? ich hoff doch...)
D.h. die erste schließende eckige Klammer, zu der es im bisher erfassten URL-string keine passende öffnende gibt, ist das Ende des URL-strings.
-
dEUs schrieb:
Nein. Eine URL muss wohlgeformte Klammerausdrücke beinhalten (oder? ich hoff doch...)
RFC?
-
ka. gebietet IMHO die Logik...
-
Das würde aber bedeuten, dann man bewusst Unsinn treiben könnte, indem man einen URI postet, der mehr öffnende als schließende Klammern hat. Auch weniger wären denkbar, aber imho weniger kritisch.
-
Was wäre, wenn man ein Zeichen zum begrenzen verwendet, das in ner URL garantiert nicht vorkommen darf?
url=< ... > beispielsweise.
-
ein Pragmatiker - danke
-
Darf vorkommen, gilt aber als "unsafe character" und darf daher nur enkodiert vorkommen. Das gleiche gilt für die doppelten Anführungszeichen
siehe: http://www.w3.org/Addressing/rfc1738.txt (siehe "2.2. URL Character Encoding Issues")
k.A. wie man verhindern könnte dass falsch kodierte URLs angenommen werden...
-
wenns kodiert ist isses ja kein Problem mehr. Als Begrenzer können einfach beliebige Zeichen dienen, die so in ner URL nicht vorkommen können.
-
Waurm schaut ihr nach runden Klammern? Die url ist doch genau bei ] zu ende.
WindowsImpersonationContext
Würde ja eigentlich funktionieren, wenn ihr nur nach eckigen Klammern schaut. Wer ne eckige Klammer in der url brauch, hat halt pech.
-
dEUs schrieb:
Nein. Eine URL muss wohlgeformte Klammerausdrücke beinhalten (oder? ich hoff doch...)
D.h. die erste schließende eckige Klammer, zu der es im bisher erfassten URL-string keine passende öffnende gibt, ist das Ende des URL-strings.Nein, das wäre für URLs ja auch nicht sinnvoll. <> ließe sich recht gut verwenden, das könnte im Grunde zwar genauso auftauchen wie [] (auch wenn es eigentlich kodiert werden müsste, halten sich daran nicht alle), aber in der freien Wildbahn ist das kaum anzutreffen.
C.Santa: Es gibt eine Menge URLS, die [] enthalten.
-
Eine alternative wäre dem url-Knopf ähnlich dem quote-Knopf noch ein Textfeld zu geben wo man den Link einträgt. Dann könnten vor dem Einfügen die bösen Zeichen kodiert werden.
-
nman schrieb:
dEUs schrieb:
Nein. Eine URL muss wohlgeformte Klammerausdrücke beinhalten (oder? ich hoff doch...)
D.h. die erste schließende eckige Klammer, zu der es im bisher erfassten URL-string keine passende öffnende gibt, ist das Ende des URL-strings.Nein, das wäre für URLs ja auch nicht sinnvoll.
Kannst du das erklären?
Ach ja, das aktuelle RFC für URLs ist http://www.ietf.org/rfc/rfc3986.txt
-
dEUs schrieb:
Kannst du das erklären?
Es geht nicht um RFC-konforme IP-Literale in eckigen Klammern, sondern darum, dass teilweise leider auch unkodierte [] in URLs auftauchen - egal ob das nun erlaubt ist, oder nicht.
Ach ja, das aktuelle RFC für URLs ist http://www.ietf.org/rfc/rfc3986.txt
Danke, kenne ich.
-
nman schrieb:
dEUs schrieb:
Kannst du das erklären?
Es geht nicht um RFC-konforme IP-Literale in eckigen Klammern, sondern darum, dass teilweise leider auch unkodierte [] in URLs auftauchen - egal ob das nun erlaubt ist, oder nicht.
Und? Ich verstehe nicht, was das mit meinem Vorschlag zu tun hat. Auch wenn sie unkodiert auftreten, dann müssen sie wohlgeformt sein, d.h. zu jeder öffnenden auch eine schließende.