urlencode vs rawurlencode?


380

Se eu quiser criar um URL usando uma variável, tenho duas opções para codificar a string. urlencode()e rawurlencode().

Quais são exatamente as diferenças e qual é a preferida?


11
Eu realmente gostaria de ver alguns motivos para escolher um sobre o outro (por exemplo, problemas que podem ser encontrados com um ou outro), eu (e espero que outros) desejem poder escolher um e usá-lo para sempre com o menos barulho, então eu comecei uma recompensa nesta questão.
Kzqai

29
@Tchalvak: Se você quiser escolher apenas um, escolha rawurlencode. Você raramente se depara com um sistema que engasga quando determinados espaços são codificados como %20, enquanto sistemas que engasgam com espaços codificados como +são mais comuns.
Anomia

Respostas:


326

Vai depender do seu propósito. Se a interoperabilidade com outros sistemas é importante, parece que o código de código bruto é o caminho a seguir. A única exceção são os sistemas legados que esperam que a string de consulta siga o estilo de codificação de formulário dos espaços codificados como + em vez de% 20 (nesse caso, você precisa do código de URL).

O rawurlencode segue o RFC 1738 anterior ao PHP 5.3.0 e o RFC 3986 posteriormente (consulte http://us2.php.net/manual/en/function.rawurlencode.php )

Retorna uma sequência na qual todos os caracteres não alfanuméricos, exceto -_. ~ Foram substituídos por um sinal de porcentagem (%) seguido por dois dígitos hexadecimais. Essa é a codificação descrita em »RFC 3986 para proteger caracteres literais de serem interpretados como delimitadores de URL especiais e para impedir que URLs sejam mutilados pela mídia de transmissão com conversões de caracteres (como alguns sistemas de email).

Nota no RFC 3986 vs 1738. O rawurlencode antes do php 5.3 codificava o caractere til ( ~) de acordo com o RFC 1738. No PHP 5.3, no entanto, o rawurlencode segue o RFC 3986, que não requer codificação de caracteres til.

O urlencode codifica os espaços como sinais de adição (não %20como feito no rawurlencode) (consulte http://us2.php.net/manual/en/function.urlencode.php )

Retorna uma sequência na qual todos os caracteres não alfanuméricos, exceto -_. foram substituídos por um sinal de porcentagem (%) seguido de dois dígitos hexadecimais e espaços codificados como sinais de mais (+). É codificado da mesma maneira que os dados publicados de um formulário da WWW são codificados, da mesma forma que no tipo de mídia application / x-www-form-urlencoded. Isso difere da codificação »RFC 3986 (consulte rawurlencode ()), pois, por razões históricas, os espaços são codificados como sinais de mais (+).

Isso corresponde à definição para application / x-www-form-urlencoded na RFC 1866 .

Leitura adicional:

Você também pode querer assistir à discussão em http://bytes.com/groups/php/5624-urlencode-vs-rawurlencode .

Além disso, o RFC 2396 vale a pena dar uma olhada. O RFC 2396 define a sintaxe válida do URI. A parte principal em que estamos interessados ​​é do 3.4 Query Component:

Dentro de um componente de consulta, os caracteres são reservados.";", "/", "?", ":", "@",
"&", "=", "+", ",", and "$"

Como você pode ver, +é um caractere reservado na string de consulta e, portanto, precisaria ser codificado de acordo com a RFC 3986 (como no rawurlencode).


27
Então, qual é o preferido?
Gary Willoughby

79
rawurlencode. vá com o padrão neste caso. urlencode só é mantido para uso legado
Jonathan Fingland

2
Muito obrigado, foi o que eu pensei, eu só queria uma segunda opinião antes de começar a atualizar muito código.
Gary Willoughby

3
Eu acho que é rawurlencode que não espaços codificar como sinais de mais, mas como% 20s
BigName

2
@Pindatjuh: A parte que você citou A única exceção é os sistemas legados que esperam que a string de consulta para acompanhar o estilo de codificação forma de espaços codificados como + em vez de% 20 (caso em que você precisa urlencode) significa que enquanto rawurlencode é certa para a maioria situação , alguns sistemas esperam que os espaços sejam codificados como um + (sinal de mais). Para esses sistemas, o urlencode é a melhor escolha.
Jonathan Fingland

213

A prova está no código fonte do PHP.

Vou levá-lo através de um processo rápido de como descobrir esse tipo de coisa por conta própria no futuro a qualquer momento que você quiser. Tenha paciência comigo, haverá muito código-fonte C em que você pode ler (eu explico). Se você deseja atualizar um pouco de C, um bom lugar para começar é o nosso SO wiki .

Faça o download da fonte (ou use http://lxr.php.net/ para navegar online), grep todos os arquivos para o nome da função, você encontrará algo como isto:

PHP 5.3.6 (mais recente no momento da escrita) descreve as duas funções em seu código nativo C no arquivo 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);
}

Ok, então o que há de diferente aqui?

Ambos estão essencialmente chamando duas funções internas diferentes, respectivamente: php_raw_url_encode e php_url_encode

Então vá procurar essas funções!

Vamos olhar para 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);
}

