A maioria das respostas existentes aqui é impraticável porque ignora totalmente o uso no mundo real de endereços como:
Primeiro, uma digressão na terminologia. Quais são esses endereços? Eles são URLs válidos?
Historicamente, a resposta foi "não". De acordo com a RFC 3986 , a partir de 2005, esses endereços não são URIs (e, portanto, não são URLs, pois os URLs são um tipo de URIs ). De acordo com a terminologia dos padrões IETF de 2005, devemos chamá-los adequadamente de IRIs (Internationalized Resource Identifiers), conforme definido na RFC 3987 , que tecnicamente não são URIs, mas podem ser convertidos em URIs simplesmente codificando por cento todos os caracteres não ASCII do IRI. .
Por especificação moderna, a resposta é "sim". O padrão de vida do WHATWG simplesmente classifica tudo o que anteriormente seria chamado de "URIs" ou "IRIs" como "URLs". Isso alinha a terminologia especificada com a forma como as pessoas normais que não leram a especificação usam a palavra "URL", que era um dos objetivos da especificação .
Quais caracteres são permitidos sob o Padrão de Vida WHATWG?
De acordo com esse novo significado de "URL", quais caracteres são permitidos? Em muitas partes do URL, como a string e o caminho da consulta, podemos usar "unidades de URL" arbitrárias , que são
Pontos de código de URL e bytes codificados em porcentagem .
O que são "pontos de código de URL"?
Os pontos de código da URL são ASCII alfanuméricos, U + 0021 (!), U + 0024 ($), U + 0026 (&), U + 0027 ('), U + 0028 PARENTHESIS ESQUERDO, U + 0029 PARENTHESIS DIREITO, U + 002A (*), U + 002B (+), U + 002C (,), U + 002D (-), U + 002E (.), U + 002F (/), U + 003A (:), U + 003B (;), U + 003D (=), U + 003F (?), U + 0040 (@), U + 005F (_), U + 007E (~) e pontos de código no intervalo U + 00A0 a U + 10FFFD, inclusive, excluindo substitutos e não caracteres.
(Observe que a lista de "pontos de código de URL" não inclui %, mas isso %é permitido em "unidades de código de URL" se fizer parte de uma sequência de codificação percentual.)
O único lugar em que posso identificar onde as especificações permitem o uso de qualquer caractere que não esteja neste conjunto é no host , onde os endereços IPv6 estão entre caracteres [e ]caracteres. Em qualquer outro lugar da URL, unidades de URL são permitidas ou algum conjunto de caracteres ainda mais restritivo.
Quais caracteres foram permitidos sob as antigas RFCs?
Por uma questão de história, e como ela não foi explorada completamente em outras partes das respostas aqui, vamos examinar o que foi permitido no par de especificações mais antigo.
Primeiro de tudo, temos dois tipos de caracteres reservados para RFC 3986 :
:/?#[]@, que fazem parte da sintaxe genérica para um URI definido no RFC 3986!$&'()*+,;=, que não fazem parte da sintaxe genérica da RFC, mas são reservados para uso como componentes sintáticos de determinados esquemas de URI. Por exemplo, ponto e vírgula e vírgulas são utilizados como parte da sintaxe dos URIs de dados , e &e =são utilizadas como parte do ubíquo ?foo=bar&qux=bazformato em cadeias de consulta (que não é especificado por RFC 3986).
Qualquer um dos caracteres reservados acima pode ser legalmente usado em um URI sem codificação, para servir ao seu propósito sintático ou apenas como caracteres literais nos dados em alguns lugares onde esse uso não pode ser mal interpretado como o personagem que serve ao seu propósito sintático. (Por exemplo, embora /tenha significado sintático em uma URL, você pode usá-lo não codificado em uma sequência de consultas, porque não possui significado em uma sequência de consultas.)
O RFC 3986 também especifica alguns caracteres não reservados , que sempre podem ser usados simplesmente para representar dados sem nenhuma codificação:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._~
Finalmente, o %próprio personagem é permitido para codificações percentuais.
Isso deixa apenas os seguintes caracteres ASCII que são proibidos de aparecer em um URL:
- Os caracteres de controle (caracteres 0-1F e 7F), incluindo nova linha, tabulação e retorno de carro.
"<>\^`{|}
Todos os outros caracteres do ASCII podem legalmente aparecer em um URL.
Em seguida, o RFC 3987 estende esse conjunto de caracteres não reservados com os seguintes intervalos de caracteres unicode:
%xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD
Essas opções de bloco das especificações antigas parecem bizarras e arbitrárias, dadas as mais recentes definições de bloco Unicode ; isso provavelmente ocorre porque os blocos foram adicionados na década desde que o RFC 3987 foi gravado.
Por fim, talvez seja interessante notar que simplesmente saber quais caracteres podem aparecer legalmente em um URL não é suficiente para reconhecer se uma determinada string é um URL legal ou não, pois alguns caracteres são válidos apenas em partes específicas do URL. Por exemplo, os caracteres reservados [e ]são legais como parte de um host literal IPv6 em um URL como http: // [1080 :: 8: 800: 200C: 417A] / foo, mas não são legais em nenhum outro contexto, portanto, o O exemplo do OP http://example.com/file[/].htmlé ilegal.