urlencode: Leer- und Pluszeichen

[jobo]

Hallo,

Aus einer Tabelle lese ich ein Datum aus. Damit ich es als get-Parameter übergeben kann, nehme ich die "." (Punkte) raus. Bleiben noch Leerzeichen übrig. Mit Url-Encode habe ich dann myPage.php?eintrag=11+Apr+2011.

Wenn ich dann einen Facebook-Like-Button erstelle(n muss), kommt da raus

myPage.php%3Feintrag%3D11%2BApr%2B2011

Ich muss also die Leerzeichen auch rauslöschen, weil die zu "+" encodiert werden, was aber wiederum zu %2B encodiert wird. Ich dachte mal %20 wäre das Leerzeichen, finde aber im PHP-Manual dass "+" historisch das encoding für " " ist. Gibts da irgendwas sinniges zu zu sagen? Eine andere/bessere Funktion zum encodieren?

Gruß

jobo

[jobo]

Hallo,

Hallo,

Aus einer Tabelle lese ich ein Datum aus. Damit ich es als get-Parameter übergeben kann, nehme ich die "." (Punkte) raus.

Das wäre garnicht nötig. Das Problem gibt es nur beim name-Attribut von input-Feldern:

http://forum.de.selfhtml.org/archiv/2009/2/t183684/#m1216746

Bleiben noch Leerzeichen übrig, die man dann wohl einfach mit urlencode encodieren müsste, halt nicht doppelt. Warum nimmt man dann nicht gleich die %20.

Gruß

jobo

[ChrisB]

Hi,

Bleiben noch Leerzeichen übrig, die man dann wohl einfach mit urlencode encodieren müsste, halt nicht doppelt. Warum nimmt man dann nicht gleich die %20.

Warum nimmst *du* dann nicht gleich rawurlencode?

MfG ChrisB

[dedlfix]

Hi!

Aus einer Tabelle lese ich ein Datum aus. Damit ich es als get-Parameter übergeben kann, nehme ich die "." (Punkte) raus. Bleiben noch Leerzeichen übrig. Mit Url-Encode habe ich dann myPage.php?eintrag=11+Apr+2011.

Genauso ist es für den Querystring definiert. Leerzeichen sind als + zu notieren, der "Rest" als %xx.

Wenn ich dann einen Facebook-Like-Button erstelle(n muss), kommt da raus
myPage.php%3Feintrag%3D11%2BApr%2B2011

Nur dann, wenn du doppelt kodierst. Dann ist auch das Querystring-Fragezeichen als %3F notiert. Den Fall hat man, wenn man eine vollständige URL als Parameter in eine andere URL schreiben will. Das ist im Prinzip nicht weiter tragisch, sondern sogar richtig. Das % in den durch die erste Kodierung zu %xx gewordenen Zeichen muss (wie dein +) noch einmal kodiert werden, was zu %25xx führt. Das Ganze wird dann von zwei Verarbeitern aufgelöst, Der eine dekodiert die Gesamt-URL und übergibt die darin enthaltene URL an den zweiten Prozess, der die zweite Kodierung auflöst.

Ich muss also die Leerzeichen auch rauslöschen, weil die zu "+" encodiert werden, was aber wiederum zu %2B encodiert wird. Ich dachte mal %20 wäre das Leerzeichen, finde aber im PHP-Manual dass "+" historisch das encoding für " " ist. Gibts da irgendwas sinniges zu zu sagen? Eine andere/bessere Funktion zum encodieren?

Ich hab dazu was im Kontextwechsel-Artikel geschrieben. Beachte auch die Fußnote [2] hinter dem "eigentlich".

Lo!

[Der Martin]

Hallo,

Aus einer Tabelle lese ich ein Datum aus. Damit ich es als get-Parameter übergeben kann, nehme ich die "." (Punkte) raus. Bleiben noch Leerzeichen übrig. Mit Url-Encode habe ich dann myPage.php?eintrag=11+Apr+2011.
Genauso ist es für den Querystring definiert. Leerzeichen sind als + zu notieren, der "Rest" als %xx.