E, claro, 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;
}

Um conhecimento rápido antes de avançar, EBCDIC é outro conjunto de caracteres , semelhante ao ASCII, mas um concorrente total. O PHP tenta lidar com ambos. Mas basicamente, isso significa que o byte EBCDIC 0x4c não é o LASCII, na verdade é um <. Tenho certeza que você vê a confusão aqui.

Ambas as funções gerenciam o EBCDIC se o servidor da web o definiu.

Além disso, ambos usam uma pesquisa de caracteres chars (tipo de cadeia de caracteres) hexcharspara obter alguns valores; a matriz é descrita da seguinte forma:

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

Além disso, as funções são realmente diferentes, e eu vou explicá-las em ASCII e EBCDIC.

Diferenças em ASCII:

URLENCODE:

  • Calcula um comprimento inicial / final da sequência de entrada, aloca memória
  • Anda através de um loop while, incrementa até chegar ao final da string
  • Agarra o personagem atual
  • Se o caractere for igual ao ASCII Char 0x20 (ou seja, um "espaço"), adicione um +sinal à string de saída.
  • Se não é um espaço, e também não é alfanumérico ( isalnum(c)), e também não é e _, -ou .caractere, emitimos um %sinal para a posição 0 da matriz, fazemos uma matriz procurar na hexcharsmatriz uma procura por os_toasciimatriz ( uma matriz do Apache que converte char para código hexadecimal) para a chave dec (o caractere presente), então deslocamos bit a bit para a direita em 4, atribuímos esse valor ao caractere 1 e à posição 2 atribuímos a mesma pesquisa, exceto que executamos um lógico e para ver se o valor é 15 (0xF) e retorne 1 nesse caso ou 0 caso contrário. No final, você terminará com algo codificado.
  • Se acabar, não é um espaço, é alfanumérico ou um dos _-.caracteres, gera exatamente o que é.

RAWURLENCODE:

  • Aloca memória para a sequência
  • Repete sobre ele com base no comprimento fornecido na chamada de função (não calculado na função como com URLENCODE).

Nota: Muitos programadores provavelmente nunca viram um loop for iterar dessa maneira, é um tanto hackiano e não a convenção padrão usada com a maioria dos loops for, preste atenção, ele atribui xe yverifica a saída ao lenatingir 0 e incrementa ambos xe y. Eu sei, não é o que você esperaria, mas é um código válido.

  • Atribui o caractere atual a uma posição de caractere correspondente em str.
  • Ele verifica se o caractere atual é alfanumérico ou um dos _-.caracteres, e se não for, fazemos quase a mesma atribuição que com URLENCODE onde ele realiza pesquisas, no entanto, incrementamos de maneira diferente, usando em y++vez de to[1], isso ocorre porque o as strings estão sendo construídas de maneiras diferentes, mas atingem o mesmo objetivo no final.
  • Quando o loop termina e o comprimento acaba, na verdade termina a string, atribuindo o \0byte.
  • Retorna a string codificada.

