Caracteres Unicode em URLs


135

Em 2010, você serviria URLs contendo caracteres UTF-8 em um grande portal da web?

Os caracteres Unicode são proibidos de acordo com o RFC nos URLs (veja aqui ). Eles teriam que ser codificados em porcentagem para serem compatíveis com os padrões.

Meu ponto principal, no entanto, é veicular os caracteres não codificados com o único objetivo de ter URLs de boa aparência, portanto, a porcentagem de codificação está fora.

Todos os principais navegadores parecem analisar bem esses URLs, independentemente do que diz a RFC. Minha impressão geral, porém, é que fica muito instável ao sair do domínio dos navegadores da web:

  • URLs sendo copiadas + coladas em arquivos de texto, e-mails e até sites com codificação diferente
  • Bibliotecas do cliente HTTP
  • Navegadores exóticos, leitores de RSS

Minha impressão está correta de que o problema é esperado aqui e, portanto, ainda não é uma solução prática se você estiver atendendo a um público não técnico e é importante que todos os seus links funcionem corretamente, mesmo que citados e transmitidos?

Existe alguma maneira mágica de exibir URLs de boa aparência em HTML

http://www.example.com/düsseldorf?neighbourhood=Lörick

que pode ser copiado + colado com os caracteres especiais intactos, mas funciona corretamente quando reutilizado em clientes mais antigos?


16
Por sua vez, o Firefox exibe os caracteres Unicode em sua barra de URL, mas os envia para a porcentagem de servidor codificada. Além disso, quando um usuário copia o URL da barra de URLs, o Firefox garante que o URL codificado em porcentagem seja copiado para a área de transferência.
Siddhartha Reddy

Respostas:


126

Use codificação percentual. Navegadores modernos cuidam dos problemas de exibição e colagem e o tornam legível por humanos. Por exemplo. http://ko.wikipedia.org/wiki/ 위키 백과: 대문

Editar: quando você copia esse URL no Firefox, a área de transferência mantém o formulário codificado em porcentagem (o que geralmente é uma coisa boa), mas se você copiar apenas uma parte dele, ele não será codificado.


Uau, na verdade você está certo! Se você cortar e colar um URL codificado em%, o Firefox o transformará na coisa correta para exibição.
Dean Harding

Uau, eu não estava ciente disso. Provavelmente, esta é a melhor solução!
Pekka

33
@ Dean, que é uma mudança bastante recente - em 2005 todas as wikipedias internacionais pareciam um% 6D% 65% 73% 73 real.
Roman Starkov

2
Você pode usar os URLs UTF-8 não codificados, ou seja , IRIs , nos documentos HTML5 agora. Se você fizer isso, todos os principais navegadores entenderão e exibirão corretamente na barra de endereços.
Oliver

Quais bytes os navegadores modernos enviam para os servidores na linha de solicitação GET /images/logo.png HTTP/1.1? Eles sempre codificam por cento o URL?
Flimm

87

O que Tgr disse. Fundo:

http://www.example.com/düsseldorf?neighbourhood=Lörick

Isso não é um URI. Mas é uma IRI .

Você não pode incluir um IRI em um documento HTML4; o tipo de atributos como hrefé definido como URI e não IRI. Alguns navegadores manipularão um IRI aqui de qualquer maneira, mas não é realmente uma boa ideia.

Para codificar um IRI em um URI, pegue o caminho e as partes da consulta, codifique-as por UTF-8 e codifique por cento os bytes não ASCII:

http://www.example.com/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick

Se houver caracteres não ASCII na parte do nome do host do IRI, por exemplo. http://例え.テスト/, eles foram codificados usando o Punycode .

Agora você tem um URI. É um URI feio. Mas a maioria dos navegadores ocultará isso para você: copie e cole na barra de endereço ou siga-o em um link e você verá a exibição com os caracteres Unicode originais. A Wikipedia usa isso há anos, por exemplo:

http://en.wikipedia.org/wiki/ɸ

O único navegador cujo comportamento é imprevisível e nem sempre exibe a bonita versão do IRI é ...

...bem, você sabe.


