Welche Zeichen machen eine URL ungültig?

Question

Welche Zeichen machen eine URL ungültig?

Sind diese URLs gültig?

• example.com/file[/].html
• http://example.com/file[/].html

Answer 1

Im Allgemeinen werden URIs gemäß der Definition von RFC 3986 参照 Abschnitt 2: Schriftzeichen ) kann jedes der folgenden 84 Zeichen enthalten:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=

Beachten Sie, dass diese Liste nicht angibt, wo im URI diese Zeichen vorkommen können.

Jedes andere Zeichen muss mit der Prozent-Kodierung ( %hh ). Für jeden Teil des URI gelten weitere Einschränkungen hinsichtlich der Zeichen, die durch ein prozentual kodiertes Wort dargestellt werden müssen.

Answer 2

Die '[' und ']' in diesem Beispiel sind "unkluge" Zeichen, aber dennoch zulässig. Wenn das "/" in den [] ein Teil des Dateinamens sein soll, ist es ungültig, da "/" reserviert ist und korrekt kodiert werden sollte:

http://example.com/file[/].html

Um die obige Frage zu klären und direkt zu beantworten, gibt es mehrere Zeichenklassen, die bei URLs und URIs Probleme verursachen.

Es gibt einige Zeichen, die nicht erlaubt sind und niemals in einer URL/URI erscheinen sollten, reservierte Zeichen (siehe unten) und andere Zeichen, die in einigen Fällen Probleme verursachen können, aber als "unklug" oder "unsicher" gekennzeichnet sind. Erklärungen, warum die Zeichen eingeschränkt sind, finden Sie in RFC-1738 (URLs) und RFC-2396 (URIs). Beachten Sie die neueren RFC-3986 (Aktualisierung von RFC-1738) definiert, welche Zeichen in einem bestimmten Kontext erlaubt sind, aber die ältere Spezifikation bietet eine einfachere und allgemeinere Beschreibung der Zeichen, die nicht erlaubt sind, mit den folgenden Regeln.

Ausgeschlossene US-ASCII-Zeichen, die in der URI-Syntax nicht zulässig sind:

   control     = <US-ASCII coded characters 00-1F and 7F hexadecimal>
   space       = <US-ASCII coded character 20 hexadecimal>
   delims      = "<" | ">" | "#" | "%" | <">

Das Zeichen "#" ist ausgeschlossen, da es zur Abgrenzung eines URI von einem Fragmentbezeichner verwendet wird. Das Prozentzeichen "%" ist ausgeschlossen, weil es für die Kodierung von escapeten Zeichen verwendet wird. Mit anderen Worten: "#" und "%" sind reservierte Zeichen, die nur in einem bestimmten Kontext verwendet werden dürfen.

Listen mit unklugen Zeichen sind erlaubt, können aber Probleme verursachen:

   unwise      = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"

Charaktere, die reserviert innerhalb einer Abfragekomponente und/oder haben eine besondere Bedeutung innerhalb einer URI/URL:

  reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

Die obige "reservierte" Syntaxklasse bezieht sich auf die Zeichen, die in einem URI zulässig sind, die aber in einer bestimmten Komponente der allgemeinen URI-Syntax nicht zulässig sind. Die Zeichen im "reservierten" Satz sind nicht in allen Zusammenhängen reserviert . Der Hostname kann zum Beispiel einen optionalen Benutzernamen enthalten, so dass er etwa wie folgt lauten könnte ftp://user@hostname/ wobei das Zeichen '@' eine besondere Bedeutung hat.

Hier ist ein Beispiel für eine URL, die ungültige und unkluge Zeichen (z. B. '$', '[', ']') enthält und ordnungsgemäß kodiert werden sollte:

http://mw1.google.com/mw-earth-vectordb/kml-samples/gp/seattle/gigapxl/$[level]/r$[y]_c$[x].jpg

