URL-Kodierung des Leerzeichens: + oder %20?

Question

Wann wird ein Leerzeichen in einer URL kodiert? + und wann wird sie kodiert zu %20 ?

Answer 1

De Wikipedia (Hervorhebung und Link hinzugefügt):

Wenn Daten, die in HTML-Formulare eingegeben wurden, übermittelt werden, werden die Namen und Werte der Formularfelder kodiert und in einer HTTP-Anforderungsnachricht mit der Methode GET oder POST an den Server gesendet, oder, in der Vergangenheit, per E-Mail. Die standardmäßig verwendete Kodierung basiert auf einer sehr frühen Version der allgemeinen URI-Prozentkodierungsregeln, mit einem Anzahl der Änderungen wie die Normalisierung von Zeilenumbrüchen und das Ersetzen von Leerzeichen durch "+" anstelle von "%20". Der MIME-Typ der auf diese Weise kodierten Daten ist application/x-www-form-urlencoded, und er ist derzeit (noch in einer sehr veralteten Form) in den HTML- und XForms-Spezifikationen definiert.

Also, die real Prozentkodierung verwendet %20 während die Formulardaten in URLs in einer modifizierten Form vorliegen, die die + . Sie werden also höchstwahrscheinlich nur sehen + in URLs im Query-String nach einer ? .

Answer 2

Diese Verwirrung ist darauf zurückzuführen, dass URLs auch heute noch "kaputt" sind.

De einen Blogbeitrag :

Nehmen Sie zum Beispiel "http://www.google.com". Dies ist eine URL. Eine URL steht für Uniform Resource Locator und ist eigentlich ein Verweis auf eine Webseite (in den meisten Fällen). URLs haben seit der ersten Spezifikation im Jahr 1994 eine sehr gut definierte Struktur.

Wir können detaillierte Informationen über die "http://www.google.com" extrahieren. URL:

+---------------+-------------------+
|      Part     |      Data         |
+---------------+-------------------+
|  Scheme       | http              |
|  Host         | www.google.com    |
+---------------+-------------------+

Wenn wir uns eine komplexere URL wie die folgende ansehen:

"https://bob:bobby@www.lunatech.com:8080/file;p=1?q=2#third"

können wir die folgenden Informationen entnehmen:

+-------------------+---------------------+
|        Part       |       Data          |
+-------------------+---------------------+
|  Scheme           | https               |
|  User             | bob                 |
|  Password         | bobby               |
|  Host             | www.lunatech.com    |
|  Port             | 8080                |
|  Path             | /file;p=1           |
|  Path parameter   | p=1                 |
|  Query            | q=2                 |
|  Fragment         | third               |
+-------------------+---------------------+

https://bob:bobby@www.lunatech.com:8080/file;p=1?q=2#third
\___/   \_/ \___/ \______________/ \__/\_______/ \_/ \___/
  |      |    |          |          |      | \_/  |    |
Scheme User Password    Host       Port  Path |   | Fragment
        \_____________________________/       | Query
                       |               Path parameter
                   Authority

Die reservierten Zeichen sind für jeden Teil unterschiedlich.

Bei HTTP-URLs muss ein Leerzeichen in einem Pfadfragmentteil zu "%20" kodiert werden (nicht, absolut nicht "+"), während das "+"-Zeichen im Pfadfragmentteil unkodiert bleiben kann.

Im Abfrageteil können Leerzeichen nun entweder als "+" (aus Gründen der Abwärtskompatibilität: versuchen Sie nicht, im URI-Standard danach zu suchen) oder als "%20" kodiert werden, während das "+"-Zeichen (als Ergebnis dieser Zweideutigkeit) als "%2B" escaped werden muss.

Das bedeutet, dass die Zeichenfolge "blau+hellblau" im Pfad- und im Abfrageteil unterschiedlich kodiert werden muss:

"http://example.com/blue+hell%20blau?blau%2Licht+blau".

Daraus lässt sich ableiten, dass die Kodierung einer vollständig konstruierten URL ohne syntaktische Kenntnis der URL-Struktur unmöglich ist.

Das läuft auf Folgendes hinaus:

Sie sollten Folgendes haben %20 vor dem ? y + nach.

Source :

Answer 3

Ein Leerzeichen darf nur im Abfrageteil einer URL mit dem Inhaltstyp "application/x-www-form-urlencoded" in "+" kodiert werden. Meiner Meinung nach ist dies ein mai , nicht ein doit . In den übrigen URLs wird es als %20 kodiert.

