Problem mit URL Parsing
-
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.
-
Das habe ich auf die schnelle nicht finden können. Kannst Du den relevanten Teil kurz raussuchen? Ich verstehe auch nicht wirklich, warum man sowas vorschreiben sollte. Klingt für mich ähnlich, als würde man in Texten ne gerade Anzahl von as fordern oder so.
-
wie gesagt, ich finde es logisch. Obs im RFC steht, müsste sich mal jemand die Mühe machen und gucken.
-
Mein Einwand "RFC?" bezog sich eben darauf mir die Stelle zu zeigen, wo das in der RFC definiert wird - wird es nämlich nicht.
Wir haben noch so ein Ding mit , in URLs... z.B. Spiegel hat seine Artikel ja so, das macht es dann schwierig bei http://www.yahoo.de, ein Nebensatz, richtig inline zu codieren, da nicht entscheidbar ist, ob das , zur URL oder zum Fließtext gehört.