Diferenças:

  • UrlEncode verifica se há espaço, atribui um sinal de +, RawURLEncode não.
  • UrlEncode não atribui um \0byte à cadeia de caracteres, RawUrlEncode (isso pode ser um ponto discutível)
  • Eles iteram de maneira diferente, é possível que você transborde com seqüências de caracteres malformadas, estou apenas sugerindo isso e na verdade não investiguei.

Basicamente, iteram de maneira diferente, atribui-se um sinal de + no evento ASCII 20.

Diferenças no EBCDIC:

URLENCODE:

  • Mesma configuração de iteração que com ASCII
  • Ainda traduzindo o caractere "espaço" para um sinal de + . Nota-- Acho que isso precisa ser compilado no EBCDIC ou você vai acabar com um bug? Alguém pode editar e confirmar isso?
  • Ele verifica se o caractere atual é um caractere anterior 0, com exceção de ser um .ou -, OR menor que Amas maior que char 9, OR maior que Ze menor que amas não a _. OU maior que z(sim, EBCDIC está meio bagunçado para trabalhar). Se corresponder a qualquer um desses, faça uma pesquisa semelhante à encontrada na versão ASCII (apenas não requer uma pesquisa em os_toascii).

RAWURLENCODE:

  • Mesma configuração de iteração que com ASCII
  • A mesma verificação descrita na versão EBCDIC do URL Encode, com exceção de que, se for maior que z, exclui ~da codificação de URL.
  • Mesma atribuição que o ASCII RawUrlEncode
  • Ainda anexando o \0byte à string antes de retornar.

Grande resumo

  • Ambos usam a mesma tabela de pesquisa de hexchars
  • URIEncode não finaliza uma string com \ 0, não processado.
  • Se você estiver trabalhando no EBCDIC, sugiro usar o RawUrlEncode, pois ele gerencia o ~que o UrlEncode não faz ( esse é um problema relatado ). Vale a pena notar que ASCII e EBCDIC 0x20 são ambos espaços.
  • Eles iteram de maneira diferente, um pode ser mais rápido, um pode ser propenso a explorações baseadas em memória ou em strings.
  • URIEncode cria um espaço +, RawUrlEncode cria um espaço %20através de pesquisas de matriz.

Isenção de responsabilidade: não toquei em C há anos e não vejo o EBCDIC há muito tempo. Se eu estiver errado em algum lugar, me avise.

Implementações sugeridas

Com base em tudo isso, rawurlencode é o caminho a seguir na maioria das vezes. Como você vê na resposta de Jonathan Fingland, fique com ela na maioria dos casos. Ele lida com o esquema moderno de componentes de URI, onde como urlencode faz as coisas da maneira antiga, onde + significava "espaço".

Se você estiver tentando converter entre o formato antigo e os novos, certifique-se de que seu código não aconteça e transforme algo que é um sinal + decodificado em um espaço por meio de codificação dupla acidental ou cenários semelhantes de "ops" espaço / 20% / + problema.

Se você estiver trabalhando em um sistema mais antigo com software mais antigo que não prefere o novo formato, fique com o código de URL, no entanto, acredito que% 20 será realmente compatível com versões anteriores, pois no antigo padrão% 20 funcionou, simplesmente não era preferido. Dê uma chance se quiser brincar, deixe-nos saber como funcionou para você.

Basicamente, você deve ficar com o raw, a menos que seu sistema EBCDIC realmente o odeie. A maioria dos programadores nunca encontrará o EBCDIC em qualquer sistema criado após o ano de 2000, talvez até 1990 (isso é bom, mas ainda é provável na minha opinião).


Eu nunca tive que me preocupar com codificação dupla, afinal, eu deveria saber o que codifiquei, já que sou eu a codificação que eu pensaria. Como decodifico tudo o que recebo com o modo de compatibilidade que sabe como tratar o + espaço, também nunca me deparei com os problemas que você tenta alertar aqui. Eu posso entender olhando a fonte se não soubermos o que algo faz, mas o que exatamente aprendemos aqui que ainda não sabíamos simplesmente executando as duas funções. Eu sei que sou tendencioso, mas não posso deixar de pensar que isso foi exagerado. Parabéns pelo esforço! =)
nickl-