Meiner Meinung nach ist es besser, Leerzeichen immer als %20 und nicht als "+" zu kodieren, selbst im Abfrageteil einer URL, da dies der HTML-Spezifikation entspricht ( RFC 1866 ), in der festgelegt wurde, dass Leerzeichen in Schlüssel-Wert-Paaren des Inhaltstyps "application/x-www-form-urlencoded" als "+" kodiert werden sollten (siehe Abschnitt 8.2.1. Unterabsatz 1.)

Diese Art der Kodierung von Formulardaten ist auch in späteren HTML-Spezifikationen enthalten. Suchen Sie z. B. in der HTML-Spezifikation 4.01 nach entsprechenden Abschnitten über application/x-www-form-urlencoded usw.

Hier ein Beispielstring in einer URL, bei der die HTML-Spezifikation die Kodierung von Leerzeichen als Pluszeichen erlaubt: "http://example.com/over/there?name=foo+bar". So, nur nach "?", Leerzeichen können durch Pluszeichen ersetzt werden . In anderen Fällen sollten Leerzeichen mit %20 kodiert werden. Da es jedoch schwierig ist, den Kontext korrekt zu bestimmen, ist es am besten, Leerzeichen nie als "+" zu kodieren.

Ich würde empfehlen, alle Zeichen mit Ausnahme von "unreserved" in Prozent zu codieren. RFC 3986 , p.2.3

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

Die Implementierung hängt von der von Ihnen gewählten Programmiersprache ab.

Wenn Ihre URL nationale Zeichen enthält, kodieren Sie diese zuerst in UTF-8 und kodieren Sie dann das Ergebnis in Prozent.

Answer 4

Ich würde empfehlen %20 .

Haben Sie sie hart kodiert?

Dies ist jedoch in den verschiedenen Sprachen nicht sehr einheitlich. Wenn ich mich nicht täusche, ist in PHP urlencode() behandelt Räume als + während Pythons urlencode() behandelt sie als %20 .

EDIT :

Ich habe mich wohl geirrt. Python ist urlencode() (zumindest in 2.7.2) verwendet quote_plus() anstelle von quote() und kodiert daher Leerzeichen als "+". Es scheint auch, dass die W3C-Empfehlung das "+" wie hier ist: http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1

Und in der Tat können Sie diese interessante Debatte auf Pythons eigenem Issue Tracker darüber verfolgen, was zur Codierung von Leerzeichen verwendet werden soll: http://bugs.python.org/issue13866 .

EDIT #2:

Ich weiß, dass die gängigste Art der Kodierung von " " ein "+" ist, aber nur eine Anmerkung, vielleicht liegt es an mir, aber ich finde das etwas verwirrend:

import urllib
print(urllib.urlencode({' ' : '+ '})

>>> '+=%2B+'

Answer 5

Um die (etwas widersprüchlichen) Antworten hier zusammenzufassen, denke ich, dass man es auf einen Nenner bringen kann:

| standard      | +   | %20 |
|---------------+-----+-----|
| URL           | no  | yes |
| query string  | yes | yes |
| form params   | yes | no  |
| mailto query  | no  | yes |

Historisch gesehen, denke ich, ist folgendes passiert:

1. Der RFC gibt einen ziemlich klaren Standard für die Form von URLs und deren Kodierung vor. In diesem Zusammenhang ist die Abfrage nur eine "Zeichenkette", es gibt keine Spezifikation, wie Schlüssel/Wertpaare kodiert werden sollten
2. Die HTTP-Leute haben einen Standard für die Kodierung von Schlüssel/Wert-Paaren in Formularparametern herausgegeben, der sich an den URL-Kodierungsstandard anlehnt, mit der Ausnahme, dass Leerzeichen wie folgt kodiert werden sollten + .
3. Die Web-Leute sagten: "Cool, wir haben eine Möglichkeit, Schlüssel/Wert-Paare zu kodieren, die wir in den URL-Abfrage-String einfügen können

Ergebnis: Es gibt zwei verschiedene Möglichkeiten, Leerzeichen in einer URL zu kodieren, je nachdem, um welchen Teil es sich handelt. Aber das verstößt nicht einmal gegen den URL-Standard. Aus der URL-Perspektive ist die "Abfrage" nur eine Blackbox. Wenn Sie dort andere Kodierungen als die prozentuale Kodierung verwenden wollen: nur zu.

Aber wie das E-Mail-Beispiel zeigt, kann es problematisch sein, die form-params-Implementierung für einen URL-Abfrage-String zu verwenden. Letztendlich ist die Verwendung von %20 also sicherer, aber es gibt möglicherweise keine fertige Bibliotheksunterstützung dafür.