URL, die das Leerzeichen codiert: + oder% 20?


Antworten:


425

Aus Wikipedia (Hervorhebung und Link hinzugefügt):

Wenn Daten, die in HTML-Formulare eingegeben wurden, gesendet werden, werden die Formularfeldnamen und -werte codiert und in einer HTTP-Anforderungsnachricht mit der Methode GET oder POST oder in der Vergangenheit per E-Mail an den Server gesendet. Die standardmäßig verwendete Codierung basiert auf einer sehr frühen Version der allgemeinen URI- Prozentcodierungsregeln mit einer Reihe von Änderungen, z. B. der Normalisierung von Zeilenumbrüchen und dem Ersetzen von Leerzeichen durch "+" anstelle von "% 20". Der auf diese Weise codierte MIME-Datentyp ist application / x-www-form-urlencoded und wird derzeit (immer noch sehr veraltet) in den HTML- und XForms-Spezifikationen definiert.

Die tatsächliche prozentuale Codierung wird verwendet, %20während Formulardaten in URLs in einer geänderten Form verwendet werden +. Daher werden Sie höchstwahrscheinlich nur +in URLs in der Abfragezeichenfolge nach einem angezeigt ?.


2
+ Codierung wäre also technisch gesehen eine Mehrteil- / Formulardatencodierung, während die prozentuale Codierung application / x-www-form-urlencodiert ist?
BC.

17
@BC: nein - multipart/form-dataverwendet MIME-Codierung; application/x-www-form-urlencodedverwendet +und richtig codierte URIs verwenden %20.
McDowell

8
"Sie sehen also höchstwahrscheinlich nur + in URLs in der Abfragezeichenfolge nach einem?" Ist eine Untertreibung. Sie sollten niemals "+" im Pfadteil der URL sehen, da dies nicht das tut, was Sie erwarten (Leerzeichen).
Adam Gent

34
Also im Grunde: Ziel der GET-Einreichung ist http://www.bing.com/search?q=hello+worldund eine Ressource mit Leerzeichen im Namenhttp://camera.phor.net/cameralife/folders/2012/2012-06%20Pool%20party/
William Entriken

8
Beachten Sie, dass Sie für E-Mail-Links% 20 und nicht + nach dem? Benötigen. Zum Beispiel mailto:support@example.org?subject=I%20need%20help. Wenn Sie dies mit + versucht haben, wird die E-Mail mit + es anstelle von Leerzeichen geöffnet.
Sygmoral

288

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

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

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

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

Wenn wir uns eine komplexere URL ansehen, wie zum Beispiel:

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

Wir können die folgenden Informationen extrahieren:

+-------------------+---------------------+
|        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 jedes Teil unterschiedlich.

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

Im Abfrageteil können Leerzeichen jetzt entweder mit "+" (aus Gründen der Abwärtskompatibilität: Versuchen Sie nicht, im URI-Standard danach zu suchen) oder mit "% 20" codiert werden, während das Zeichen "+" (aufgrund dieser Mehrdeutigkeit) verwendet wird ) muss auf "% 2B" maskiert werden.

Dies bedeutet, dass die Zeichenfolge "blau + hellblau" in den Pfad- und Abfrageteilen unterschiedlich codiert werden muss:

" http://example.com/blue+light%20blue?blue%2Blight+blue ".

Daraus können Sie schließen, dass die Codierung einer vollständig erstellten URL ohne eine syntaktische Kenntnis der URL-Struktur nicht möglich ist.

Das läuft darauf hinaus:

Sie sollten %20vor ?und +nach haben.

Quelle


>> Sie sollten% 20 vor dem haben? und + nach Entschuldigung für die dumme Frage. Ich weiß irgendwie, dass der Hashtag-Parameter nach "?" Fragezeichen-Parameter. Obwohl es irgendwie anders ist, weil die Verwendung von "#" die Seite nicht neu lädt. Aber ich habe versucht,% 20 und + nach dem Hashtag "#" zu verwenden, und es scheint nicht zu funktionieren. Welches muss nach "#" verwendet werden?
Philcyb

@Philcyb Vielleicht möchten Sie diese en.wikipedia.org/wiki/Percent-encoding
Matas Vaitkevicius

Hat der Abfrageteil tatsächlich einen "offiziellen" Standard? Ich dachte im Grunde, dass dieser Teil anwendungsspezifisch ist. 99,99% der Apps verwenden, key1=value1&key1=value2wenn Schlüssel und Werte mit den folgenden Regeln codiert werden. encodeURIComponentAFAIK Der Inhalt des Abfrageteils liegt jedoch zu 100% bei der App. Ansonsten geht es nur zum ersten #gibt es keine offizielle Kodierung.
Gman

Eine doppelte Antwort auf die doppelte Frage! Aber hmm, ok, ich habe beide aufgegeben.
Vladimir Vukanac

3
Diese ASCII-Komponentenkennzeichnung ist episch.
jsejcksn

25

Ich würde empfehlen %20.

Codierst du sie hart?

