Die meisten der hier vorhandenen Antworten sind unpraktisch, da sie die reale Verwendung von Adressen wie:
Zunächst ein Exkurs in die Terminologie. Was sind diese Adressen? Sind sie gültige URLs?
Historisch gesehen war die Antwort "nein". Laut RFC 3986 sind solche Adressen ab 2005 keine URIs (und daher keine URLs, da URLs eine Art von URIs sind ). Gemäß der Terminologie der IETF-Standards von 2005 sollten wir sie ordnungsgemäß als IRIs (Internationalized Resource Identifiers) gemäß RFC 3987 bezeichnen , die technisch gesehen keine URIs sind, sondern einfach durch prozentuale Codierung aller Nicht-ASCII-Zeichen in der IRI in URIs konvertiert werden können .
Laut moderner Spezifikation lautet die Antwort "Ja". Der WHATWG Living Standard klassifiziert einfach alles, was zuvor als "URIs" oder "IRIs" bezeichnet wurde, als "URLs". Dadurch wird die festgelegte Terminologie darauf abgestimmt, wie normale Personen, die die Spezifikation nicht gelesen haben, das Wort "URL" verwenden, was eines der Ziele der Spezifikation war .
Welche Zeichen sind nach dem WHATWG-Lebensstandard zulässig?
Welche Zeichen sind gemäß dieser neueren Bedeutung von "URL" zulässig? In vielen Teilen der URL, wie z. B. der Abfragezeichenfolge und dem Pfad, dürfen beliebige "URL-Einheiten" verwendet werden
URL-Codepunkte und prozentual codierte Bytes .
Was sind "URL-Codepunkte"?
Die URL-Codepunkte sind alphanumerisch ASCII, U + 0021 (!), U + 0024 ($), U + 0026 (&), U + 0027 ('), U + 0028 LINKE PARENTHESE, U + 0029 RECHTE PARENTHESE, U + 002A (*), U + 002B (+), U + 002C (,), U + 002D (-), U + 002E (.), U + 002F (/), U + 003A (:), U + 003B (;), U + 003D (=), U + 003F (?), U + 0040 (@), U + 005F (_), U + 007E (~) und Codepunkte im Bereich von U + 00A0 bis U. + 10FFFD, einschließlich, ohne Ersatz und Nicht-Zeichen.
(Beachten Sie, dass die Liste der "URL-Codepunkte" nicht enthalten ist %, diese jedoch %in "URL-Codeeinheiten" zulässig sind , wenn sie Teil einer Prozentcodierungssequenz sind.)
Der einzige Ort, an dem ich feststellen kann, wo die Spezifikation die Verwendung von Zeichen erlaubt, die nicht in diesem Satz enthalten sind, ist der Host , in dem IPv6-Adressen [und ]Zeichen enthalten sind. Überall sonst in der URL sind entweder URL-Einheiten oder noch restriktivere Zeichensätze zulässig.
Welche Zeichen waren unter den alten RFCs erlaubt?
Aus Gründen der Geschichte und da dies an anderer Stelle in den Antworten hier nicht vollständig untersucht wird, sollten wir untersuchen, ob dies unter den älteren Spezifikationen zulässig war.
Zunächst haben wir zwei Arten von reservierten RFC 3986- Zeichen :
:/?#[]@, die Teil der generischen Syntax für einen in RFC 3986 definierten URI sind!$&'()*+,;=, die nicht Teil der generischen Syntax des RFC sind, aber für die Verwendung als syntaktische Komponenten bestimmter URI-Schemata reserviert sind. Zum Beispiel sind Semikolons und Kommas als Teil der Syntax der verwendeten Daten URIs , und &und =als Teil des allgegenwärtigen verwendeten ?foo=bar&qux=bazFormat in Abfragezeichenfolgen (die nicht durch RFC 3986 spezifiziert).
Jedes der oben genannten reservierten Zeichen kann legal in einer URI ohne Codierung verwendet werden, entweder um ihren syntaktischen Zweck zu erfüllen, oder nur als Literalzeichen in Daten an einigen Stellen, an denen eine solche Verwendung nicht als das Zeichen interpretiert werden kann, das seinem syntaktischen Zweck dient. (Obwohl /eine URL eine syntaktische Bedeutung hat, können Sie sie in einer Abfragezeichenfolge nicht codiert verwenden, da sie in einer Abfragezeichenfolge keine Bedeutung hat.)
RFC 3986 spezifiziert auch einige nicht reservierte Zeichen, die immer einfach verwendet werden können, um Daten ohne Codierung darzustellen:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._~
Schließlich ist das %Zeichen selbst für Prozentcodierungen zulässig.
Damit bleiben nur die folgenden ASCII-Zeichen übrig, deren Anzeige in einer URL verboten ist :
- Die Steuerzeichen (Zeichen 0-1F und 7F), einschließlich Zeilenumbruch, Tabulator und Wagenrücklauf.
"<>\^`{|}
Jedes andere Zeichen aus ASCII kann legal in einer URL enthalten sein.
Dann erweitert RFC 3987 diesen Satz nicht reservierter Zeichen um die folgenden Unicode-Zeichenbereiche:
%xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD
Diese Block - Auswahl aus dem alten spec scheint bizarr und willkürlich die neuesten Unicode gegebenen Blockdefinitionen ; Dies liegt wahrscheinlich daran, dass die Blöcke im Jahrzehnt seit dem Schreiben von RFC 3987 hinzugefügt wurden.
Schließlich ist es vielleicht erwähnenswert, dass es nicht ausreicht, nur zu wissen, welche Zeichen legal in einer URL erscheinen können, um zu erkennen, ob eine bestimmte Zeichenfolge eine legale URL ist oder nicht, da einige Zeichen nur in bestimmten Teilen der URL legal sind. Beispielsweise sind die reservierten Zeichen [und ]als Teil eines IPv6-Literal-Hosts in einer URL wie http: // [1080 :: 8: 800: 200C: 417A] / foo zulässig, in keinem anderen Kontext jedoch zulässig Das Beispiel von OP http://example.com/file[/].htmlist illegal.