Problem mit URL Parsing
-
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.
-
dEUs schrieb:
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.
Nein, müssen sie natürlich nicht. Es sei denn, es handelt sich um RFC-konforme IP-Literale, was aber nicht immer der Fall ist.
Marc++us schrieb:
Tja, dann wäre Jesters URL-Button wohl eine ganz gute Idee, bzw. mittel- bis langfristig [u r l="http://asdf.tld"]asdf[/u r l] oä.
-
Und so etwas wie
[ url<hierDieAdresse> ] Text [ / url ]
ginge nicht?EDIT: Zu spät ... Wobei die Variante mit ="" wohl gängiger wäre ...