La mayoría de las respuestas existentes aquí no son prácticas porque ignoran totalmente el uso de direcciones en el mundo real como:
Primero, una digresión en la terminología. ¿Cuáles son estas direcciones? ¿Son URL válidas?
Históricamente, la respuesta fue "no". Según RFC 3986 , desde 2005, tales direcciones no son URI (y, por lo tanto, no son URL, ya que las URL son un tipo de URI ). Según la terminología de los estándares IETF de 2005, deberíamos llamarlos adecuadamente IRI (Identificadores de recursos internacionalizados), tal como se define en RFC 3987 , que técnicamente no son URI pero pueden convertirse a URI simplemente codificando todos los caracteres no ASCII en el IRI. .
Según las especificaciones modernas, la respuesta es "sí". El WHATWG Living Standard simplemente clasifica todo lo que anteriormente se llamaría "URI" o "IRI" como "URL". Esto alinea la terminología especificada con la forma en que las personas normales que no han leído la especificación usan la palabra "URL", que era uno de los objetivos de la especificación .
¿Qué caracteres están permitidos bajo el WHATWG Living Standard?
Según este nuevo significado de "URL", ¿qué caracteres están permitidos? En muchas partes de la URL, como la cadena de consulta y la ruta, podemos usar "unidades URL" arbitrarias , que son
Puntos de código URL y bytes codificados en porcentaje .
¿Qué son los "puntos de código URL"?
Los puntos del código URL son alfanuméricos ASCII, U + 0021 (!), U + 0024 ($), U + 0026 (&), U + 0027 ('), U + 0028 PARENTESIS IZQUIERDA, U + 0029 PARENTESIS DERECHA, 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 (~) y puntos de código en el rango U + 00A0 a U + 10FFFD, inclusive, excluyendo sustitutos y no personajes.
(Tenga en cuenta que la lista de "puntos de código URL" no incluye %, pero que %se permiten en "unidades de código URL" si son parte de una secuencia de codificación porcentual).
El único lugar que puedo detectar donde la especificación permite el uso de cualquier carácter que no esté en este conjunto es en el host , donde se incluyen las direcciones IPv6 [y los ]caracteres. En cualquier otro lugar de la URL, se permiten unidades de URL o algún conjunto de caracteres aún más restrictivo.
¿Qué caracteres fueron permitidos bajo los viejos RFC?
Por el bien de la historia, y dado que no se explora por completo en ninguna otra parte de las respuestas aquí, examinemos que estaba permitido bajo el par de especificaciones más antiguas.
En primer lugar, tenemos dos tipos de caracteres reservados RFC 3986 :
:/?#[]@, que forman parte de la sintaxis genérica para un URI definido en RFC 3986!$&'()*+,;=, que no forman parte de la sintaxis genérica de RFC, pero están reservadas para su uso como componentes sintácticos de esquemas de URI particulares. Por ejemplo, puntos y comas y comas se utilizan como parte de la sintaxis de URIs de datos , y &y =se utilizan como parte de la omnipresente ?foo=bar&qux=bazformato en cadenas de consulta (que no está especificado por el RFC 3986).
Cualquiera de los caracteres reservados arriba se puede usar legalmente en un URI sin codificación, ya sea para cumplir su propósito sintáctico o simplemente como caracteres literales en los datos en algunos lugares donde dicho uso no puede ser malinterpretado como el carácter que cumple su propósito sintáctico. (Por ejemplo, aunque /tiene un significado sintáctico en una URL, puede usarlo sin codificar en una cadena de consulta, porque no tiene significado en una cadena de consulta).
RFC 3986 también especifica algunos caracteres no reservados , que siempre se pueden usar simplemente para representar datos sin ninguna codificación:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._~
Finalmente, el %carácter en sí está permitido para codificaciones porcentuales.
Eso deja solo los siguientes caracteres ASCII que tienen prohibido aparecer en una URL:
- Los caracteres de control (caracteres 0-1F y 7F), incluyendo nueva línea, tabulación y retorno de carro.
"<>\^`{|}
Todos los demás caracteres de ASCII pueden aparecer legalmente en una URL.
Luego, RFC 3987 extiende ese conjunto de caracteres no reservados con los siguientes rangos 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
Estas opciones de bloque de la especificación anterior parecen extrañas y arbitrarias dadas las últimas definiciones de bloque Unicode ; Esto probablemente se deba a que los bloques se han agregado en la década desde que se escribió RFC 3987.
Finalmente, quizás valga la pena señalar que el simple hecho de saber qué caracteres pueden aparecer legalmente en una URL no es suficiente para reconocer si una cadena dada es una URL legal o no, ya que algunos caracteres solo son legales en determinadas partes de la URL. Por ejemplo, los caracteres reservados [y ]son legales como parte de un host literal IPv6 en una URL como http: // [1080 :: 8: 800: 200C: 417A] / foo pero no son legales en ningún otro contexto, por lo que El ejemplo de OP http://example.com/file[/].htmles ilegal.