urlencode vs rawurlencode?

Si quiero crear una URL usando una variable, tengo dos opciones para codificar la cadena. urlencode()y rawurlencode().

¿Cuáles son exactamente las diferencias y cuál es el preferido?

Dependerá de tu propósito. Si la interoperabilidad con otros sistemas es importante, entonces parece que el código sin procesar es el camino a seguir. La única excepción son los sistemas heredados que esperan que la cadena de consulta siga el estilo de codificación de formulario de espacios codificados como + en lugar de% 20 (en cuyo caso necesita el código urlen).

rawurlencode sigue RFC 1738 antes de PHP 5.3.0 y RFC 3986 después (ver http://us2.php.net/manual/en/function.rawurlencode.php )

Devuelve una cadena en la que todos los caracteres no alfanuméricos, excepto -_. ~, Se han reemplazado con un signo de porcentaje (%) seguido de dos dígitos hexadecimales. Esta es la codificación descrita en »RFC 3986 para proteger los caracteres literales de ser interpretados como delimitadores de URL especiales, y para proteger las URL de ser destruidas por medios de transmisión con conversiones de caracteres (como algunos sistemas de correo electrónico).

Nota sobre RFC 3986 vs 1738. rawurlencode anterior a php 5.3 codificó el carácter tilde ( ~) de acuerdo con RFC 1738. Sin embargo, a partir de PHP 5.3, rawurlencode sigue RFC 3986 que no requiere codificar caracteres tilde.

urlencode codifica espacios como signos más (no %20como se hace en rawurlencode) (consulte http://us2.php.net/manual/en/function.urlencode.php )

Devuelve una cadena en la que todos los caracteres no alfanuméricos excepto -_. se han reemplazado con un signo de porcentaje (%) seguido de dos dígitos hexadecimales y espacios codificados como signos más (+). Se codifica de la misma manera que se codifican los datos publicados de un formulario WWW, de la misma manera que en el tipo de medio application / x-www-form-urlencoded. Esto difiere de la codificación »RFC 3986 (ver rawurlencode ()) en que, por razones históricas, los espacios se codifican como signos más (+).

Esto corresponde a la definición de aplicación / x-www-form-urlencoded en RFC 1866 .

Lectura adicional:

También puede ver la discusión en http://bytes.com/groups/php/5624-urlencode-vs-rawurlencode .

Además, RFC 2396 merece un vistazo. RFC 2396 define la sintaxis de URI válida. La parte principal que nos interesa es del componente de consulta 3.4:

Dentro de un componente de consulta, los caracteres están reservados.";", "/", "?", ":", "@",
"&", "=", "+", ",", and "$"

Como puede ver, el +es un carácter reservado en la cadena de consulta y, por lo tanto, debería codificarse según RFC 3986 (como en rawurlencode).

La prueba está en el código fuente de PHP.

Te guiaré a través de un proceso rápido de cómo descubrir este tipo de cosas por tu cuenta en el futuro en cualquier momento que desees. Tenga paciencia conmigo, habrá un montón de código fuente C que puede leer (lo explico). Si desea repasar un poco de C, un buen lugar para comenzar es nuestra wiki de SO .

Descargue la fuente (o use http://lxr.php.net/ para navegar en línea), seleccione todos los archivos para el nombre de la función, encontrará algo como esto:

PHP 5.3.6 (más reciente en el momento de escribir esto) describe las dos funciones en su código nativo de C en el archivo 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);
}

Bien, entonces, ¿qué hay de diferente aquí?

Ambos esencialmente llaman a dos funciones internas diferentes respectivamente: php_raw_url_encode y php_url_encode

¡Así que ve a buscar esas funciones!

Veamos 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);
}

Y, por supuesto, 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;
}

Un poco de conocimiento rápido antes de avanzar, EBCDIC es otro conjunto de caracteres , similar a ASCII, pero un competidor total. PHP intenta lidiar con ambos. Pero básicamente, esto significa que el byte EBCDIC 0x4c no está Len ASCII, en realidad es un <. Estoy seguro de que ves la confusión aquí.

Ambas funciones administran EBCDIC si el servidor web lo ha definido.

Además, ambos usan una matriz de caracteres (piense en el tipo de cadena) hexcharspara obtener algunos valores, la matriz se describe como tal:

