Wann sollte ein Leerzeichen als Plus (+) oder %20 kodiert werden?

Question

Manchmal werden die Leerzeichen URL-kodiert, um die + Zeichen, und einige andere Male zu %20 . Worin besteht der Unterschied und warum sollte dies geschehen?

Answer 1

+ bedeutet ein Leerzeichen sólo en application/x-www-form-urlencoded Inhalt, z. B. den Abfrageteil einer URL:

http://www.example.com/path/foo+bar/path?query+name=query+value

In dieser URL lautet der Parametername query name mit einem Leerzeichen und der Wert ist query value mit einem Leerzeichen, aber der Ordnername im Pfad lautet wörtlich foo+bar , pas foo bar .

%20 ist ein gültiger Weg, um ein Leerzeichen in einem dieser Zusammenhänge zu kodieren. Wenn Sie also eine Zeichenkette für die Aufnahme in einen Teil einer URL kodieren müssen, ist es immer sicher, Leerzeichen durch %20 und Pluspunkte mit %2B . Das ist es, was z. B., encodeURIComponent() in JavaScript tut. Leider ist es nicht das, was urlencode in PHP tut ( rawurlencode ist sicherer).

Siehe auch

HTML 4.01-Spezifikation application/x-www-form-urlencoded

Answer 2

Die Antworten hier sind also alle ein wenig unvollständig. Die Verwendung von "%20" zur Kodierung eines Leerzeichens in URLs ist ausdrücklich definiert in RFC 3986 die definiert, wie ein URI aufgebaut ist. In dieser Spezifikation wird die Verwendung eines "+" für die Kodierung von Leerzeichen nicht erwähnt - wenn Sie sich ausschließlich an diese Spezifikation halten, muss ein Leerzeichen als "%20" kodiert werden.

Die Erwähnung der Verwendung von "+" für die Kodierung von Leerzeichen stammt aus den verschiedenen Versionen der HTML-Spezifikation - insbesondere aus dem Abschnitt, der den Inhaltstyp "application/x-www-form-urlencoded" beschreibt. Dieser wird für die Veröffentlichung von Formulardaten verwendet.

Nun, die HTML 2.0 Spezifikation (RFC 1866) in Abschnitt 8.2.2 ausdrücklich gesagt, dass die Abfrage Teil der URL-Zeichenfolge einer GET-Anforderung sollte als "application/x-www-form-urlencoded" kodiert werden. Dies legt theoretisch nahe, dass es legal ist, ein "+" in der URL im Abfrage-String (nach dem "?") zu verwenden.

Aber... ist das wirklich so? Denken Sie daran, dass HTML selbst eine Inhaltsspezifikation ist und dass URLs mit Query-Strings auch für andere Inhalte als HTML verwendet werden können. Während die späteren Versionen der HTML-Spezifikation weiterhin "+" als zulässig in "application/x-www-form-urlencoded"-Inhalten definieren, lassen sie den Teil, der besagt, dass GET-Abfragezeichenfolgen als dieser Typ definiert sind, komplett weg. Nach der HTML 2.0-Spezifikation wird die Kodierung von Abfragezeichenfolgen überhaupt nicht mehr erwähnt.

Bleibt die Frage: Ist sie gültig? Sicherlich gibt es eine Los von Legacy-Code, der '+' in Abfragezeichenfolgen unterstützt, und eine Menge Code, der es ebenfalls erzeugt. Die Chancen stehen also gut, dass Sie bei der Verwendung von '+' keinen Fehler machen. (Und tatsächlich habe ich vor kurzem alle Nachforschungen zu diesem Thema angestellt, weil ich eine große Website entdeckte, die "%20" in einer Abfrage nicht akzeptierte. GET Abfrage als Leerzeichen. Sie haben es tatsächlich nicht geschafft, zu entschlüsseln jede Prozent kodiertes Zeichen. Es kann also auch auf den Dienst ankommen, den Sie nutzen).

Aber wenn man die Spezifikationen rein liest, ohne die Sprache aus der HTML 2.0-Spezifikation, die in spätere Versionen übernommen wurde, werden URLs vollständig von RFC 3986 abgedeckt, was bedeutet, dass Leerzeichen in "%20" umgewandelt werden sollten. Und das sollte definitiv der Fall sein, wenn Sie etwas anderes als ein HTML-Dokument anfordern.

Answer 3

http://www.example.com/some/path/to/resource?param1=value1

Der Teil vor dem Fragezeichen muss die %-Kodierung verwenden (also %20 für Leerzeichen), nach dem Fragezeichen können Sie entweder %20 ou + für einen Raum. Wenn Sie eine aktuelle + nach dem Fragezeichen verwenden %2B .

Answer 4

Aus Kompatibilitätsgründen ist es besser, Leerzeichen immer als "%20" und nicht als "+" zu kodieren.

Es war RFC 1866 (HTML 2.0-Spezifikation), in der festgelegt ist, dass Leerzeichen in "application/x-www-form-urlencoded"-Inhaltspaaren als "+" kodiert werden sollten. (siehe Abschnitt 8.2.1. Unterabsatz 1.). Diese Art der Kodierung von Formulardaten wird auch in späteren HTML-Spezifikationen angegeben, siehe die entsprechenden Absätze über application/x-www-form-urlencoded.

Hier ist ein Beispiel für eine URL-Zeichenkette, bei der RFC 1866 die Kodierung von Leerzeichen als Pluszeichen erlaubt: "http://example.com/over/there?name=foo+bar". Nur nach "?" können Leerzeichen nach RFC 1866 durch Pluszeichen ersetzt werden. In anderen Fällen sollten Leerzeichen als %20 kodiert werden. Da es jedoch schwierig ist, den Kontext zu bestimmen, ist es die beste Praxis, Leerzeichen niemals 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 einzige Situation, in der Sie Leerzeichen als "+" (ein Byte) und nicht als "%20" (drei Bytes) kodieren sollten, ist, wenn Sie genau wissen, wie der Kontext zu interpretieren ist, und wenn die Größe des Abfrage-Strings von entscheidender Bedeutung ist.

Answer 5

Was ist der Unterschied? Siehe die anderen Antworten.

Wann sollten wir die + 代わりに %20 ? Verwenden Sie + wenn Sie aus irgendeinem Grund die URL-Abfragezeichenfolge ( ?..... ) oder Hash-Fragment ( #.... ) besser lesbar. Beispiel: Sie können dies tatsächlich lesen:

https://www.google.se/#q=google+kodiert+nicht+und+verwendet+%2B+anstelle+von+Leerzeichen ( %2B = +)

Aber das Folgende ist viel schwieriger zu lesen (zumindest für mich):

https://www.google.se/#q=google%20doesn%27t%20oops%20:%20%20this%20text%20%2B%20is%20different%20spaces

Ich würde denken + ist es unwahrscheinlich, dass etwas kaputt geht, da Google + (siehe den 1. Link oben) und sie haben wahrscheinlich darüber nachgedacht. Ich werde Folgendes verwenden + mich selbst, nur weil lesbar + Google denkt, dass es OK ist.