url amigables
Caracteres seguros para URL amigable (13)
Necesito hacer un sitio web que tenga artículos, y me gustaría crear URL amigables para él, por ejemplo, la URL de la página con
Título: Prueba del artículo
debería convertirse en: http://www.example.com/articles/article_test
.
Por supuesto, necesito eliminar algunos caracteres del título como ?
o #
, pero no estoy seguro de cuáles eliminar.
¿Puede alguien decirme qué personajes son seguros de guardar?
Siempre seguro
Estos son seguros (en teoría / especificación), básicamente en cualquier lugar excepto el nombre de dominio.
Porcentaje: codifica todo lo que no figura en la lista, y ya está listo.
A-Z a-z 0-9 - . _ ~ ( ) '' ! * : @ , ;
A veces seguro
Solo es seguro cuando se usa dentro de componentes de URL específicos; usar con cuidado
Paths: + & =
Queries: ? /
Fragments: ? / # + & =
Nunca seguro
De acuerdo con la especificación de URI (RFC 3986), todos los demás caracteres deben estar codificados porcentualmente. Esto incluye:
<space> <control-characters> <extended-ascii> <unicode>
% < > [ ] { } | / ^
Si la compatibilidad máxima es una preocupación, limite el juego de caracteres a AZ az 0-9 - _.
(con períodos solo para extensiones de nombre de archivo).
Creo que está buscando algo como "codificación de URL", que codifica una URL para que sea "segura" de usar en la web:
Aquí hay una referencia para eso. Si no desea ningún carácter especial, simplemente elimine cualquiera que requiera codificación URL:
Desde una perspectiva SEO, los guiones son preferibles a los subrayados. Convierta a minúsculas, elimine todos los apóstrofos y luego reemplace todas las cadenas de caracteres no alfanuméricas con un solo guión. Recorte el exceso de guiones desde el principio y finalice.
El formato para un URI se define en RFC 3986 . Ver la sección 3.3 para más detalles.
En cuanto a RFC3986 - Uniform Resource Identifier (URI): Sintaxis genérica , su pregunta gira en torno al componente de ruta de un URI.
foo://example.com:8042/over/there?name=ferret#nose /_/ /______________//_________/ /_________/ /__/ | | | | | scheme authority path query fragment | _____________________|__ / / / / urn:example:animal:ferret:nose
Citando la sección 3.3, los caracteres válidos para un segment
URI son de tipo pchar
:
pchar = sin reservas / pct-encoded / sub-delims / ":" / "@"
Lo que se reduce a:
ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded
"!" / "$" / "&" / "''" / "(" / ")" / "*" / "+" / "," / ";" / "="
":" / "@"
O en otras palabras: puede usar cualquier carácter (no de control) de la tabla ASCII , excepto /
?
, #
, [
y ]
.
Esta comprensión está respaldada por RFC1738 - Localizadores de recursos uniformes (URL) .
Entre 3-50 caracteres. Puede contener letras minúsculas, números y caracteres especiales: punto (.), Guión (-), guión bajo (_) y al ritmo (@).
Hay dos conjuntos de caracteres que debes tener en cuenta: reservados e inseguros .
Los personajes reservados son:
- ampersand ("&")
- dólar ("$")
- signo más ("+")
- coma (",")
- barra inclinada ("/")
- colon (":")
- punto y coma (";")
- equals ("=")
- signo de interrogación ("?")
- Símbolo ''At'' ("@")
- libra ("#").
Los personajes generalmente considerados inseguros son:
- espacio (" ")
- menor que y mayor que ("<>")
- abrir y cerrar corchetes ("[]")
- abrir y cerrar llaves ("{}")
- tubería ("|")
- barra invertida ("/")
- caret ("^")
- por ciento ("%")
Pude haber olvidado uno o más, lo que me lleva a hacerme eco de la respuesta de Carl V. A largo plazo, es mejor que uses una "lista blanca" de caracteres permitidos y luego codifiques la cadena en lugar de tratar de mantenerte al tanto de los caracteres que los servidores y sistemas no permiten.
Lo mejor es mantener solo algunos caracteres (lista blanca) en lugar de eliminar ciertos caracteres (lista negra).
Puedes permitir técnicamente cualquier personaje, siempre que lo codifiques correctamente. Pero, para responder en el espíritu de la pregunta, solo debes permitir estos caracteres:
- Letras en minúsculas (convertir mayúsculas en minúsculas)
- Números, del 0 al 9
- Un guión - o guión bajo _
- Tilde ~
Todo lo demás tiene un significado potencialmente especial. Por ejemplo, puede pensar que puede usar +, pero puede reemplazarse con un espacio. y es peligroso también, especialmente si se usan algunas reglas de reescritura.
Al igual que con los otros comentarios, consulte los estándares y especificaciones para obtener detalles completos.
Me pareció muy útil codificar mi URL a una segura cuando estaba devolviendo un valor a través de ajax / php a una URL que luego fue leída por la página otra vez.
Salida de PHP con codificador de URL para el carácter especial y
//PHP returning the sucess info of ajax request
echo "".str_replace(''&'',''%26'',$_POST[''name''])." category was changed";
//javascript sending the value to url
window.location.href=''time.php?return=updated&val=''+msg;
//javascript/php executing the function printing the value of the url,
//now with the text normally lost in space because of the reserved & character.
setTimeout("infoApp(''updated'',''<?php echo $_GET[''val''];?>'');",360);
Espero que alguien encuentre útil mi pequeño código. :)
Para citar la sección 2.3 de RFC 3986 :
"Los caracteres que están permitidos en un URI pero no tienen un propósito reservado se llaman sin reserva. Estos incluyen letras mayúsculas y minúsculas, dígitos decimales, guiones, punto, guión bajo y tilde".
ALPHA DIGIT "-" / "." / "_" / "~"
Tenga en cuenta que RFC 3986 enumera menos signos de puntuación reservados que el anterior RFC 2396 .
Según el contexto que describes, sospecho que lo que en realidad estás tratando de hacer es algo que se llama ''babosa de SEO''. La mejor práctica conocida general para aquellos es:
- Convertir a minúsculas
- Convierta secuencias enteras de caracteres que no sean az y de 0-9 a un guión (-) (sin subrayar)
- Elimine "detener palabras" de la URL, es decir, palabras no indexables como ''a'', ''an'' y ''the''; Google ''stop words'' para listas extensas
Entonces, como un ejemplo, un artículo titulado "El uso de! @% $ * Para representar juramentos en los cómics" recibiría una babosa de "usage-represents-jure-comics".
Tuve un problema similar, quería tener URLs bonitas y llegué a la conclusión de que tenía que permitir solo letras, dígitos, y en las direcciones URL. Eso está bien, luego escribí algunas expresiones regulares agradables y me di cuenta de que reconoce que todos los caracteres UTF8 no son letras en .NET y que estaban jodidos. Esto parece ser un problema conocido para .NET Regex Engine. Así que llegué a esta solución:
private static string GetTitleForUrlDisplay(string title)
{
if (!string.IsNullOrEmpty(title))
{
return Regex.Replace(Regex.Replace(title, @"[^A-Za-z0-9_-]", new MatchEvaluator(CharacterTester)).Replace('' '', ''-'').TrimStart(''-'').TrimEnd(''-''), "[-]+", "-").ToLower();
}
return string.Empty;
}
/// <summary>
/// All characters that do not match the patter, will get to this method, i.e. useful for unicode chars, because
/// .NET impl of regext do not handle unicode chars. So we use char.IsLetterOrDigit() which works nicely and we
/// return what we approve and return - for everything else.
/// </summary>
/// <param name="m"></param>
/// <returns></returns>
private static string CharacterTester(Match m)
{
string x = m.ToString();
if (x.Length > 0 && char.IsLetterOrDigit(x[0]))
{
return x.ToLower();
}
else
{
return "-";
}
}
sin reserva = ALPHA / DIGIT / "-" / "." / "_" / "~"