Einige der Zeichenbeschränkungen für URIs und URLs sind programmiersprachenabhängig. Das Zeichen "|" (0x7C) ist in der URI-Spezifikation zwar nur als "unklug" gekennzeichnet, führt aber zu einem URISyntaxException in der Java java.net.URI Konstruktor, so dass eine URL wie http://api.google.com/q?exp=a|b ist nicht erlaubt und muss stattdessen als http://api.google.com/q?exp=a%7Cb bei Verwendung von Java mit einer URI-Objektinstanz.

Answer 3

Die meisten Antworten, die hier gegeben werden, sind unpraktisch, weil sie die reale Verwendung von Adressen wie z. B:

• https://en.wikipedia.org/wiki/Möbius_strip oder
• https://zh.wikipedia.org/wiki/Wikipedia:/en .

Zunächst ein kleiner Exkurs in die Terminologie. Was sont diese Adressen? Sind es gültige URLs?

Historisch gesehen war die Antwort "nein". Laut RFC 3986 aus dem Jahr 2005 sind solche Adressen keine URIs (und daher keine URLs, da URLs sind eine Art von URIs ). Gemäß der Terminologie der IETF-Normen von 2005 sollten wir sie eigentlich IRIs (Internationalized Resource Identifiers) nennen, wie sie in RFC 3987 die technisch gesehen keine URIs sind, aber in URIs umgewandelt werden können, indem einfach alle Nicht-ASCII-Zeichen im IRI prozentual kodiert werden.

Nach modernen Spezifikationen lautet die Antwort "ja". Die WHATWG Lebensstandard klassifiziert einfach alles, was zuvor als "URIs" oder "IRIs" bezeichnet wurde, als "URLs". Dies gleicht die spezifizierte Terminologie an die Art und Weise an, wie normale Menschen, die die Spezifikation nicht gelesen haben, das Wort "URL" verwenden, was eines der Ziele der Spezifikation war. Ziele .

Welche Zeichen sind nach dem WHATWG Living Standard erlaubt?

Welche Zeichen sind nach dieser neueren Bedeutung von "URL" zulässig? In vielen Teilen der URL, z. B. in der Abfragezeichenfolge und im Pfad, dürfen wir beliebige "URL-Einheiten" die sind

URL-Code-Punkte y prozentual kodierte Bytes .

Was sind "URL-Codepunkte"?

