route - Enrutamiento de URL: manejo de espacios y caracteres ilegales al crear URL amigables
route netcore (11)
He visto mucha discusión sobre enrutamiento de URL y MUCHAS grandes sugerencias ... pero en el mundo real, una cosa que no he visto es:
- Crear URLs amigables con espacios y caracteres ilegales
- Consultando el DB
Supongamos que está creando un sitio médico, que tiene artículos con una categoría y una subcategoría opcional. (1 a muchos). ( Podría haber usado cualquier ejemplo, pero el campo médico tiene muchas palabras largas )
Categorías de ejemplos / estructura de sub / artículo:
- Su salud general (categoría)
- Salud natural (Subcategoría)
- El sistema inmune de su cuerpo y por qué necesita ayuda. (Artículo)
- ¿Son las plantas y las hierbas realmente la solución?
- ¿Debo comer alimentos enriquecidos?
- Medicina Homeopática
- ¿Qué es la medicina homeopática?
- Alimentación saludable
- ¿Deberías tomar 10 tazas de café por día?
- Son las verduras orgánicas vale la pena?
- ¿Burger King® es malo?
- ¿El "café francés" o el café estadounidense es más saludable?
- Salud natural (Subcategoría)
- Enfermedades y condiciones (Categoría)
- Trastornos autoinmunes (Subcategoría)
- La causa # 1 de las personas es alguna enfermedad
- Cómo obtener ayuda
- Condiciones genéticas
- Previniendo espina bífida antes del embarazo.
- ¿Estás predispuesto a vivir mucho tiempo?
- Trastornos autoinmunes (Subcategoría)
- Sugerencias personales del Dr. FooBar (Categoría)
- Mis pensamientos sobre medicina herbaria y remedios naturales (Artículo - sin subcategoría)
- ¿Por qué deberías preocuparte por tu salud?
- Es posible comer bien y tener una buena dieta.
- ¿La cirugía sin sangre ha alcanzado la mayoría de edad?
En una estructura como esta, vas a tener algunas URL LOOONG si vas: / {Categoría} / {subcategoría} / {Título del artículo}
Además, hay numerosos personajes ilegales , como #! ? ''é'', etc.
ASÍ QUE, LA PREGUNTA (S) ES:
- ¿Cómo manejarías los personajes ilegales y los espacios? (¿Pros y contras?)
- ¿Podrías manejar esto desde la base de datos?
- En otras palabras, ¿ confiaría en que el DB encuentre el artículo, pase el título o extraiga todos los títulos y encuentre la clave en el código para que la clave pase a la base de datos (dos llamadas a la base de datos)?
nota: siempre veo bonitos ejemplos bonitos como / products / beverages / Short-Product-Name / cómo manejar algunos ejemplos feos ^ _ ^
Como un seguimiento. Tengo algunas ideas Así que siéntase libre de comentar las ideas o dar su propia respuesta a la pregunta:
Solución n. ° 1: reemplace todos los caracteres ilegales con guiones:
- www.mysite.com/diseases--conditions/Auto-immune-disorders/the--1-killer-of-people-is-some-disease/
Eso me parece un poco feo ...
Solución # 2: Eliminar caracteres ilegales y reemplazar espacios con guiones únicos:
- www.mysite.com/diseases-conditions/Auto-immune-disorders/the-1-killer-of-people-is-some-disease/
Solución # 3 Aplicar algunas reglas para reemplazar ciertos caracteres por palabras:
- www.mysite.com/diseases-and-conditions/Auto-immune-disorders/the-number1-killer-of-people-is-some-disease/
Solución # 4 Pele todos los espacios y use mayúsculas
- www.misitio.com/DiseasesAndConditions/AutoImmuneDisorders/TheNumber1KillerOfPeopleIsSomeDisease/
(Puede que no funcione bien en servidores sensibles a mayúsculas y minúsculas y es difícil de leer)
La solución 2 es el enfoque típico de aquellos ... algunos refinamientos son posibles, por ej. convirtiendo apóstrofes en nada en lugar de un guión, para facilitar la lectura. Normalmente querrá almacenar la versión del título en munged-for-URL para la base de datos, así como el título "real", para que pueda seleccionar el elemento utilizando un SELECT WHERE indexado.
Sin embargo. No hay un carácter ilegal real en una parte de la ruta de la URL, siempre que la codifique adecuadamente. Por ejemplo, un espacio, hash o slash se puede codificar como% 20,% 23 o% 2F. De esta manera, es posible codificar cualquier cadena en una parte de la URL, por lo que puede SELECCIONARla de nuevo fuera de la base de datos por título real, sin cambios.
Sin embargo, existen algunos problemas potenciales con esto dependiendo de su framework web. Por ejemplo, cualquier elemento basado en CGI no podrá distinguir entre un% 2F codificado y un real /, y algunos marcos / implementaciones pueden tener dificultades con los caracteres Unicode.
Alternativamente, una solución simple y segura es incluir la clave principal en la URL, utilizando las partes tituladas exclusivamente para hacer que la dirección sea más agradable. p.ej.:
http://www.example.com/x/category-name/subcat-name/article-name/348254863
Así es como, por ej. Amazon lo hace. Tiene la ventaja de que puede cambiar el título en la base de datos y hacer que la URL con el título anterior se redirija automáticamente a la nueva.
La solución 2 sería mi recomendación. No soy el experto en SEO más grande del mundo, pero de todos modos creo que es la forma "estándar" de obtener buenas clasificaciones.
Lo que hago normalmente es permitir solo el carácter legal y mantener la URL amigable lo más corta posible. También es importante que las URL amigables a menudo sean insertadas por personas, nunca genero una URL amigable de título o contenido, y luego la utilizo para consultar la base de datos. Utilizaría una columna en una tabla, por ejemplo, friendly_url, para que el administrador del sitio web pueda insertar URL amigables.
Mi último enfoque es:
- Convierta todas las "letras extrañas" a "letras normales" -> à a a, ñ a n, etc.
- Convierta todos los caracteres que no sean palabras a _ (es decir, no a-zA-Z0-9)
- reemplaza grupos de guiones bajos con un guion bajo
- eliminar todos los extremos y guiones bajos
En cuanto al almacenamiento, creo que la URL amigable debe ir a la base de datos y ser inmutable, después de que todos los URI geniales no cambien
Resolví este problema agregando una columna adicional en la base de datos (por ejemplo: UrlTitle junto a la columna Título) y guardando un título despojado de todos los caracteres ilegales con símbolos ''&'' reemplazados por ''y'', y espacios reemplazados por guiones bajos. Luego puede buscar a través del UrlTitle y usar el real en el título de la página o donde sea.
Sugiero hacer lo que WordPress hace: quitar las palabras pequeñas y responder a los caracteres ilegales con guiones (máximo 1 guión) y luego dejar que el usuario corrija la URL si así lo desean. Es mejor para SEO hacer la URL configurable.
Yo mismo prefiero - por razones de legibilidad (pones un subrayado y prácticamente te vas), si vas a quitar espacios.
Es posible que desee intentar convertir los caracteres extendidos, es decir, ü, en equivalentes cercanos cuando sea posible, es decir:
ü -> u
Sin embargo, en mi experiencia el mayor problema con los problemas relacionados con SEO real , no es que la URL contenga todo el texto encantador, es que cuando las personas cambian el texto en el enlace, todo su trabajo de SEO se convierte en basura porque ahora tiene ADJUDICACIONES EN EL índices
Para esto, sugeriría lo que hace , y tiene una parte numérica que hace referencia a una entidad constante, e ignora por completo el resto del texto (y / o lo actualiza cuando está equivocado)
Además, la naturaleza groseramente hericichista solo hace mala usabilidad por los humanos. Los humanos odian las urls largas. Copiar pegarlos es una mierda y son más propensos a romperse. Si puedes subdividirlo en teirs inferiores, es decir,
/article/1/Some_Article_Title_Here
/article/1/Section/5/Section_Title_Here
/section/19023/Section_Title_here ( == above link )
De esa manera, la única vez que necesitas hacer magia vudú es cuando el artículo numerado en realidad ha sido eliminado, momento en el que usas la parte del texto como cadena de búsqueda para intentar encontrar el artículo real o algo parecido.
Al limpiar las URL, aquí hay un método que estoy usando para reemplazar los caracteres acentuados:
private static string anglicized(this string urlpart) {
string before = "àÀâÂäÄáÁéÉèÈêÊëËìÌîÎïÏòÒôÔöÖùÙûÛüÜçÇ’ñ";
string after = "aAaAaAaAeEeEeEeEiIiIiIoOoOoOuUuUuUcC''n";
string cleaned = urlpart;
for (int i = 0; i < avantConversion.Length; i++ ) {
cleaned = Regex.Replace(urlpart, before[i].ToString(), after[i].ToString());
}
return cleaned;
// Here''s some for Spanish : ÁÉÍÑÓÚÜ¡¿áéíñóúü"
}
No sé si es la Regex más eficiente, pero sin duda es efectiva. Es un método de extensión, así que para llamarlo simplemente debes poner el método en una clase estática y hacer algo como esto:
string articleTitle = "My Article about café and the letters àâäá";
string cleaned = articleTitle.anglicized();
// replace spaces with dashes
cleaned = Regex.Replace( cleaned, "[^A-Za-z0-9- ]", "");
// strip all illegal characters like punctuation
cleaned = Regex.Replace( cleaned, " +", "-").ToLower();
// returns "my-article-about-cafe-and-the-letters-aaaa"
Por supuesto, puedes combinarlo en un método llamado "CleanUrl" o algo así, pero eso depende de ti.
En caso de que alguien esté interesado. Esta es la ruta (oooh ... punny) que estoy tomando:
Route r = new Route("{country}/{lang}/Article/{id}/{title}/", new NFRouteHandler("OneArticle"));
Route r2 = new Route("{country}/{lang}/Section/{id}-{subid}/{title}/", new NFRouteHandler("ArticlesInSubcategory"));
Route r3 = new Route("{country}/{lang}/Section/{id}/{title}/", new NFRouteHandler("ArticlesByCategory"));
Esto me ofrece la posibilidad de hacer URLs así:
- site.com/ca/en/Article/123/my-life-and-health
- site.com/ca/en/Section/12-3/Health-Issues
- site.com/ca/en/Section/12/
Como usuario de un cliente, no como diseñador web, encuentro que a veces Firefox rompe la URL cuando intenta reemplazar caracteres "ilegales" con caracteres utilizables. Por ejemplo, FF reemplaza ~ con% 7E. Eso nunca se carga para mí. No puedo entender por qué los editores y navegadores de HTML no aceptan simplemente aceptar caracteres distintos de AZ y 0-9. Si ciertos scripts necesitan%,?, Y tal, cambie las aplicaciones de scripting para que funcionen con alfanumérico.