urlencode vs rawurlencode?

Dowód jest w kodzie źródłowym PHP.

Przeprowadzę Cię przez szybki proces, jak dowiedzieć się tego typu rzeczy na własną rękę w przyszłości, kiedy tylko zechcesz. Bear with me, there ' ll be a lot of C source code you can skim over (I explain it). jeśli chcesz odświeżyć trochę C, dobrym miejscem na początek jest nasza so wiki .

Pobierz źródło (lub użyj http://lxr.php.net / aby przeglądać go online), grep wszystkie pliki dla nazwy funkcji, znajdziesz coś takiego:

PHP 5.3.6 (najnowsze w momencie pisania) opisuje dwie funkcje w ich natywnym kodzie C w pliku url.c .

RawUrlEncode()

PHP_FUNCTION(rawurlencode)
{
    char *in_str, *out_str;
    int in_str_len, out_str_len;

    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &in_str,
                              &in_str_len) == FAILURE) {
        return;
    }

    out_str = php_raw_url_encode(in_str, in_str_len, &out_str_len);
    RETURN_STRINGL(out_str, out_str_len, 0);
}

UrlEncode()

PHP_FUNCTION(urlencode)
{
    char *in_str, *out_str;
    int in_str_len, out_str_len;

    if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &in_str,
                              &in_str_len) == FAILURE) {
        return;
    }

    out_str = php_url_encode(in_str, in_str_len, &out_str_len);
    RETURN_STRINGL(out_str, out_str_len, 0);
}

W istocie obie wywołują dwie różne funkcje wewnętrzne odpowiednio: php_raw_url_encode i php_url_encode

Więc poszukaj tych funkcje!

Spójrzmy na php_raw_url_encode

