J'écris une application web qui nécessite des URL conviviales, mais je ne suis pas sûr de savoir comment gérer les caractères ASCII autres que 7 bits. Je ne veux pas non plus remplacer les caractères accentués par des entités codées en URL. Y at-il une méthode C# qui permet ce type de conversion ou dois-je cartographier chaque cas que je veux traiter?Faire des chaînes URL Friendly (par exemple: convertir Montréal en Montréal)
Je ne sais pas comment le faire en C#, mais les mots magiques que vous voulez sont "Décomposition Unicode". Il existe un moyen standard de décomposer les caractères composés comme "é", et vous devriez pouvoir filtrer les caractères non-ASCII.
Modifier: this peut être ce que vous cherchez.
il y a un facile pourquoi je pense, il n'y a pas beaucoup de ces caractères, vous pouvez remplacer ceux de la chaîne très facile en utilisant la méthode Replace() de la classe de chaîne.
Il y a quelque chose de similaire sur: URL Routing: Handling Spaces and Illegal Characters When Creating Friendly URLs
Néanmoins, je ne recommande pas de conversion automatique. Certains mots peuvent changer de sens en faisant ce type de changement. Vous pouvez transformer un mot gentil en un mot inapproprié.
Merci pour le lien. Je n'ai rien trouvé dans mes recherches. –
Ce lien pourrait aider: 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;
}
(copier/coller dans le navigateur, il fonctionne?)
Les caractères Unicode du nom de domaine fonctionnent différemment des chemins/parties de requête, ils sont codés en utilisant les règles "punycode" de l'IDN. – bobince
Utilisez UTF-8:
Non Les caractères ASCII doivent d'abord être codés selon UTF-8 [STD63], puis chaque octet de la séquence UTF-8 correspondante doit être codé en pourcentage pour être représenté en tant que caractères URI. - RFC 3986
+1. Il est parfaitement possible d'avoir des caractères non-ASCII dans les parties du chemin; vous encodez en hexadécimal leurs octets UTF-8 et le navigateur affiche la version Unicode dans la barre d'adresse. Voir Wikipedia pour quelque part cela fonctionne bien. – bobince
Même si sa deuxième phrase était "Je ne veux pas remplacer les caractères accentués par des URL codées", vous lui dites de faire quelque chose qui "doit être codé en pourcentage pour être représenté comme URI"? Ce que nous avons ici est un échec à communiquer. – Ken
Je pense qu'il suppose que ces mots endodés sont affichés comme '% xx' et non les caractères qu'il représente. Mais ce n'est que le cas où les mots ne sont pas codés en UTF-8. – Gumbo
Ok - il y a quelques bonnes réponses ici. Ces méthodes fonctionneraient. Cependant, je dois remettre en question votre prémisse de base. Je présume que ces valeurs dont vous parlez sont fondamentalement des paramètres de querystring, oui? C'est la raison la plus courante d'avoir à filtrer les caractères spéciaux.
Pendant deux ou trois ans, j'ai utilisé une approche de codage/décodage de chaîne pour transmettre ce genre de choses par le biais de la chaîne query. Il y avait toujours des problèmes intermittents, parce que - tout simplement - il y a tellement de différents caractères spéciaux possibles, et des problèmes dans un navigateur par rapport à un autre, etc. Nos méthodes n'étaient pas aussi sophistiquées que celles décrites ici, mais quand même. En 2005, lors d'une réécriture d'une grande partie du système sur lequel je travaillais, nous avons décidé de passer à seulement des valeurs d'identification qui passaient par la chaîne de requête. Cette approche a très bien fonctionné et je ne vois aucun inconvénient à cela. Si vous avez un back-end de base de données, vous avez déjà un ID attaché à pratiquement toutes les chaînes, de toute façon. Si c'est pour des recherches ou autres, vous pouvez toujours l'envoyer via un formulaire - ou vous pouvez utiliser une solution AJAX qui ne nécessite pas de charger une autre page en premier lieu. Ces méthodes ne vont pas être les meilleures pour chaque situation - il n'y a pas de solution miracle ici plus que partout ailleurs - mais cette approche a été simple et très fonctionnelle pour moi et mon équipe, et donc je pense que c'est quelque chose que tu peux au moins considérer.
Ils ne seront pas des variables querystring. Je vais faire des URLs du formulaire: http:/server/name/of-montreal et je veux que cette balise url "of-montreal" soit automatiquement générée par la valeur "Of Montréal". Dans les cas où les choses sont mal traduites, il y aura toujours une commande manuelle. –
Ensuite, vous êtes vraiment sur la bonne voie avec les suggestions des autres. Il semble que vous serez capable de les générer une seule fois et de les stocker ensuite dans une base de données, ce qui est encore mieux - avoir à encoder/décoder en temps réel est moins efficace. – x4000
Je vois de l'URL de cette question qui est c'est quelque chose que les concepteurs StackOverflow ne vous embêtez pas avec :) lol –
patrick, en effet, nous pouvons voir cela ne les retient :) – eglasius