Dies ist jedoch sprachübergreifend nicht sehr konsistent. Wenn ich mich nicht irre, urlencode()behandelt PHP Leerzeichen so, wie +Python sie urlencode()behandelt %20.

BEARBEITEN:

Es scheint, ich irre mich. Pythons urlencode()(zumindest in 2.7.2) verwendet quote_plus()anstelle von quote()und codiert Leerzeichen daher als "+". Es scheint auch, dass die W3C-Empfehlung das "+" gemäß hier lautet: http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1

Tatsächlich können Sie dieser interessanten Debatte über Pythons eigenen Issue-Tracker folgen, wie Leerzeichen codiert werden sollen: http://bugs.python.org/issue13866 .

EDIT # 2:

Ich verstehe, dass die gebräuchlichste Art, "" zu codieren, "+" ist, aber nur eine Notiz, es mag nur ich sein, aber ich finde das etwas verwirrend:

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

>>> '+=%2B+'

Keine Hardcodierung. Ich versuche aus ästhetischer Sicht zu bestimmen, wie meine URLs mit Leerzeichen aussehen werden.
BC.

Hallo, ich bin auch verwirrt. Wenn der Benutzer das HTML-Formular sendet, wie codiert das Formular den Speicherplatz? mit welchem ​​Charakter? Ist das Ergebnis browserabhängig?
GMsoF

1
Und die URLEncoder.encode()Methode in Java konvertiert es auch in +.
Februar

Und dann stellt sich die Frage, wie die Codierung im Hauptteil einer POST-Anforderung zu behandeln ist: "Inhaltstyp: application / x-www-form-urlencoded", wobei die Parameter in Form von "a = b & c = d" vorliegen. Sie befinden sich jedoch überhaupt nicht in einer URL, sondern nur im Hauptteil des "Dokuments". Sie haben dieses Problem wirklich durcheinander gebracht, und es ist verdammt schwierig, endgültige Antworten zu finden.
Fyngyrz

Perls uri_escape () behandelt sie als% 20
someuser

16

Ein Leerzeichen darf nur im Abfrageteil einer URL vom Typ "application / x-www-form-urlencoded" für "application / x-www-form-urlencoded" mit "+" codiert werden. Meiner Meinung nach ist dies ein MAI, kein MUSS. In den übrigen URLs wird es als% 20 codiert.

Meiner Meinung nach ist es besser, Leerzeichen immer als% 20 und nicht als "+" zu codieren, selbst im Abfrageteil einer URL, da in der HTML-Spezifikation (RFC-1866) angegeben wurde, dass Leerzeichen als "codiert" werden sollen. + "in" application / x-www-form-urlencoded "Schlüssel-Wert-Paare vom Inhaltstyp (siehe Absatz 8.2.1. Unterabsatz 1.)

Diese Art der Codierung von Formulardaten wird auch in späteren HTML-Spezifikationen angegeben. Suchen Sie beispielsweise nach relevanten Absätzen zu application / x-www-form-urlencoded in der HTML 4.01-Spezifikation usw.

Hier ist eine Beispielzeichenfolge in der URL, in der die HTML-Spezifikation das Codieren von Leerzeichen als Pluspunkte zulässt: " http://example.com/over/there?name=foo+bar ". Also, erst nach „?“, Leerzeichen können durch Pluszeichen ersetzt werden . In anderen Fällen sollten Leerzeichen in% 20 codiert werden. Da es jedoch schwierig ist, den Kontext korrekt zu bestimmen, empfiehlt es sich, Leerzeichen niemals als "+" zu codieren.

Ich würde empfehlen, alle Zeichen außer "nicht reserviert" in RFC-3986, S. 2.3, prozentual zu codieren

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

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

Wenn Ihre URL nationale Zeichen enthält, codieren Sie diese zuerst in UTF-8 und anschließend in Prozent.


1
Warum sollte sich jemand für die HTML-Spezifikation interessieren, wenn die angeforderte Ressource kein HTML ist? Ich habe "+" in einigen Web-APIs gesehen, die nicht mit HTML antworten, z. B. wenn Sie ein PDF anfordern. Ich halte es für falsch, dass sie nicht "% 20" verwenden.
Der unglaubliche

@ TheincredibleJan, ich stimme dir zu. Darum geht es in meiner Antwort.
Maxim Masiutin

1
@MaximMasiutin Wenn Ihre Antwort lautet "Dies ist ein MAI, kein MUSS", auf welche Spezifikation beziehen Sie sich? Ich kämpfe darum, eine Spezifikation zu finden, die es als Mai hat. In w3.org/TR/1999/REC-html401-19991224/interact/… befindet sich die Verwendung von '+' (im Abfrageabschnitt) innerhalb eines ' Muss' -Abschnitts der Spezifikation.
JosephH

2
@ JosephH - danke für deinen Hinweis. Es ist meine eindringliche Meinung über MAI. Ich habe den Beitrag bearbeitet. Was ich damit gemeint habe ist, dass die von Ihnen angegebene HTML-Spezifikation "+" definiert, aber im URL-Kontext gelten andere Regeln, die auch das Codieren von Leerzeichen als% 20 ermöglichen.
Maxim Masiutin
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.