Solución:
Los siguientes caracteres tienen un significado especial en el componente de ruta de su URL (el componente de ruta es todo lo que está antes del ‘?’):
";" | "https://foroayuda.es/" | "?"
Además de estos, los siguientes caracteres tienen un significado especial en la parte de consulta de su URL (todo después de “?”). Por lo tanto, si van después del ‘?’ necesitas escapar de ellos:
":" | "@" | "&" | "=" | "+" | "$" | ","
Para obtener una explicación más detallada, consulte el RFC.
Los caracteres seguros son az, AZ, 0-9 y _ – (subrayado y menos), además de los caracteres reservados que se utilizan para los parámetros.
Otros personajes darán problemas hasta cierto punto. ejemplo: si un parámetro es una matriz ?param=array[content] es decir, mostrará una URL con la URL codificada entre corchetes, que se ve fea e imposible de dictar.
Pero el problema no solo es feo, digamos que tienes un jpg con un carácter al lado de los más seguros, muchas veces el navegador no podrá descargarlo obteniendo un 404. Este es un problema de los navegadores más antiguos y algunos navegadores móviles.
¿Cómo probar esto?
- ponga un montón de imágenes / js / css con los caracteres que desea probar en los nombres en una página pública con muchos visitantes
- Haga que la página 404 le envíe un correo electrónico cada vez que reciba una visita
Tengo una bandeja de entrada con 14000 correos electrónicos que prueban mi punto.
Esta pregunta apareció primero, por supuesto, cuando busqué en Google “caracteres seguros para URL”, como haría la mayoría de la gente. Creo que vale la pena dar una respuesta sencilla a una pregunta concisa. De la boca del caballo, uf, RFC2396, quiero decir, la boca de Sir Timothy:
2.3. Unreserved Characters Data characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include upper and lower case letters, decimal digits, and a limited set of punctuation marks and symbols. unreserved = alphanum | mark mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")" Unreserved characters can be escaped without changing the semantics of the URI, but this should not be done unless the URI is being used in a context that does not allow the unescaped character to appear.
Las “letras mayúsculas y minúsculas” en este contexto se entienden como se definen anteriormente en el apartado 1.6 de la misma norma:
The following definitions are common to many elements: alpha = lowalpha | upalpha lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" alphanum = alpha | digit
Entonces, la respuesta es que los caracteres seguros para URL son buenos caracteres latinos ASCII-7. A mediante Z en minúsculas y mayúsculas, dígitos decimales 0 mediante 9, y un puñado de caracteres no alfanuméricos enumerados explícitamente en el mark regla de producción de la gramática en la Sec. 2.3.
Si se quiere entender la pregunta sobre HTTP / HTTPS URL (tenga en cuenta que RFC2396 define la URI), los semántico tratamiento del RFC2396 sintaxis como localizadores de recursos para HTTP[S] El protocolo está actualmente estandarizado por RFC7230, Sec. 2.7. No obstante, inferir que el conjunto de caracteres “seguros para URL” es mayor que el definido por el RFC2396 a partir de la observación de que no se tratan especialmente en RFC7230 Sec. 2.7 no sería una medida a prueba de futuro; una posible actualización futura de RFC7230 puede atribuir semántica a más caracteres que están fuera del conjunto de RFC2396 “seguro para URL”, lo que representa tal inferencia ex statu quo inválido.
TL; DR, es el enfoque más seguro y a prueba de futuro para tratar el conjunto de caracteres seguros para URL definidos en RFC2396 como el más grande posible y no extensible, y no extenderlo con aquellos que son en la actualidad okay / seguro / no especial según RFC7230: esto puede cambiar. El conjunto RFC2396, por el contrario, no puede.