urlencode vs. rawurlencode?

Question

Wenn ich eine URL mit einer Variablen erstellen möchte, habe ich zwei Möglichkeiten, die Zeichenfolge zu kodieren. urlencode() y rawurlencode() .

Was genau sind die Unterschiede und was ist vorzuziehen?

Answer 1

1. Was genau sind die Unterschiede und

Der einzige Unterschied besteht in der Art und Weise, wie die Räume behandelt werden:

urlencode - basierend auf der alten Implementierung werden Leerzeichen in + umgewandelt

rawurlencode - basierend auf RFC 1738 übersetzt Leerzeichen in %20

Der Grund für den Unterschied liegt darin, dass + reserviert und in URLs gültig (unverschlüsselt) ist.

2. Was wird bevorzugt?

Ich möchte wirklich einige Gründe für die Wahl eines über das andere zu sehen ... Ich möchte in der Lage sein, einfach einen auszuwählen und ihn für immer mit dem geringsten Aufwand zu verwenden.

Nun gut, ich habe eine einfache Strategie, die ich bei diesen Entscheidungen verfolge und die ich mit Ihnen teilen möchte, in der Hoffnung, dass sie Ihnen helfen kann.

Ich glaube, es war die HTTP/1.1-Spezifikation RFC 2616 in der gefordert wird " Tolerante Anwendungen "

Clients SOLLTEN beim Parsen der Statuszeile tolerant sein und Server tolerant sein, wenn sie die Request-Line parsen.

Bei solchen Fragen besteht die beste Strategie immer darin, so viel wie möglich zu verbrauchen und das zu produzieren, was den Normen entspricht.

Mein Ratschlag lautet daher, die rawurlencode um standardkonforme RFC 1738 kodierte Zeichenketten zu erzeugen und die urldecode abwärtskompatibel sein und alles aufnehmen können, was Sie konsumieren möchten.

Nun könnten Sie mir das einfach glauben, aber beweisen wir es doch einmal...

php > $url = <<<'EOD'
<<< > "Which, % of Alice's tasks saw $s @ earnings?"
<<< > EOD;
php > echo $url, PHP_EOL;
"Which, % of Alice's tasks saw $s @ earnings?"
php > echo urlencode($url), PHP_EOL;
%22Which%2C+%25+of+Alice%27s+tasks+saw+%24s+%40+earnings%3F%22
php > echo rawurlencode($url), PHP_EOL;
%22Which%2C%20%25%20of%20Alice%27s%20tasks%20saw%20%24s%20%40%20earnings%3F%22
php > echo rawurldecode(urlencode($url)), PHP_EOL;
"Which,+%+of+Alice's+tasks+saw+$s+@+earnings?"
php > // oops that's not right???
php > echo urldecode(rawurlencode($url)), PHP_EOL;
"Which, % of Alice's tasks saw $s @ earnings?"
php > // now that's more like it

Es scheint, dass PHP genau das im Sinn hatte, auch wenn ich noch nie jemanden getroffen habe, der eines der beiden Formate ablehnt, kann ich mir keine bessere Strategie vorstellen, die Sie als Ihre Defacto-Strategie übernehmen könnten, oder?

nFreude!

Answer 2

Der Unterschied liegt in den Rückgabewerten, d.h:

urlencode() :

Gibt eine Zeichenkette zurück, in der alle nicht alphanumerische Zeichen außer -_ enthalten. durch ein Prozentzeichen (%) ersetzt wurden Zeichen, gefolgt von zwei Hex-Ziffern und Leerzeichen, die als Pluszeichen (+) kodiert sind. Sie ist auf die gleiche Weise kodiert wie die geposteten Daten eines WWW-Formulars kodiert werden, d.h. auf dieselbe Weise wie in application/x-www-form-urlencoded Medientyp. Dies unterscheidet sich von der " RFC 1738-Kodierung (siehe rawurlencode()) dadurch, dass aus historischen Gründen Leerzeichen als Pluszeichen (+) kodiert werden.