2
+1, para esta parte: "Eu acredito% 20 vai realmente ser compatível, como sob o antigo% padrão de 20 trabalhado, só não foi preferido"
Gras Duplo

3
Boa resposta, mas talvez um pouco exagero?
Rinogo 9/08/19

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

rendimentos

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

enquanto

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

rendimentos

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

A diferença é o asd%20asdvsasd+asd

urlencode difere do RFC 1738, codificando espaços, em +vez de%20


28

Um motivo prático para escolher um sobre o outro é se você usará o resultado em outro ambiente, por exemplo, JavaScript.

No PHP, urlencode('test 1')retorna 'test+1'enquanto rawurlencode('test 1')retorna 'test%201'como resultado.

Mas se você precisa de "decodificar" isso em JavaScript usando decodeURI () função, em seguida, decodeURI("test+1")irá dar-lhe "test+1"enquanto decodeURI("test%201")lhe dará "test 1"como resultado.

Em outras palavras, o espaço ("") codificado pelo urlencode para mais ("+") no PHP não será decodificado adequadamente pelo decodeURI no JavaScript.

Nesses casos, a função PHP rawurlencode deve ser usada.


6
Esta é de longe a melhor resposta que eu já vi. Ele fornece uma sugestão para uso, voltando a um exemplo do mundo real. Além disso, é conciso.
dotancohen

É um bom exemplo, embora eu prefira json_encodee JSON.parsepara esse fim.
Fabrício Matté 05/02

21

Acredito que os espaços devem ser codificados como:

O exemplo a seguir mostra o uso correto de rawurlencodee urlencode:

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

Resultado:

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

O que acontece se você codificar o caminho e consultar os componentes da cadeia de caracteres ao contrário? Para o seguinte exemplo:

http://example.com/category/latest+songs/search?q=lady%20gaga
  • O servidor da web procurará o diretório em latest+songsvez delatest songs
  • O parâmetro da string de consulta qconterálady gaga

2
"O parâmetro da string de consulta qconterá lady gaga" O que mais ele conteria? O parâmetro query qparece ter o mesmo valor passado para a $_GETmatriz, independentemente do uso rawurlencodeou urlencodeno PHP 5.2+. No entanto, urlencodecodifica no application/x-www-form-urlencodedformato que é padrão para solicitações GET, então eu vou com sua abordagem. +1
Fabrício Matté 05/02

2
Eu queria esclarecer que ambos +e %20são decodificados como espaço quando usados ​​em seqüências de caracteres de consulta.
precisa

5

A diferença está nos valores de retorno, ou seja:

urlencode () :

Retorna uma sequência na qual todos os caracteres não alfanuméricos, exceto -_. foram substituídos por um sinal de porcentagem (%) seguido de dois dígitos hexadecimais e espaços codificados como sinais de mais (+). É codificado da mesma maneira que os dados publicados de um formulário da WWW são codificados, da mesma forma que no tipo de mídia application / x-www-form-urlencoded. Isso difere da codificação »RFC 1738 (consulte rawurlencode ()), pois, por razões históricas, os espaços são codificados como sinais de adição (+).

rawurlencode () :

Retorna uma sequência na qual todos os caracteres não alfanuméricos, exceto -_. foram substituídos por um sinal de porcentagem (%) seguido por dois dígitos hexadecimais. Essa é a codificação descrita na »RFC 1738 para proteger caracteres literais de serem interpretados como delimitadores de URL especiais e para impedir que URLs sejam mutilados pela mídia de transmissão com conversões de caracteres (como alguns sistemas de email).

Os dois são muito semelhantes, mas o último (rawurlencode) substituirá espaços por um '%' e dois dígitos hexadecimais, o que é adequado para codificar senhas ou outras, em que um '+' não é, por exemplo:

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">