PHPAPI char *php_raw_url_encode(char const *s, int len, int *new_length)
{
    register int x, y;
    unsigned char *str;

    str = (unsigned char *) safe_emalloc(3, len, 1);
    for (x = 0, y = 0; len--; x++, y++) {
        str[y] = (unsigned char) s[x];
#ifndef CHARSET_EBCDIC
        if ((str[y] < '0' && str[y] != '-' && str[y] != '.') ||
            (str[y] < 'A' && str[y] > '9') ||
            (str[y] > 'Z' && str[y] < 'a' && str[y] != '_') ||
            (str[y] > 'z' && str[y] != '~')) {
            str[y++] = '%';
            str[y++] = hexchars[(unsigned char) s[x] >> 4];
            str[y] = hexchars[(unsigned char) s[x] & 15];
#else /*CHARSET_EBCDIC*/
        if (!isalnum(str[y]) && strchr("_-.~", str[y]) != NULL) {
            str[y++] = '%';
            str[y++] = hexchars[os_toascii[(unsigned char) s[x]] >> 4];
            str[y] = hexchars[os_toascii[(unsigned char) s[x]] & 15];
#endif /*CHARSET_EBCDIC*/
        }
    }
    str[y] = '\0';
    if (new_length) {
        *new_length = y;
    }
    return ((char *) str);
}

I oczywiście php_url_encode:

PHPAPI char *php_url_encode(char const *s, int len, int *new_length)
{
    register unsigned char c;
    unsigned char *to, *start;
    unsigned char const *from, *end;

    from = (unsigned char *)s;
    end = (unsigned char *)s + len;
    start = to = (unsigned char *) safe_emalloc(3, len, 1);

    while (from < end) {
        c = *from++;

        if (c == ' ') {
            *to++ = '+';
#ifndef CHARSET_EBCDIC
        } else if ((c < '0' && c != '-' && c != '.') ||
                   (c < 'A' && c > '9') ||
                   (c > 'Z' && c < 'a' && c != '_') ||
                   (c > 'z')) {
            to[0] = '%';
            to[1] = hexchars[c >> 4];
            to[2] = hexchars[c & 15];
            to += 3;
#else /*CHARSET_EBCDIC*/
        } else if (!isalnum(c) && strchr("_-.", c) == NULL) {
            /* Allow only alphanumeric chars and '_', '-', '.'; escape the rest */
            to[0] = '%';
            to[1] = hexchars[os_toascii[c] >> 4];
            to[2] = hexchars[os_toascii[c] & 15];
            to += 3;
#endif /*CHARSET_EBCDIC*/
        } else {
            *to++ = c;
        }
    }
    *to = 0;
    if (new_length) {
        *new_length = to - start;
    }
    return (char *) start;
}

Zanim przejdę do przodu, EBCDIC to kolejny zestaw znaków , podobny do ASCII, ale totalny konkurent. PHP próbuje poradzić sobie z obydwoma. Ale zasadniczo oznacza to, że bajt EBCDIC 0x4c nie jest L W ASCII, to w rzeczywistości <. Jestem pewien, że widzisz tu zamieszanie.

Obie te funkcje zarządzają EBCDIC, jeśli serwer WWW zdefiniował to.

Ponadto oba używają tablicy znaków (think string type) hexchars look-up, aby uzyskać pewne wartości, tablica jest opisana w następujący sposób:

/* rfc1738:

   ...The characters ";",
   "/", "?", ":", "@", "=" and "&" are the characters which may be
   reserved for special meaning within a scheme...

   ...Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
   reserved characters used for their reserved purposes may be used
   unencoded within a URL...

   For added safety, we only leave -_. unencoded.
 */

static unsigned char hexchars[] = "0123456789ABCDEF";

Poza tym, funkcje są naprawdę różne, i zamierzam wyjaśnić je w ASCII i EBCDIC.

Różnice w ASCII:

URLENCODE:

• oblicza długość początkową / końcową łańcucha wejściowego, przydziela pamięć
• przechodzi przez pętlę while, inkrementuje aż dojdziemy the end of the string
• chwyta obecny znak
• jeśli znak jest równy znakowi ASCII 0x20 (czyli" spacja"), Dodaj znak + do wyjściowego łańcucha.
• jeśli nie jest spacją, a także nie jest alfanumeryczna (isalnum(c)), a także nie jest i _, -, lub . znak, następnie wypisujemy znak % na pozycję tablicy 0, wykonujemy wyszukiwanie tablicy hexchars w celu wyszukania tablicy os_toascii array( tablicy z Apache, która tłumaczy znak na kod hex) dla klucz c (obecny znak), następnie przesuwamy w prawo o 4, przypisujemy tę wartość do znaku 1, A do pozycji 2 przypisujemy to samo wyszukiwanie, z wyjątkiem preformowania logicznego i sprawdzenia, czy wartość jest 15( 0xF), i zwracamy 1 w takim przypadku, lub 0 w przeciwnym razie. Na koniec, skończysz z czymś zakodowanym.
• jeśli kończy się, że nie jest spacją, jest alfanumeryczny lub jeden z znaków _-., wyświetla dokładnie to, co jest.

RAWURLENCODE:

• alokuje pamięć Dla ciągu
• iteruje na podstawie długości podanej w wywołaniu funkcji (nie jest obliczana w funkcji jak w URLENCODE).

Uwaga: wielu programistów prawdopodobnie nigdy nie widziało iteracji pętli for w ten sposób, jest to nieco hakerskie, a nie Standardowa konwencja używana w większości pętli for, zwróć uwagę, przypisuje x i y, sprawdza wyjście na len osiągając 0, a przyrost zarówno x, jak i y. Wiem, że to nie jest to, czego byś się spodziewał, ale to prawidłowy kod.

• przypisuje obecny znak do pasującej pozycji znaku w str.
• sprawdza, czy obecny znak jest alfanumeryczny, czy jeden ze znaków _-., a jeśli tak nie jest, robimy prawie to samo przypisanie, jak w URLENCODE, gdzie preform lookups, jednak zwiększamy inaczej, używając y++ zamiast to[1], dzieje się tak dlatego, że ciągi są budowane w różnych sposoby, ale i tak osiągnąć ten sam cel na końcu.
• kiedy pętla jest skończona i jej długość zniknie, kończy łańcuch, przypisując bajt \0.
• zwraca zakodowany ciąg znaków.

Różnice:

• UrlEncode sprawdza spację, przypisuje znak+, RawURLEncode nie.
W tym przypadku nie jest możliwe przypisanie bajtu \0 do ciągu znaków, ale do RawUrlEncode (może to być punkt sporny)
• różnie się powtarzają, jeden może być podatny na przepełnienie zniekształconymi strunami, ja tylko sugeruję, że to i ja nie prowadziliśmy śledztwa.

Zasadniczo iteracji inaczej, jeden przypisuje znak + w przypadku ASCII 20.

Różnice w EBCDIC:

URLENCODE:

• ta sama konfiguracja iteracji jak w ASCII
• nadal tłumacząc znak "spacja" na znak + . Uwaga-- myślę, że to musi być skompilowane w EBCDIC lub będziesz skończyłeś z robakiem? Czy ktoś może to edytować i potwierdzić?
• sprawdza, czy obecny znak jest znakiem przed 0, z wyjątkiem . lub -, lub mniej niż A ale więcej niż char 9, lub większe niż Z i mniejsze niż a, ale nie _. lub większe niż z (tak, EBCDIC jest trochę Pokręcony do pracy z). Jeśli pasuje do któregokolwiek z nich, wykonaj podobne wyszukiwanie jak w wersji ASCII (po prostu nie wymaga a lookup in os_toascii).

RAWURLENCODE:

• ta sama konfiguracja iteracji jak w ASCII
• to samo sprawdzenie opisane w wersji EBCDIC kodowania URL, z tym wyjątkiem, że jeśli jest większy niż z, wyklucza ~ Z kodowania URL.
• to samo zadanie co ASCII RawUrlEncode
• nadal dołącza bajt \0 do łańcucha przed powrotem.

Wielkie Podsumowanie

• oba używają tego samego hexchars lookup table
• URIEncode nie kończy łańcucha z \0, raw tak.
• jeśli pracujesz w EBCDIC, sugerowałbym użycie RawUrlEncode, ponieważ zarządza ~, którego UrlEncode nie ma (jest to zgłoszony problem ). Warto zauważyć, że ASCII i EBCDIC 0x20 są spacjami.
• iterują inaczej, można być szybszym, można być podatnym na exploity oparte na pamięci lub łańcuchach.
• URIEncode tworzy spację na +, RawUrlEncode tworzy spację do %20 poprzez szukanie tablicy.

Nie dotykałem C od lat i nie patrzyłem na EBCDIC od bardzo dawna. Jeśli się mylę, daj mi znać.

Sugerowane wdrożenia

Bazując na tym wszystkim, rawurlencode jest najlepszym rozwiązaniem przez większość czasu. Jak widzisz w odpowiedzi Jonathana Finglanda, trzymaj się jej w większości przypadków. Zajmuje się nowoczesnym schematem Dla komponentów URI, gdzie jak urlencode robi rzeczy w stary sposób, gdzie + oznaczało " przestrzeń."

Jeśli próbujesz przekonwertować stary format na nowy, upewnij się, że Twój kod nie wygłupia się i nie zamienia czegoś, co jest zdekodowanym znakiem + w spację przez przypadkowe podwójne kodowanie lub podobne scenariusze "oops" wokół tej spacji/20%/+.

Jeśli pracujesz na starszym systemie ze Starszym oprogramowaniem, które nie preferuje nowego formatu, trzymaj się urlencode, jednak wierzę, że %20 będzie kompatybilny wstecz, tak jak pod starym standard %20 zadziałał, po prostu nie był preferowany. Spróbuj, jeśli chcesz się bawić, daj nam znać, jak ci się udało.

Zasadniczo powinieneś trzymać się raw, chyba że Twój system EBCDIC naprawdę cię nienawidzi. Większość programistów nigdy nie natknie się na EBCDIC na żadnym systemie wyprodukowanym po roku 2000, może nawet 1990 (to pchanie, ale nadal prawdopodobnie moim zdaniem).

echo rawurlencode('http://www.google.com/index.html?id=asd asd');

http%3A%2F%2Fwww.google.com%2Findex.html%3Fid%3Dasd%20asd

While

echo urlencode('http://www.google.com/index.html?id=asd asd');

http%3A%2F%2Fwww.google.com%2Findex.html%3Fid%3Dasd+asd

Różnica jest asd%20asd vs asd+asd

Urlencode różni się od RFC 1738 spacjami kodującymi jako + zamiast %20

Jednym z praktycznych powodów, aby wybrać jeden nad drugim, jest użycie wyniku w innym środowisku, na przykład JavaScript.

W PHP urlencode('test 1') zwraca 'test+1' podczas gdy rawurlencode('test 1') zwraca 'test%201' jako wynik.

Ale jeśli chcesz "dekodować" to w JavaScript za pomocą decodeURI() Funkcja decodeURI("test+1") da ci "test+1" podczas gdy decodeURI("test%201") da ci "test 1" jako wynik.

Innymi słowy spacja (" ") zakodowana przez urlencode do plus ( " + " ) w PHP nie będzie poprawnie dekodowane przez decodeURI w JavaScript.

W takich przypadkach należy użyć funkcji PHP rawurlencode.

Uważam, że spacje muszą być zakodowane jako:

• %20 w przypadku użycia wewnątrz komponentu ścieżki URL
• + w przypadku użycia wewnątrz komponentu ciągu zapytania URL lub danych formularza (patrz 17.13.4 typy treści formularza)

Poniższy przykład pokazuje prawidłowe użycie rawurlencode oraz urlencode:

echo "http://example.com"
    . "/category/" . rawurlencode("latest songs")
    . "/search?q=" . urlencode("lady gaga");

Wyjście:

http://example.com/category/latest%20songs/search?q=lady+gaga

Co się stanie, jeśli zakodujesz ścieżkę i odpytywasz komponenty ciągu znaków na odwrót? Dla następujących przykład:

http://example.com/category/latest+songs/search?q=lady%20gaga

• serwer WWW będzie szukał katalogu latest+songs zamiast latest songs
• parametr ciągu zapytania q będzie zawierał lady gaga

Różnica jest w wartościach zwrotnych, tzn.:

Urlencode():

Zwraca łańcuch, w którym wszystkie znaki niealfanumeryczne z wyjątkiem -_. zostały zastąpione procentami (%) znak, po którym następują dwie cyfry szesnastkowe i spacje zakodowane jako znaki plus ( + ). Informatyka jest zakodowany w ten sam sposób, w jaki zamieszczone dane z formularza WWW są zakodowane, czyli tak samo jak w application / x-www-form-urlencoded typ nośnika. Różni się to od " Kodowanie RFC 1738 (zobacz rawurlencode()) w tym ze względów historycznych, przestrzenie są kodowane jako znaki plus ( + ).

Rawurlencode():

Zwraca łańcuch, w którym wszystkie znaki niealfanumeryczne z wyjątkiem -_. zostały zastąpione procentami (%) znak, po którym następują dwie cyfry szesnastkowe. To jest kodowaniem opisanym w " RFC 1738 za ochronę znaków literalnych od interpretacji jako specjalny adres URL ograniczniki, oraz do ochrony adresów URL od bycia zniekształconym przez transmisję media z konwersją znaków (jak niektóre systemy poczty elektronicznej).

Te dwa są bardzo podobne, ale ten drugi (rawurlencode) zastąpi spacje znakiem " % "i dwoma cyframi szesnastkowymi, co nadaje się do kodowania haseł lub takich, gdzie" + " nie jest np.:

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

1. Jakie dokładnie są różnice i

Jedyna różnica polega na sposobie traktowania przestrzeni:

Urlencode-w oparciu o starsze implementacje konwertuje spacje na +

Rawurlencode-oparty na RFC 1738 tłumaczy spacje na %20

Powodem różnicy jest to, że + jest zarezerwowane i ważne (niekodowane) w adresach URL.

2. co jest preferowane?

Naprawdę chciałbym zobaczyć kilka powodów, dla których warto wybrać jedno nad drugim ... I chcesz być w stanie po prostu wybrać jeden i używać go na zawsze z najmniejszym zamieszaniem.

W porządku, mam prostą strategię, którą kieruję się przy podejmowaniu tych decyzji, którymi podzielę się z wami w nadziei, że może to pomóc.

Myślę, że to specyfikacja HTTP / 1.1 RFC 2616 wymagała "tolerancyjne zastosowania"

Klienci powinni być tolerancyjni w parsowaniu linii statusu i serwerów Tolerancyjny podczas parsowania Request-Line.

W obliczu takich pytań najlepszą strategią jest zawsze spożywać jak najwięcej i produkować to, co jest zgodne z normami.

Więc radzę używać rawurlencode do tworzenia zgodnych ze standardami łańcuchów kodowanych RFC 1738 i używać urldecode, aby być wstecznie kompatybilnym i pomieścić wszystko, co można natknąć się konsumować.

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

Wydaje się PHP miało dokładnie to na myśli, mimo że nigdy nie spotkałem nikogo, kto odmawia żadnego z dwóch formatów, nie mogę wymyślić lepszej strategii do przyjęcia jako strategii defacto, prawda?

Urlencode : różni się to od "Kodowanie RFC 1738 (zobacz rawurlencode ()) w tym dla historycznych powody, spacje są zakodowane jako plus ( + ) znaki.

Uważam, że urlencode jest dla parametrów zapytania, podczas gdy rawurlencode jest dla segmentów ścieżki. Wynika to głównie z %20 dla segmentów ścieżki vs + dla parametrów zapytania. Zobacz odpowiedź, która mówi o spacjach: Kiedy zakodować spację na plus ( + ) lub %20?

Jednak %20 działa teraz również w parametrach zapytań, dlatego rawurlencode jest zawsze bezpieczniejszy. Jednak znak plus jest zwykle używany tam, gdzie użytkownik doświadcza edycji i czytelności parametrów zapytania Materia.

Zauważ, że oznacza to, że rawurldecode nie dekoduje + na spacje (http://au2.php.net/manual/en/function.rawurldecode.php ). dlatego $_GET jest zawsze automatycznie przepuszczany przez urldecode, co oznacza, że + i %20 są dekodowane na spacje.

Jeśli chcesz, aby kodowanie i dekodowanie były spójne między wejściami i wyjściami i wybrałeś zawsze używać +, A Nie %20 dla parametrów zapytania, to urlencode jest w porządku dla parametrów zapytania (klucz i wartość).

Wniosek jest następujący:

Segmenty ścieżki - Zawsze używaj rawurlencode / rawurldecode

Parametry zapytania-do dekodowania Zawsze używaj urldecode (wykonywanego automatycznie), do kodowania zarówno rawurlencode, jak i urlencode są w porządku, po prostu wybierz jeden, aby był spójny, szczególnie podczas porównywania adresów URL.

Spacje zakodowane jako %20 vs. +

Największym powodem, dla którego używam rawurlencode() w większości przypadków jest to, że urlencode koduje spacje tekstowe jako + (znaki plus), gdzie rawurlencode koduje je jako powszechnie widziane %20:

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

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

Widziałem pewne punkty końcowe API, które akceptują zakodowane zapytania tekstowe, oczekują, że będą widzieć %20 dla spacji i w rezultacie nie powiodą się, jeśli zamiast tego zostanie użyty znak plus. Oczywiście będzie się to różnić między implementacjami API, a przebieg może / align = "left" /

Proste * rawurlencode The path - ścieżka jest częścią przed"?" - spacje muszą być zakodowane jako %20 * urlencode ciąg zapytania - Łańcuch zapytania jest częścią po"?" - spacje są lepiej zakodowane jako" +" = rawurlencode jest bardziej kompatybilny ogólnie