31
Eu sei. Um dia, alguém tem que pegar um grande clube e dar um tapa na cabeça daqueles desenvolvedores do Lynx. Obrigado pela excelente informação de plano de fundo.
Pekka

2
@bobince E o único bot (avanço rápido para 2013) que também não pode lidar com URIs não IRI é ... ... bem, você sabe: bingbot! Vai saber.
Tom Harrison

1
Finalmente, o HTML5 suporta IRIs. Mais informações sobre o assunto podem ser encontradas nesta resposta a uma pergunta relacionada .
25413 Oliver

5
Re: O IE nem sempre exibe IRIs bonitos - eles estão protegendo os usuários de ataques de phishing baseados em homógrafos. Confira w3.org/International/articles/idn-and-iri (especificamente a seção 'Nomes de domínio e phishing') e blogs.msdn.com/b/ie/archive/2006/07/31/684337.aspx
codingoutloud

2
Os nomes de domínio não têm nada a ver com isso. Todos os navegadores não permitem uma ampla variedade de caracteres para evitar phishing. A exibição de caracteres não ASCII no caminho ou na parte da sequência de consultas não cria uma vulnerabilidade semelhante. O IE simplesmente não se deu ao trabalho de implementá-lo. (E Firefox é o único que implementou para a parte fragmento também.)
Tgr

16

Dependendo do seu esquema de URL, você pode tornar a parte codificada em UTF-8 "não importante". Por exemplo, se você olhar para os URLs de estouro de pilha, eles terão o seguinte formato:

http://stackoverflow.com/questions/2742852/unicode-characters-in-urls

No entanto, o servidor realmente não se importa se você errar a peça após o identificador, então isso também funciona:

http://stackoverflow.com/questions/2742852/ Clique para ver mais.

Portanto, se você tivesse um layout como esse, poderia usar o UTF-8 na parte após o identificador e isso realmente não importaria se fosse ilegível. Claro que isso provavelmente só funciona em circunstâncias especializadas ...


Hmmm, pensamento muito inteligente! Ainda pode ser que alguns clientes engasgar com os personagens, não importa onde eles estão localizados na cadeia, mas seria eliminar todos os problemas com garbling comum quando copiar + colar uma URL, o que eu acho que é a parte mais importante. Ainda não tinha analisado o URL da SO dessa maneira. Obrigado!
Pekka

bem, isso ainda deixa a palavra "perguntas" sem tradução, além de haver coisas após o hash #, que segue o URL inteiro, um truque muito bom!
Evgeny

4
Por exemplo, URL e URL
Glutexo

6

Não tenho certeza se é uma boa ideia, mas, como mencionado em outros comentários e como o interpreto, muitos caracteres Unicode são válidos nos URLs HTML5 .

Por exemplo, os hrefdocumentos dizem http://www.w3.org/TR/html5/links.html#attr-hyperlink-href :

O atributo href nos elementos a e area deve ter um valor que seja uma URL válida potencialmente cercada por espaços.

A definição de "URL válido" aponta para http://url.spec.whatwg.org/ , que define os pontos de código da URL como:

Alfanumérico ASCII, "!", "$", "&", "'", "(", ")", "*", "+", ",", "-" - ",". "," / " , ":", ";", "=", "?", "@", "_", "~" e pontos de código nos intervalos U + 00A0 a U + D7FF, U + E000 a U + FDCF , U + FDF0 a U + FFFD, U + 10000 a U + 1FFFD, U + 20000 a U + 2FFFD, U + 30000 a U + 3FFFD, U + 40000 a U + 4FFFD, U + 50000 a U + 5FFFD, U +60000 para U + 6FFFD, U + 70000 para U + 7FFFD, U + 80000 para U + 8FFFD, U + 90000 para U + 9FFFD, U + A0000 para U + AFFFD, U + B0000 para U + BFFFD, U + C0000 para U + CFFFD, U + D0000 a U + DFFFD, U + E1000 a U + EFFFD, U + F0000 a U + FFFFD, U + 100000 a U + 10FFFD.

O termo "pontos de código de URL" é então usado em algumas partes do algoritmo de análise, por exemplo, para o estado do caminho relativo :

Se c não for um ponto de código da URL e não "%", analise o erro.