ja, wobei Leerzeichen oft auch als %20 codiert werden, ohne die Sonderregelung mit dem Pluszeichen in Anspruch zu nehmen. Die Serverseite muss das Percent-Encoding ohnehin korrekt decodieren können, da fällt die systematische Behandlung von %20 als Leerzeichen automatisch mit ab.

Ich hab dazu was im Kontextwechsel-Artikel geschrieben. Beachte auch die Fußnote [2] hinter dem "eigentlich".

Ah, ich wusste nicht, dass das tatsächlich unterschiedlich *geregelt* ist. Gibt's ungeachtet der Praxisbetrachtung, dass es in der Regel egal ist, einen Grund für die Festlegung, dass Leerzeichen im Querystring als Pluszeichen und nicht als %20 angegeben werden sollen?

So long,
 Martin

[ChrisB]

Hi,

Ich hab dazu was im Kontextwechsel-Artikel geschrieben. Beachte auch die Fußnote [2] hinter dem "eigentlich".

„Es gibt zwei Stellen in einer URL, die eigentlich unterschiedlich betrachtet werden müssen. Für den Querystring ist urlencode() vorgesehen und für Daten, die im Pfadteil eingefügt werden, gibt es rawurlencode(). Der Unterschied zwischen beiden Funktionen ist lediglich die Behandlung des Leerzeichens. rawurlencode() wandelt es zu %20, urlencode() hingegen in ein + (Plus).“

In RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax kann ich von dieser Unterscheidung, von der du in Bezug auf Path- und Query-Part von URLs sprichst, nichts (mehr) erkennen.

Abschnitt “3.4. Query” beschreibt den Aufbau des Query-Strings als

query       = *( pchar / "/" / "?" )

pchar wieder ist definiert als

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

und pct-encoded als

pct-encoded   = "%" HEXDIG HEXDIG

Abschnitt “2.1. Percent-Encoding” führt explizit dieses Beispiel an,

For example, "%20" is the percent-encoding for the binary octet "00100000" (ABNF: %x20), which in US-ASCII corresponds to the space character (SP).

Eine Unterscheidung zwischen der Kodierung eines Leerzeichens im Path- und im Query-Bestandteil eines URIs kann ich in RFC 3986 nicht entdecken.

Ich würde also sagen, dein „eigentlich“ im Artikel gilt eigentlich gar nicht mehr.
Wie das PHP-Manual zu urlencode auch schon sagt, sprechen höchstens noch “historical reasons” dafür, ein Leerzeichen als + zu kodieren. Dass es in freier Wildbahn noch eine Notwendigkeit dafür geben könnte, kann ich mir kaum vorstellen.

MfG ChrisB

[jobo]

Hallo,

wieso gibt

var_dump(rawurldecode(rawurlencode(" ")));
var_dump(urldecode(rawurlencode(" ")));

das selbe (string(1)" ") aus?

Abgesehen davon also als Fazit: _nur_ rawurlencode nehmen bzw. %20 für Leerzeichen.

Gruß

jobo

[ChrisB]

Hi,

wieso gibt

var_dump(rawurldecode(rawurlencode(" ")));
var_dump(urldecode(rawurlencode(" ")));

das selbe (string(1)" ") aus?

Weil's dem definierten Funktionsumfang entspricht ...?

Über ersteres müssen wir nicht diskutieren (Funktion und „Umkehrfunktion“ angewandt, da ist sowieso nichts anderes zu erwarten), und zu zweiteren siehe urldecode: “Decodes any %## encoding in the given string. Plus symbols ('+') are decoded to a space character.” - Betonung beim Lesen bitte auf “any” legen.

MfG ChrisB

[jobo]

Hallo,

Über ersteres müssen wir nicht diskutieren (Funktion und „Umkehrfunktion“ angewandt, da ist sowieso nichts anderes zu erwarten), und zu zweiteren siehe urldecode: “Decodes any %## encoding in the given string. Plus symbols ('+') are decoded to a space character.” - Betonung beim Lesen bitte auf “any” legen.

