Os URLs estão por toda parte, mas parece que os desenvolvedores não os entendem, porque muitas vezes vejo pessoas pedindo como criar um URL corretamente no transbordamento da pilha. Se você quiser saber como a sintaxe do URL funciona, pode ler este artigo da Lunatech, o que é muito bom.
Este artigo não apresentará toda a sintaxe dos URLs em profundidade (se você deseja entender completamente os URLs, poderá ler a RFC 3986, RFC 1738 e o artigo mencionado acima, bem como a documentação acima do W3). Aqui, quero falar sobre algumas bibliotecas comuns nos URLs de operação e como usá-lo corretamente através do URL-Builder. Esta é uma biblioteca Java que publicamos para criar URLs corretamente.
Pergunta 1: Urlencoder de Java
Essa classe não é apenas mal nomeada, mas sua primeira frase no documento não está muito correta.
Classe de utilidade para codificação de formulário HTML.
Você pode estar se perguntando por que é chamado de urlencoder, mas você está completamente sem palavras quando vê essa linha.
Se você leu a postagem do blog Lunatech, agora deve entender que não pode milagrosamente converter uma string de URL em um objeto URL seguro e codificado corretamente através desta classe. Obviamente, se você não fez lição de casa suficiente, aqui está um pequeno exemplo para ajudá -lo a entender.
Suponha que você tenha um serviço de serviço HTTP http://foo.com/search, que aceita um parâmetro de consulta p, e o valor de p é a sequência a ser pesquisada. Se você pesquisar a string "You & I", o URL da pesquisa que você criou pela primeira vez pode ser assim: http://foo.com/search?q=you & I. É claro que isso não funcionará, porque e é o separador que separa o nome do parâmetro/valores de consulta. Se você receber essa string de URL confusa, ficará impotente porque, antes de tudo, não poderá analisar corretamente.
Ok, vamos usar o Urlencoder. Urlencoder.encode ("you & i", "utf-8") é o resultado de que você+%26+i. Depois de decodificar esse %26, ele é & e o sinal + representa espaços na sequência de consultas, para que esse URL possa funcionar normalmente.
Agora, suponha que você queira usar sua sequência de consulta para consumir o caminho da URL em vez de colocá -la nos parâmetros da URL. Obviamente, http://foo.com/search/you e eu está errado. Infelizmente, o resultado do urlencoder.Encode () também está errado. http://foo.com/search/you+%26+i obterá/search/you+&+i, porque o sinal+não resolverá espaços no caminho da URL.
O Urlencoder pode satisfazer alguns de seus cenários. Infelizmente, seu nome excessivamente genérico facilita para os desenvolvedores usá -lo. Portanto, a melhor maneira é não usá -lo, para que outros desenvolvedores cometam erros ao usar outras funções com base na sua base (a menos que você esteja realmente fazendo "codificação de forma html").
Pergunta 2: Groovy Httpbuilder e Java's Uri
O HTTP Builder é uma biblioteca de clientes HTTP da Groovy.
Criar uma solicitação GET normal é muito simples:
novo httpbuilder ("http: // localhost: 18080") .request (métod.get) {uri.path = "/foo"}Este código enviará GET /FOO HTTP /1.1 para o servidor (você pode executar o NC -L -L -P 18080 e, em seguida, executar esse código para verificá -lo).
Vamos tentar o URL que contém espaços.
novo httpbuilder ("http: // localhost: 18080") .request (métod.get) {uri.path = "/foo bar"}Isso envia Get /Foo%20bar HTTP /1.1, que parece muito bom.
Agora, suponha que haja uma seção em nosso caminho chamado Foo/Bar. Isso não pode ser feito simplesmente enviando Foo/Bar, porque isso será considerado como dois segmentos no caminho, Foo e Bar. Vamos tentar Foo%2fBar (substitua / pela codificação correspondente).
novo httpbuilder ('http: // localhost: 18080') .request (métod.get) {uri.path = '/foo%2fbar'}Isso envia get /foo%252fbar http /1.1. Isso não é muito bom. %Em %2f é codificado repetidamente, portanto, o caminho obtido após a decodificação é Foo %2fbar em vez de foo/bar. O verdadeiro culpado aqui é Java.net.uri, porque a classe Uribuilder em Httpbuilder a usa.
O tipo de propriedade URI exposta no fechamento da configuração no código acima é o Uribuilder. Se você atualizar a propriedade Path do URI através do URI.Path =…, ele acabará por chamar um construtor do URI. Este método descreve a propriedade Path de entrada da seguinte maneira:
Se o parâmetro do caminho for fornecido, ele será anexado ao URL. Os caracteres no caminho são codificados, desde que não sejam reservados, pontuados, escapados e outras categorias (Nota do tradutor: essas categorias são detalhadas no RFC 2396) e não são/ou @ números.
Essa abordagem não é muito significativa, porque se o texto antes da codificação contiver caracteres especiais, ela não poderá gerar um segmento de caminho codificado corretamente. Em outras palavras, "vou codificar essa string e depois de codificá -la está correta", o que é obviamente uma falácia, e Uri é vítima dessa falácia. Se a string foi codificada corretamente, não há problema. Caso contrário, será feito porque a string não pode ser analisada. De fato, o que a documentação diz não escapar do / significa que assume que a sequência do caminho foi codificada corretamente (ou seja, é usada corretamente para separar os caminhos) e não foi codificada corretamente (as outras partes, exceto / ainda precisam ser codificadas).
Seria ótimo se o httpbuilder não usar essa função defeituosa da classe URI. Obviamente, seria ainda melhor se o próprio URI estivesse bem.
A maneira correta de fazer isso
Escrevemos esse construtor de URL, que pode ajudar os desenvolvedores a unir facilmente vários tipos de URLs. Segue as especificações de codificação nos materiais de referência no início do artigo e também fornece uma API de streaming. O exemplo de uso a seguir pode cobrir quase todos os cenários de uso:
Urlbuilder.forhost ("http", "foo.com") .PathSegment ("com espaços") .PathSegments ("Path", "com", "varargs") .PathSegment ("& =?/") .QueryParam ("Fancy + Name", "Fancy? .TourlString ()O resultado é: http://foo.com/with%20spaces/path/with/varargs/&=%3f%2f ;matrix=param%3f?fancy%20%2b%20name=fancy?%3DValue#%23?=
Este exemplo demonstra diferentes regras de codificação para cada parte do URL. Por exemplo, o não codificado & = no caminho é permitido, enquanto?/ Precisa ser codificado, mas o = precisa ser codificado nos parâmetros de consulta, mas o? O número não precisa, porque isso já faz parte da sequência de consulta (Nota do tradutor: a sequência de consulta começa com um número?, para que possa incluir um número?
Obrigado pela leitura, espero que isso possa ajudá -lo. Obrigado pelo seu apoio a este site!