Além disso, o validador http://validator.w3.org/ passa por URLs como "你好"e não passa por URLs com caracteres como espaços"a b"

Relacionado: Quais caracteres tornam um URL inválido?


Mas os dois URLs ( "你好"e "a b") precisam ser codificados em porcentagem ao fazer a solicitação HTTP, certo?
Utku

@ Utku para "a b"eu tenho certeza que sim, já que o espaço não está na lista permitida acima. Para "你好", é definitivamente a melhor idéia para cento codificar, mas eu não sei se é apenas uma questão de "as implementações não são bons o suficiente" ou o "padrão diz isso". O padrão HTML parece permitir esses caracteres. Mas acho que isso é especificado pelo padrão HTTP, não pelo HTML. Veja também: stackoverflow.com/questions/912811/…
Ciro Santilli (

Sim, eu estava pensando no padrão HTTP, não em HTML.
Utku

5

Como todos esses comentários são verdadeiros, observe que, na medida em que a ICANN aprovou caracteres árabes (persas) e chineses para serem registrados como nome de domínio, todas as empresas fabricantes de navegadores (Microsoft, Mozilla, Apple etc.) precisam suporta Unicode em URLs sem qualquer codificação, e esses devem ser pesquisáveis ​​pelo Google etc.

Portanto, esse problema resolverá o mais rápido possível.


2
@Nasser: True - também temos caracteres especiais em domínios alemães agora - mas esses são codificados em caracteres ASCII usando o Punycode . Embora eles com certeza funcionem nos principais navegadores, levará muito tempo para que toda biblioteca cliente HTTP e aplicativo exótico consiga lidar com caracteres Unicode não codificados.
Pekka

@Pekka, eu não tenho certeza, mas como eu ouvi, todos os navegadores que suportam Unicode URL no 4º trimestre de 2010. (Eu não sei)
Nasser Hadjloo

A questão é complicada pelo fato de que nem todo agente de usuário é um navegador da web. O maior exemplo é o próprio Google: ele não usa navegadores comuns para fazer o rastreamento. O mesmo aconteceria com muitas bibliotecas para interação com a API etc. etc. - Os URLs estão quase literalmente em toda parte, não apenas na WWW. Provavelmente até no seu sistema de arquivos agora.
Cornelius

1

Use o formulário codificado em porcentagem . Alguns computadores (principalmente antigos) executando o Windows XP, por exemplo, não suportam Unicode, mas codificações ISO. Essa é a razão pela qual os URLs codificados em porcentagem foram inventados. Além disso, se você fornecer um URL impresso em papel a um usuário, contendo caracteres que não podem ser digitados com facilidade, esse usuário poderá ter dificuldade em digitá-lo (ou simplesmente ignorá-lo). A forma codificada em porcentagem pode até ser usada em muitas das máquinas mais antigas que já existiram (embora elas não suportem a Internet, é claro).

Há uma desvantagem, pois os caracteres codificados em porcentagem são mais longos que os originais, resultando possivelmente em URLs muito longos. Mas tente ignorá-lo ou use um encurtador de URL (eu recomendaria o goo.gl nesse caso, que cria um URL com 13 caracteres). Além disso, se você não deseja se registrar em uma conta do Google, tente bit.ly (o bit.ly cria URLs um pouco mais longos, com 14 caracteres).


Por que eu gostaria de oferecer suporte a computadores obsoletos que ainda usam o Windows XP?
Mateus Felipe

0

Para mim, esta é a maneira correta, isso só funcionou:

    $linker = rawurldecode("$link");
    <a href="<?php echo $link;?>"   target="_blank"><?php echo $linker ;?></a>

Isso funcionou e agora os links são exibidos corretamente:

http://newspaper.annahar.com/article/121638 -معرض - جوزف-حرب-في-غاليري-جانين-ربيز-لوحاته-الجدية-تبحث-وتكتشف-وتفرض-الاحترام

Link encontrado em:

http://www.galeriejaninerubeiz.com/newsite/news


2
"os links são exibidos corretamente" - exceto que o analisador de descontos StackOverflow não interpreta os URLs como pretendido!
MrWhite
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.