O que é a maneira correta de URL codificar caracteres Unicode?

votos
98

Eu sei do esquema% uxxxx não-padrão, mas que não parece ser uma escolha sábia desde que o regime foi rejeitado pelo W3C.

Alguns exemplos interessantes:

O caráter de coração. Se eu escreva isso no meu navegador:

http://www.google.com/search?q=♥

Em seguida, copie e cole-o, vejo este URL

http://www.google.com/search?q=%E2%99%A5

que faz parecer que o Firefox (ou Safari) está fazendo isso.

urllib.quote_plus(x.encode(latin-1))
'%E2%99%A5'

o que faz sentido, exceto para as coisas que não podem ser codificados em Latim-1, como o caractere de ponto triplo.

Se eu digitar a URL

http://www.google.com/search?q=…

no meu navegador, em seguida, copiar e colar, recebo

http://www.google.com/search?q=%E2%80%A6

costas. Que parece ser o resultado de fazer

urllib.quote_plus(x.encode(utf-8))

o que faz sentido, uma vez ... não pode ser codificado com Latin-1.

Mas então não é claro para mim como o navegador sabe se para decodificar com UTF-8 ou Latin-1.

Uma vez que este parece ser ambígua:

In [67]: u….encode('utf-8').decode('latin-1')
Out[67]: u'\xc3\xa2\xc2\x80\xc2\xa6'

obras, então eu não sei como as figuras do navegador para fora se para decodificar que, com UTF-8 ou Latin-1.

Qual é a coisa certa a fazer com os caracteres especiais que eu preciso lidar com isso?

Publicado 26/05/2009 em 22:18
fonte usuário
Em outras línguas...                            


5 respostas

votos
56

Eu sempre codificar em UTF-8. A partir da página da Wikipedia sobre codificação por cento :

Os mandatos genéricos sintaxe de URI que novos esquemas URI que fornecem para a representação de dados de caracteres em um URI deve, com efeito, representar caracteres do conjunto sem reservas, sem tradução, e deve converter todos os outros personagens para bytes de acordo com UTF-8, e, em seguida, por cento-codificar esses valores. Este requisito foi introduzido em Janeiro de 2005 com a publicação do RFC 3986 . URI regimes introduzidas antes desta data não são afetados.

Parece que porque havia outras maneiras aceitas de fazer a codificação URL no passado, os navegadores tentar vários métodos de decodificação de um URI, mas se você é o único a fazer a codificação você deve usar UTF-8.

Respondeu 27/05/2009 em 03:18
fonte usuário

votos
9

A regra geral parece ser que os navegadores codificar respostas do formulário de acordo com o tipo de conteúdo da página do formulário foi servido. Esta é uma suposição que se o servidor envia-nos "text / xml; charset = iso-8859-1", então eles esperam respostas de volta no mesmo formato.

Se você está apenas entrando em um URL na barra de URL, o navegador não tem uma página de base para trabalhar e, portanto, só tem que adivinhar. Portanto, neste caso, parece estar fazendo utf-8 todo o tempo (desde que ambos os seus inputs produzidos valores do formulário de três octeto).

A triste verdade é que AFAIK não há nenhum padrão para o conjunto de caracteres os valores em uma string de consulta, ou mesmo quaisquer caracteres no URL, deve ser interpretado como. Pelo menos no caso de valores na cadeia de consulta, não há nenhuma razão para supor que eles necessariamente não correspondem aos caracteres.

É um problema conhecido que você tem que dizer a sua estrutura de servidor que conjunto de caracteres que você espera a string de consulta para ser codificado como --- por exemplo, no Tomcat, você tem que chamar request.setEncoding () (ou algum método similar) antes de você chamar qualquer um dos métodos request.getParameter (). A escassez de documentação sobre este assunto, provavelmente, reflete a falta de consciência do problema entre muitos desenvolvedores. (I regularmente pedir entrevistados Java qual a diferença entre um leitor e um InputStream é, e regularmente obter olhares em branco)

Respondeu 27/05/2009 em 23:13
fonte usuário

votos
7

IRI ( RFC 3987 ) é o padrão mais recente que substitui o URI / URL ( RFC 3986 padrões mais antigos e). URI / URL não suporta nativamente Unicode (bem, RFC 3986 acrescenta disposições para futuras / protocolos baseados em URL URI para apoiá-lo, mas não atualiza passado RFCs). O esquema "% uXXXX" é uma extensão não-padrão para permitir Unicode em algumas situações, mas não é universalmente implementado por todos. IRI, por outro lado, suporta inteiramente Unicode, e exige que o texto seja codificado como UTF-8 antes em seguida, ser codificado por cento.

Respondeu 19/06/2009 em 23:22
fonte usuário

votos
5

IRIs não substituem URIs, porque apenas URIs (efetivamente, ASCII) são permitidas em alguns contextos - incluindo HTTP.

Em vez disso, você especifica um IRI e se transforma em um URI quando sair no fio.

Respondeu 14/04/2010 em 06:31
fonte usuário

votos
0

A primeira pergunta é quais são as suas necessidades? UTF-8 é um bom compromisso entre a tomada de texto criado com um editor barato e suporte para uma ampla variedade de idiomas. Em relação ao navegador identificando a codificação, a resposta (a partir do servidor web) deve dizer ao navegador a codificação. Ainda a maioria dos navegadores irá tentar adivinhar, porque este está ausente ou errado em tantos casos. Eles acho lendo alguma quantidade do fluxo de resultado para ver se há um personagem que não se encaixa no padrão de codificação. Atualmente todos os navegador (? Eu não verificar isso, mas é muito perto de verdadeira) use utf-8 como padrão.

Portanto, use utf-8 a menos que tenha uma razão para usar um dos muitos outros esquemas de codificação.

Respondeu 27/05/2009 em 17:08
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more