2
O OP pergunta como saber qual usar e quando. Saber o que cada um faz com espaços não ajuda o OP a tomar uma decisão se ele não souber a importância dos diferentes valores de retorno.
dotancohen

5

1. Quais são exatamente as diferenças e

A única diferença está na maneira como os espaços são tratados:

urlencode - com base na implementação herdada converte espaços em +

rawurlencode - com base no RFC 1738 converte espaços para% 20

O motivo da diferença é porque + é reservado e válido (não codificado) em URLs.

2. qual é o preferido?

Eu realmente gostaria de ver alguns motivos para escolher um sobre o outro ... Eu quero poder escolher um e usá-lo para sempre com o mínimo barulho.

Justo, tenho uma estratégia simples que sigo ao tomar essas decisões, que compartilharei com você na esperança de que possa ajudar.

Eu acho que foi a especificação HTTP / 1.1 RFC 2616 que pediu " aplicativos tolerantes "

Os clientes devem ser tolerantes ao analisar a linha de status e os servidores tolerantes ao analisar a linha de solicitação.

Quando confrontada com perguntas como essas, a melhor estratégia é sempre consumir o máximo possível e produzir o que é compatível com os padrões.

Portanto, meu conselho é usar rawurlencodepara produzir seqüências codificadas em conformidade com os padrões RFC 1738 e urldecodeser compatível com versões anteriores e acomodar qualquer coisa que você possa encontrar para consumir.

Agora você pode apenas aceitar minha palavra, mas vamos provar que devemos ...

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 o PHP tinha exatamente isso em mente, mesmo que eu nunca tenha encontrado alguém que se recuse a nenhum dos dois formatos, não consigo pensar em uma estratégia melhor para adotar como sua estratégia defacto, pode?

nJoy!


4

urlencode : difere da codificação »RFC 1738 (consulte rawurlencode ()) porque, por razões históricas, os espaços são codificados como sinais de adição (+).


2

Espaços codificados como %20vs.+

A maior razão que eu vi usar rawurlencode()na maioria dos casos é porque urlencodecodifica os espaços de texto como +(sinais de mais), onde os rawurlencodecodifica como os mais comuns %20:

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

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

Vi especificamente determinados pontos de extremidade da API que aceitam consultas de texto codificado que esperam ver %20 por um espaço e, como resultado, falham se um sinal de adição for usado. Obviamente, isso difere entre implementações de API e sua milhagem pode variar.


1

Acredito que urlencode é para parâmetros de consulta, enquanto o rawurlencode é para os segmentos de caminho. Isso se deve principalmente aos %20segmentos de caminho e +aos parâmetros de consulta. Veja esta resposta que fala sobre os espaços: Quando codificar o espaço para mais (+) ou% 20?

No entanto, %20agora também funciona nos parâmetros de consulta, e é por isso que o rawurlencode é sempre mais seguro. No entanto, o sinal de mais tende a ser usado onde a experiência do usuário de edição e legibilidade dos parâmetros de consulta são importantes.

Observe que isso significa rawurldecodeque não decodifica +em espaços ( http://au2.php.net/manual/en/function.rawurldecode.php ). É por isso que o $ _GET é sempre passado automaticamente através urldecode, o que significa que +e %20ambos são decodificados em espaços.

Se você deseja que a codificação e a decodificação sejam consistentes entre entradas e saídas e optou por sempre usar +e não %20para parâmetros de consulta, isso urlencodeé bom para parâmetros de consulta (chave e valor).

A conclusão é:

Segmentos de caminho - sempre use rawurlencode / rawurldecode

Parâmetros de consulta - para decodificar sempre use urldecode (feito automaticamente), para codificação, tanto rawurlencode quanto urlencode estão corretos, basta escolher um que seja consistente, especialmente ao comparar URLs.


0

simple * rawurlencode o caminho - o caminho é a parte antes do "?" - espaços devem ser codificados como% 20 * urlencode a string de consulta - String de consulta é a parte após o "?" -spaces são melhor codificados como "+" = rawurlencode é mais compatível geralmente

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.