El URL-Code-Punkte sind ASCII alphanumerisch, U+0021 (!), U+0024 ($), U+0026 (&), U+0027 ('), U+0028 LINKSPARENTHESIS, U+0029 RECHTSPARENTHESIS, 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 U+00A0 bis einschließlich U+10FFFD, ausgenommen Surrogate und Nichtzeichen.

(Beachten Sie, dass die Liste der "URL-Code-Punkte" nicht enthält % sondern dass % s sind in "URL-Code-Einheiten" erlaubt, wenn sie Teil einer prozentualen Kodierungssequenz sind).

Die einzige Stelle, an der ich erkennen kann, dass die Spezifikation die Verwendung eines Zeichens erlaubt, das no in diesem Satz ist in der Gastgeber wobei die IPv6-Adressen in [ y ] Zeichen. Überall sonst in der URL sind entweder URL-Einheiten erlaubt oder eine noch restriktivere Gruppe von Zeichen.

Welche Zeichen waren nach den alten RFCs erlaubt?

Um der Geschichte willen, und da dies in den Antworten hier nicht ausführlich behandelt wird, wollen wir untersuchen, was nach den älteren Spezifikationen erlaubt war.

Zunächst einmal gibt es zwei Arten von RFC 3986 reservierte Zeichen :

• :/?#[]@ die Teil der in RFC 3986 definierten generischen Syntax für einen URI sind
• *`!$&'()+,;=** die nicht Teil der allgemeinen RFC-Syntax sind, sondern für die Verwendung als syntaktische Komponenten bestimmter URI-Schemata reserviert sind. Zum Beispiel werden Semikolons und Kommas als Teil der Syntax von [Daten URIs](https://en.wikipedia.org/wiki/Data_URI_scheme) y&y=werden als Teil der allgegenwärtigen?foo=bar&qux=baz` Format in Abfragezeichenfolgen (die ist nicht spezifiziert durch RFC 3986).

Jedes der oben genannten reservierten Zeichen kann legal in einem URI ohne Kodierung verwendet werden, entweder um ihren syntaktischen Zweck zu erfüllen oder einfach als literales Zeichen in Daten an einigen Stellen, wo eine solche Verwendung nicht fälschlicherweise als das Zeichen, das seinen syntaktischen Zweck erfüllt, interpretiert werden könnte. (Zum Beispiel, obwohl / in einer URL eine syntaktische Bedeutung hat, können Sie es unverschlüsselt in einem Query-String verwenden, da es nicht in einem Abfrage-String eine Bedeutung haben).

RFC 3986 spezifiziert auch einige uneingeschränkt Zeichen, die immer zur einfachen Darstellung von Daten ohne jegliche Kodierung verwendet werden können:

• abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._~

Schließlich ist die % Zeichen selbst ist für Prozentkodierungen zulässig.

Damit bleiben nur noch die folgenden ASCII-Zeichen übrig, die Verbotene nicht in einer URL auftauchen:

• Die Steuerzeichen (Zeichen 0-1F und 7F), einschließlich Zeilenumbruch, Tabulator und Wagenrücklauf.
• "<>^`{|}

Jedes andere ASCII-Zeichen kann legal in einer URL vorkommen.

RFC 3987 erweitert diesen Satz von nicht reservierten 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 Blockauswahl aus der alten Spezifikation erscheint angesichts des neuesten Unicode bizarr und willkürlich Blockdefinitionen Dies liegt wahrscheinlich daran, dass die Blöcke in den zehn Jahren seit der Erstellung von RFC 3987 ergänzt wurden.

---

Abschließend ist vielleicht noch anzumerken, dass das bloße Wissen, welche Zeichen in einer URL zulässig sind, nicht ausreicht, um zu erkennen, ob eine bestimmte Zeichenfolge eine zulässige URL ist oder nicht, da einige Zeichen nur in bestimmten Teilen der URL zulässig sind. Zum Beispiel sind die reservierten Zeichen [ y ] sind als Teil eines IPv6-Literal-Hosts in einer URL wie http://\[1080::8:800:200C:417A\]/foo legal, aber in jedem anderen Kontext nicht, so dass das Beispiel des Auftraggebers von http://example.com/file[/].html ist illegal.

Answer 4

In Ihrer Zusatzfrage haben Sie gefragt, ob www.example.com/file[/].html ist eine gültige URL.

Diese URL ist nicht gültig, da eine URL eine Art von URI ist und ein gültiger URI ein Schema haben muss wie http: 参照 RFC 3986 ).

Wenn Sie fragen wollten, ob http://www.example.com/file[/].html eine gültige URL ist, lautet die Antwort immer noch nein, weil die Zeichen in eckigen Klammern dort nicht gültig sind.

Die Zeichen in eckigen Klammern sind für URLs in diesem Format reserviert: http://[2001:db8:85a3::8a2e:370:7334]/foo/bar (d. h. ein IPv6-Literal anstelle eines Hostnamens)

Es lohnt sich, RFC 3986 sorgfältig zu lesen, wenn Sie das Problem vollständig verstehen wollen.

Answer 5

Alle gültig Zeichen, die in einem URI verwendet werden können (ein URL ist eine Art von URI ) sind definiert in RFC 3986 .

Alle anderen Zeichen können in einer URL verwendet werden, vorausgesetzt, sie werden zuerst "URL-codiert". Dabei wird das ungültige Zeichen gegen bestimmte "Codes" ausgetauscht (in der Regel in Form des Prozentzeichens (%) gefolgt von einer Hexadezimalzahl).

Dieser Link, HTML-URL-Kodierungsreferenz enthält eine Liste der Kodierungen für ungültige Zeichen.