c# - htaccess - Hacer cadenas URL amistosas(por ejemplo: convertir Montréal en Montreal)
url amigables php sin htaccess (7)
Estoy escribiendo una aplicación web que requiere URLs amigables, pero no estoy seguro de cómo tratar con caracteres ASCII que no sean de 7 bits. Tampoco quiero reemplazar caracteres acentuados con entidades codificadas en URL. ¿Hay algún método de C # que permita este tipo de conversión o realmente necesito diseñar cada caso que quiero manejar?
Este enlace podría ayudar: http://www.codeproject.com/KB/cs/UnicodeNormalization.aspx
private string LatinToAscii(string InString)
{
string newString = string.Empty, charString;
char ch;
int charsCopied;
for (int i = 0; i < InString.Length; i++)
{
charString = InString.Substring(i, 1);
charString = charString.Normalize(NormalizationForm.FormKD);
// If the character doesn''t decompose, leave it as-is
if (charString.Length == 1)
newString += charString;
else
{
charsCopied = 0;
for (int j = 0; j < charString.Length; j++)
{
ch = charString[j];
// If the char is 7-bit ASCII, add
if (ch < 128)
{
newString += ch;
charsCopied++;
}
}
/* If we''ve decomposed non-ASCII, give it back
* in its entirety, since we only mean to decompose
* Latin chars.
*/
if (charsCopied == 0)
newString += InString.Substring(i, 1);
}
}
return newString;
}
No sé cómo hacerlo en C #, pero las palabras mágicas que desea son "descomposición Unicode". Hay una forma estándar de descomponer caracteres compuestos como "é", y luego debería poder filtrar los que no son ASCII.
Editar: esto podría ser lo que estás buscando.
Ok, hay algunas buenas respuestas aquí. Esos métodos funcionarían. Sin embargo, tengo que cuestionar tu premisa básica. Supongo que estos valores que está discutiendo son básicamente parámetros de cadena de consulta, ¿sí? Esa es la razón más común para tener que filtrar los caracteres especiales.
Durante dos o tres años, utilicé un enfoque de codificación / descodificación de cadenas para pasar cosas como esta a través de la cadena de consulta. Siempre hubo problemas intermitentes, porque - maldición - hay tantos diferentes caracteres especiales posibles, y problemas en un navegador frente a otro, etc. Nuestros métodos no eran tan sofisticados como los que se describen aquí, pero aún así. En 2005, durante una reescritura de gran parte del sistema en el que estaba trabajando, decidimos pasar solo a los valores de id pasados a través de la cadena de consulta. Ese enfoque ha funcionado muy bien, y no puedo pensar en ningún inconveniente. Si tiene un back-end de base de datos, de todos modos ya tiene una identificación adjunta a prácticamente cada cadena. Si esto es para búsquedas o similares, siempre puede enviarlo por correo postal o puede usar una solución AJAX que no requiere que cargue otra página en primer lugar.
Esos métodos no serán los mejores para cada situación, no hay una solución mágica aquí más que en cualquier otro lado, pero este enfoque ha sido simple y muy funcional para mí y para mi equipo, así que creo que es algo para usted al menos a considerar.
Use UTF-8:
Los caracteres no ASCII primero deben codificarse de acuerdo con UTF-8 [STD63], y luego cada octeto de la secuencia UTF-8 correspondiente debe estar codificado en un porcentaje para representarse como caracteres URI. - RFC 3986
bueno, hay una manera fácil de hacerlo, creo que no hay muchos de estos caracteres, puedes reemplazarlos fácilmente utilizando el método Reemplazar () de la clase de cadena.
(copiar / pegar en el navegador, funciona?)
Hay algo similar en: enrutamiento de URL: manejo de espacios y caracteres ilegales al crear URL amigables
Sin embargo, no recomiendo la conversión automática. Algunas palabras pueden cambiar el significado al hacer este tipo de cambio. Puedes convertir una buena palabra en una palabra inapropiada.