IIS effectue-t-il une substitution de caractère illégale? Si oui, comment l'arrêter?

Question

Contexte: ASP.NET MVC cours d'exécution dans IIS, avec un encodage UTF-8 %-URL encodée.

En utilisant le modèle de projet standard, et d'un test-l'action en HomeController comme:

public ActionResult Test(string id)
{
    return Content(id, "text/plain");
}

Cela fonctionne bien pour la plupart des %-encodé en UTF-8 voies, telles que:

http://mydevserver/Home/Test/%e4%ba%ac%e9%83%bd%e5%bc%81

avec le résultat attendu 京都弁

Cependant, l'utilisation de la route:

http://mydevserver/Home/Test/%ee%93%bb

l'url n'est pas reçu correctement.

De côté: %ee%93%bb est %codé de point de code 0xE4FB; base-multilingue-plan, privé de la zone d'utilisation; mais en fin de compte un code unicode-point; vous pouvez le vérifier manuellement, ou via:

string value = ((char) 0xE4FB).ToString();
string encoded = HttpUtility.UrlEncode(value); // %ee%93%bb

Maintenant, ce qui se passe ensuite dépend de la web-serveur; le Serveur de Développement Visual Studio (aka cassini), l'correcte id reçu: une chaîne de caractères de longueur, contenant le code-point 0xE4FB.

Si, toutefois, je le fais dans IIS ou IIS Express, je reçois un autre id, spécifiquement "î"»", code-points: 0xEE, 0x201C, 0xBB. Vous serez immédiatement reconnaître le premier et le dernier comme le début et la fin de notre pour cent-chaîne codée... donc ce qui est arrivé dans le milieu?

Bien:

• code-point 0x93 est - " (source)
• code-point 0x201c est - " (source)

Il me semble très bien comme IIS a effectué une sorte de devis de traduction lors du traitement de mon url. Maintenant peut-être que cela pourrait avoir utilise dans quelques scénarios (je ne sais pas), mais il est certainement une mauvaise chose quand il arrive dans le milieu d'un %-encodé en UTF-8 bloc.

Notez que HttpContext.Current.Request.Raw également montre cette traduction a eu lieu, de sorte que cela ne ressemble pas à un MVC bug; note également Darin commentaire, soulignant que cela fonctionne différemment dans le chemin vs requête de la partie de l'url.

Donc (en deux parties):

1. mon analyse est manquant important de la subtilité de l'unicode / url traitement?
2. comment puis-je résoudre ce problème? (c'est à dire faire en sorte que je devrait recevoir le caractère)

Answer 1

id = Encoding.UTF8.GetString(Encoding.Default.GetBytes(id));

Cela vous donnera votre identifiant d'origine. IIS utilise par Défaut (ANSI) codant pour des caractères de chemin d'accès. Votre url de chaîne codée est décodé à l'aide de qui, et c'est pourquoi vous obtenez une chose bizarre en arrière.

Pour obtenir l'identifiant d'origine, vous pouvez convertir des octets et obtenir l'aide de la chaîne de codage utf8.

Voir Unicode et des Filtres ISAPI

Filtre ISAPI est une API ANSI - toutes les valeurs que vous pouvez obtenir/définir à l'aide de l'API doit être la norme ANSI. Oui, je sais que c'est choquant; après tout, il est de 2006 et tout de nos jours sont en Unicode... mais n'oubliez pas que cette API origine de plus d'une décennie, quand à peine quelque chose a été 32bit, beaucoup moins Unicode. Aussi, rappelez-vous que le protocole HTTP qui ISAPI manipule directement est dans la norme ANSI et non Unicode.

EDIT: Puisque vous avez mentionné qu'il fonctionne avec la plupart des autres personnages, donc je suis en supposant que IIS a une sorte de mécanisme de détection de l'encodage qui est en défaut dans ce cas. Comme une solution de contournement si vous pouvez ajouter un préfixe de votre pièce d'identité avec ce char et puis vous pouvez facilement détecter si le problème est survenu (si ce char est manquant). Pas une solution idéale, mais il fonctionne. Vous pouvez ensuite écrire votre propre modèle de classeur et une classe wrapper dans ASP.NET MVC pour rendre votre code de la consommation propre.

Answer 2

Il était une fois, les URL elles-mêmes n'étaient pas dans UTF-8. Ils étaient dans la page de code ANSI. Cela facilite le fait qu'ils sont souvent utilisés pour sélectionner, ainsi, des chemins d'accès dans le système de fichiers du serveur. Dans les temps anciens, IE avait la possibilité d'indiquer si vous vouliez envoyer des URL UTF-8 ou non.

Peut-être enterrés dans les entrailles de la configuration IIS il y a un endroit pour spécifier le codage d'URL, et peut-être pas.

Answer 3

En fin de compte, pour contourner ce problème, je devais utiliser request.ServerVariables["HTTP_URL"] et quelques analyses manuelles, avec un tas de solutions de rechange pour la gestion des erreurs (compensant en outre certains problèmes liés en Uri ). Pas génial, mais ne concerne qu'une infime minorité de demandes maladroites.