Das mit der Betonung erschließt sich mir nicht ...;

Gruß

jobo

[ChrisB]

Hi,

urldecode: “Decodes any %## encoding in the given string. Plus symbols ('+') are decoded to a space character.” - Betonung beim Lesen bitte auf “any” legen.

Das mit der Betonung erschließt sich mir nicht ...;

urldecode dekodiert *alles*, was eine gültige Kodierung in der Form %## darstellt - also auch ein Leerzeichen, welches von rawurlencode als %20 kodiert wurde.

Womit die Frage, wieso bei beiden Tests " " herauskommt, doch wohl geklärt sein dürfte.

MfG ChrisB

[dedlfix]

Hi!

Über ersteres müssen wir nicht diskutieren (Funktion und „Umkehrfunktion“ angewandt, da ist sowieso nichts anderes zu erwarten), und zu zweiteren siehe urldecode: “Decodes any %## encoding in the given string. Plus symbols ('+') are decoded to a space character.” - Betonung beim Lesen bitte auf “any” legen.
Das mit der Betonung erschließt sich mir nicht ...;

"any" schließt auch die Dekodierung von %20 ein. Auch dann, wenn das Gegenstück zu urldecode() aus dem Leerzeichen ein + macht.

Das schließt übrigens auch alle anderen %##-Sequenzen ein, selbst wenn urlencode() das entsprechende Zeichen gar nicht behandelt. urldecode() ist also nicht exakt das Gegenstück zu urlencode() - und umgekehrt.

Lo!

[dedlfix]

Hi!

Ich hab dazu was im Kontextwechsel-Artikel geschrieben. Beachte auch die Fußnote [2] hinter dem "eigentlich".

„Es gibt zwei Stellen in einer URL, die eigentlich unterschiedlich betrachtet werden müssen. Für den Querystring ist urlencode() vorgesehen und für Daten, die im Pfadteil eingefügt werden, gibt es rawurlencode(). Der Unterschied zwischen beiden Funktionen ist lediglich die Behandlung des Leerzeichens. rawurlencode() wandelt es zu %20, urlencode() hingegen in ein + (Plus).“

In RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax kann ich von dieser Unterscheidung, von der du in Bezug auf Path- und Query-Part von URLs sprichst, nichts (mehr) erkennen.

Ich gebe zu, dass ich dazu nicht die RFCs herangezogen hatte, sondern nur die Beschreibungen der Funktionen urlencode() und rawurlencode() im PHP-Handbuch. Auch weiß ich nicht mehr, was damals genau dazu geschrieben stand. Es kann gut sein, dass das damals noch nicht so deutlich auf die RFC3986 bezugnehmend beschrieben stand.

Eine Unterscheidung zwischen der Kodierung eines Leerzeichens im Path- und im Query-Bestandteil eines URIs kann ich in RFC 3986 nicht entdecken.

Sie war (und ist derzeit immer noch) in den Beispielen im PHP-Handbuch zu sehen. rawurlencode() behandelt nur Pfad-Teile (und das Passwort im FTP-Beispiel), urlencode() nur Werte für den Querystring.

Ich würde also sagen, dein „eigentlich“ im Artikel gilt eigentlich gar nicht mehr.
Wie das PHP-Manual zu urlencode auch schon sagt, sprechen höchstens noch “historical reasons” dafür, ein Leerzeichen als + zu kodieren. Dass es in freier Wildbahn noch eine Notwendigkeit dafür geben könnte, kann ich mir kaum vorstellen.

Eine Notwendigkeit sehe ich auch nicht. An der Stelle hab ich auch schon rumgefeilt. Die Fassung der Erstveröffentlichung stellt das noch deutlicher als Fehler dar, wenn man im Query-Teil nicht das + verwendet. Das muss also nochmal umformuliert werden. Wobei man die Sonderstellung des Plus aus historischen Gründen nicht untern Tisch fallen lassen darf, sonst wundert sich am Ende noch jemand, wenn sein ernst gemeintes + von einer Dekodierfunktion in Luft (ähm Leerzeichen) aufgelöst wird.

Lo!