rawurlencode() :

Gibt eine Zeichenkette zurück, in der alle nicht alphanumerische Zeichen außer -_. durch ein Prozentzeichen (%) ersetzt wurden Zeichen, gefolgt von zwei Hex-Ziffern, ersetzt wurden. Diese ist die Kodierung, die in " RFC 1738 beschriebene Kodierung zum Schutz literaler Zeichen vor der Interpretation als spezielle URL Begrenzungszeichen interpretiert werden, und zum Schutz von URLs davor zu schützen, dass sie durch Übertragungs Medien mit Zeichenumwandlungen (wie einige E-Mail-Systeme).

Die beiden sind sich sehr ähnlich, aber letzteres (rawurlencode) ersetzt Leerzeichen durch ein '%' und zwei Hexadezimalziffern, was sich für die Verschlüsselung von Passwörtern oder Ähnlichem eignet, bei denen ein '+' z. B. nicht möglich ist:

echo '<a href="ftp://user:', rawurlencode('foo @+%/'),
     '@ftp.example.com/x.txt">';
//Outputs <a href="ftp://user:foo%20%40%2B%25%2F@ftp.example.com/x.txt">

Answer 3

Leerzeichen kodiert als %20 vs. +

Der wichtigste Grund, den ich für die Verwendung von rawurlencode() in den meisten Fällen, weil urlencode kodiert Textabstände als + (Pluszeichen), wobei rawurlencode kodiert sie als die allgemein sichtbare %20 :

echo urlencode("red shirt");
// red+shirt

echo rawurlencode("red shirt");
// red%20shirt

Ich habe speziell gesehen, dass bestimmte API-Endpunkte, die verschlüsselte Textabfragen akzeptieren, erwarten zu sehen %20 für ein Leerzeichen und schlägt daher fehl, wenn stattdessen ein Pluszeichen verwendet wird. Natürlich ist dies von API-Implementierung zu API-Implementierung unterschiedlich, und Ihre Erfahrungen können variieren.

Answer 4

urlencode : Dies unterscheidet sich von der " RFC 1738-Kodierung (siehe rawurlencode()) dadurch, dass aus historischen Gründen Leerzeichen als Pluszeichen kodiert werden (+) Zeichen kodiert werden.

Answer 5

Ich glaube, urlencode ist für Abfrageparameter, während der rawurlencode für die Pfadsegmente ist. Dies ist hauptsächlich zurückzuführen auf %20 für Pfadsegmente gegenüber + für Abfrageparameter. Siehe diese Antwort, die über die Leerzeichen spricht: Wann ist ein Leerzeichen als Plus (+) oder %20 zu kodieren?

Allerdings %20 funktioniert jetzt auch in Abfrageparametern, weshalb rawurlencode immer sicherer ist. Das Pluszeichen wird jedoch eher dort verwendet, wo es auf die Benutzerfreundlichkeit bei der Bearbeitung und die Lesbarkeit von Abfrageparametern ankommt.

Beachten Sie, dass dies bedeutet rawurldecode dekodiert nicht + in Leerzeichen ( http://au2.php.net/manual/en/function.rawurldecode.php ). Aus diesem Grund wird $_GET immer automatisch durch urldecode was bedeutet, dass + y %20 werden beide in Leerzeichen dekodiert.

Wenn Sie möchten, dass die Kodierung und Dekodierung zwischen Eingängen und Ausgängen konsistent ist, und Sie sich dafür entschieden haben, immer die + und nicht %20 für Abfrageparameter, dann urlencode ist für Abfrageparameter (Schlüssel und Wert) geeignet.

Die Schlussfolgerung ist:

Pfadsegmente - immer rawurlencode/rawurldecode verwenden

Abfrageparameter - für die Dekodierung immer urldecode verwenden (erfolgt automatisch), für die Kodierung ist sowohl rawurlencode als auch urlencode in Ordnung, wählen Sie einfach einen, um konsistent zu sein, insbesondere beim Vergleich von URLs.