/* 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";

Más allá de eso, las funciones son realmente diferentes, y las voy a explicar en ASCII y EBCDIC.

Diferencias en ASCII:

URLENCODE:

• Calcula una longitud de inicio / fin de la cadena de entrada, asigna memoria
• Camina a través de un ciclo while, incrementos hasta llegar al final de la cadena
• Agarra el personaje actual
• Si el carácter es igual a ASCII Char 0x20 (es decir, un "espacio"), agregue un +signo a la cadena de salida.
• Si no es un espacio, y tampoco es alfanumérico ( isalnum(c)), y tampoco es y _, -o .carácter, entonces, enviamos un %signo a la posición 0 de la matriz, buscamos una hexcharsmatriz para buscar una os_toasciimatriz ( una matriz de Apache que traduce char a código hexadecimal) para la clave de c(el carácter actual), luego cambiamos bit a la derecha por 4, asignamos ese valor al carácter 1, y a la posición 2 asignamos la misma búsqueda, excepto que preformamos un lógico y para ver si el valor es 15 (0xF), y devolver un 1 en ese caso, o un 0 en caso contrario. Al final, terminarás con algo codificado.
• Si termina no es un espacio, es alfanumérico o uno de los _-.caracteres, genera exactamente lo que es.

CÓDIGO SIN PROCESAR:

• Asigna memoria para la cadena
• Se repite en función de la longitud proporcionada en la llamada a la función (no se calcula en la función como con URLENCODE).

Nota: Muchos programadores probablemente nunca hayan visto un bucle for iterar de esta manera, es algo hackeo y no es la convención estándar utilizada con la mayoría de los bucles for, presta atención, asigna xy ycomprueba la salida al lenllegar a 0, e incrementa ambos xy y. Lo sé, no es lo que esperarías, pero es un código válido.

• Asigna el personaje actual a una posición de personaje coincidente en str.
• Comprueba si el carácter actual es alfanumérico, o uno de los _-.caracteres, y si no lo es, hacemos casi la misma asignación que con URLENCODE donde realiza búsquedas, sin embargo, incrementamos de manera diferente, usando en y++lugar de to[1], esto es porque el Las cadenas se construyen de diferentes maneras, pero de todos modos alcanzan el mismo objetivo al final.
• Cuando finaliza el ciclo y desaparece la longitud, en realidad termina la cadena, asignando el \0byte.
• Devuelve la cadena codificada.

Diferencias:

• UrlEncode busca espacio, asigna un signo +, RawURLEncode no.
• UrlEncode no asigna un \0byte a la cadena, RawUrlEncode sí (esto puede ser un punto discutible)
• Se repiten de manera diferente, uno puede ser propenso a desbordarse con cadenas malformadas, simplemente sugiero esto y en realidad no he investigado.

Básicamente iteran de manera diferente, uno asigna un signo + en el caso de ASCII 20.

Diferencias en EBCDIC:

URLENCODE:

• La misma configuración de iteración que con ASCII
• Aún traduciendo el carácter "espacio" a un signo + . Nota: ¿creo que esto debe compilarse en EBCDIC o terminará con un error? ¿Alguien puede editar y confirmar esto?
• Comprueba si el char actual es un char antes 0, con la excepción de ser un .o -, O menor que Apero mayor que char 9, O mayor que Zy menor que apero no a _. O mayor que z(sí, EBCDIC es un poco complicado para trabajar). Si coincide con alguno de ellos, realice una búsqueda similar a la que se encuentra en la versión ASCII (simplemente no requiere una búsqueda en os_toascii).

CÓDIGO SIN PROCESAR:

• La misma configuración de iteración que con ASCII
• La misma verificación que se describe en la versión EBCDIC de URL Encode, con la excepción de que si es mayor que z, se excluye ~de la codificación URL.
• Misma asignación que el ASCII RawUrlEncode
• Aún agregando el \0byte a la cadena antes de regresar.

Gran resumen

• Ambos usan la misma tabla de búsqueda hexchars
• URIEncode no termina una cadena con \ 0, sin procesar.
• Si está trabajando en EBCDIC, sugeriría usar RawUrlEncode, ya que gestiona ~que UrlEncode no lo haga ( este es un problema reportado ). Vale la pena señalar que ASCII y EBCDIC 0x20 son ambos espacios.
• Se iteran de manera diferente, uno puede ser más rápido, uno puede ser propenso a la memoria o exploits basados ​​en cadenas.
• URIEncode crea un espacio en +, RawUrlEncode crea un espacio en las %20búsquedas de matriz.

Descargo de responsabilidad: no he tocado C en años, y no he visto EBCDIC en mucho, mucho tiempo. Si me equivoco en alguna parte, avísame.

Implementaciones sugeridas

Basado en todo esto, el código rawurlen es el camino a seguir la mayor parte del tiempo. Como puede ver en la respuesta de Jonathan Fingland, sígalo en la mayoría de los casos. Se trata del esquema moderno para los componentes de URI, donde como urlencode hace las cosas a la antigua usanza, donde + significa "espacio".

Si está tratando de convertir entre el formato anterior y el nuevo, asegúrese de que su código no aumente y convierta algo que es un signo decodificado + en un espacio mediante la doble codificación accidental o escenarios similares de "oops" alrededor de esto espacio / 20% / + tema.

Si está trabajando en un sistema más antiguo con un software más antiguo que no prefiere el nuevo formato, siga con urlencode, sin embargo, creo que% 20 en realidad será compatible con versiones anteriores, ya que según el antiguo estándar% 20 funcionó, simplemente no era privilegiado. Pruébalo si estás dispuesto a jugar, dinos cómo te fue.

Básicamente, debe seguir con raw, a menos que su sistema EBCDIC realmente lo odie. La mayoría de los programadores nunca se encontrarán con EBCDIC en ningún sistema fabricado después del año 2000, tal vez incluso 1990 (eso es difícil, pero aún es probable en mi opinión).

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

rendimientos

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

mientras

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

rendimientos

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

La diferencia es el asd%20asdvsasd+asd

urlencode difiere de RFC 1738 al codificar espacios como en +lugar de%20

Una razón práctica para elegir uno sobre el otro es si va a utilizar el resultado en otro entorno, por ejemplo, JavaScript.

En PHP urlencode('test 1')devuelve 'test+1'mientras que rawurlencode('test 1')devuelve 'test%201'como resultado.

Pero si necesita "decodificar" esto en JavaScript utilizando la función decodeURI () , entonces decodeURI("test+1")le dará "test+1"mientras que decodeURI("test%201")le dará "test 1"como resultado.

En otras palabras, el espacio ("") codificado por urlencode a más ("+") en PHP no será decodificado correctamente por decodeURI en JavaScript.

En tales casos , se debe utilizar la función PHP rawurlencode .

Creo que los espacios deben codificarse como:

• %20 cuando se usa dentro del componente de ruta URL
• +cuando se usa dentro del componente de cadena de consulta URL o datos de formulario (consulte 17.13.4 Tipos de contenido de formulario )

El siguiente ejemplo muestra el uso correcto de rawurlencodey urlencode:

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

Salida:

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

¿Qué sucede si codifica la ruta y consulta los componentes de la cadena al revés? Para el siguiente ejemplo:

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

• El servidor web buscará el directorio en latest+songslugar delatest songs
• El parámetro de cadena de consulta qcontendrálady gaga

La diferencia está en los valores de retorno, es decir:

urlencode () :

Devuelve una cadena en la que todos los caracteres no alfanuméricos excepto -_. se han reemplazado con un signo de porcentaje (%) seguido de dos dígitos hexadecimales y espacios codificados como signos más (+). Se codifica de la misma manera que se codifican los datos publicados de un formulario WWW, de la misma manera que en el tipo de medio application / x-www-form-urlencoded. Esto difiere de la codificación »RFC 1738 (ver rawurlencode ()) en que, por razones históricas, los espacios se codifican como signos más (+).

rawurlencode () :

Devuelve una cadena en la que todos los caracteres no alfanuméricos excepto -_. han sido reemplazados por un signo de porcentaje (%) seguido de dos dígitos hexadecimales. Esta es la codificación descrita en »RFC 1738 para proteger los caracteres literales de ser interpretados como delimitadores de URL especiales, y para proteger las URL de ser destruidas por medios de transmisión con conversiones de caracteres (como algunos sistemas de correo electrónico).

Los dos son muy similares, pero el último (código rawurlen) reemplazará los espacios con un '%' y dos dígitos hexadecimales, lo cual es adecuado para codificar contraseñas o similares, donde un '+' no es, por ejemplo:

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. ¿Cuáles son exactamente las diferencias y

La única diferencia está en la forma en que se tratan los espacios:

urlencode: basado en la implementación heredada convierte espacios en +

rawurlencode - basado en RFC 1738 traduce espacios a% 20

La razón de la diferencia es porque + es reservado y válido (sin codificar) en las URL.

2. ¿Cuál es el preferido?

Realmente me gustaría ver algunas razones para elegir uno sobre el otro ... Quiero poder elegir uno y usarlo para siempre con el menor alboroto.

Justamente, tengo una estrategia simple que sigo al tomar estas decisiones que compartiré con ustedes con la esperanza de que pueda ayudar.

Creo que fue la especificación HTTP / 1.1 RFC 2616 que pidió " Aplicaciones tolerantes "

Los clientes DEBEN ser tolerantes al analizar la línea de estado y los servidores tolerantes al analizar la línea de solicitud.

Cuando se enfrentan a preguntas como estas, la mejor estrategia es siempre consumir tanto como sea posible y producir lo que cumple con los estándares.

Por lo tanto, mi consejo es usar rawurlencodepara producir cadenas codificadas RFC 1738 que cumplan con los estándares y usar urldecodepara ser compatibles con versiones anteriores y acomodar todo lo que pueda encontrar para consumir.

Ahora puedes tomar mi palabra, pero demostremos que si ...

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

Parece que PHP tenía exactamente esto en mente, a pesar de que nunca me he encontrado con nadie que rechace ninguno de los dos formatos, no puedo pensar en una mejor estrategia para adoptar como su estrategia de facto, ¿puede?

nJoy!

urlencode : Esto difiere de la codificación »RFC 1738 (ver rawurlencode ()) en que, por razones históricas, los espacios se codifican como signos más (+).

Espacios codificados como %20vs.+

La razón más grande que he visto usar rawurlencode()en la mayoría de los casos es porque urlencodecodifica espacios de texto como +(más signos) donde los rawurlencodecodifica como los comúnmente vistos %20:

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

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

He visto específicamente ciertos puntos finales de la API que aceptan consultas de texto codificado que esperan ver %20por un espacio y, como resultado, fallan si se usa un signo más en su lugar. Obviamente, esto va a diferir entre las implementaciones de API y su kilometraje puede variar.

Creo que urlencode es para parámetros de consulta, mientras que el rawurlencode es para los segmentos de ruta. Esto se debe principalmente a los %20segmentos de ruta frente +a los parámetros de consulta. Vea esta respuesta que habla sobre los espacios: ¿ Cuándo codificar el espacio a más (+) o% 20?

Sin embargo, %20ahora también funciona en los parámetros de consulta, por lo que rawurlencode siempre es más seguro. Sin embargo, el signo más tiende a usarse cuando la experiencia del usuario en la edición y la legibilidad de los parámetros de consulta son importantes.

Tenga en cuenta que esto significa rawurldecodeque no se decodifica +en espacios ( http://au2.php.net/manual/en/function.rawurldecode.php ). Esta es la razón por la $ _GET siempre se pasa automáticamente a través urldecode, lo que significa que +y %20son decodificados tanto en espacios.

Si desea que la codificación y la decodificación sean consistentes entre las entradas y las salidas y ha seleccionado usar siempre +y no %20para los parámetros de consulta, entonces urlencodeestá bien para los parámetros de consulta (clave y valor).

La conclusión es:

Segmentos de ruta: siempre use rawurlencode / rawurldecode

Parámetros de consulta: para la decodificación siempre use urldecode (hecho automáticamente), para codificar, tanto rawurlencode como urlencode están bien, solo elija uno para que sea consistente, especialmente al comparar URL.

simple * rawurlencode la ruta: la ruta es la parte anterior a "?" - los espacios deben codificarse como% 20 * urlencode la cadena de consulta - La cadena de consulta es la parte después de "?" -los espacios están mejor codificados como "+" = rawurlencode es más compatible en general