Réponses:
HttpServerUtility.UrlEncode
utilisera en HttpUtility.UrlEncode
interne. Il n'y a pas de différence spécifique. La raison de l'existence de Server.UrlEncode
est la compatibilité avec l'ASP classique.
J'ai eu des maux de tête importants avec ces méthodes auparavant, je vous recommande d' éviter toute variante de UrlEncode
, et d'utiliser à la placeUri.EscapeDataString
- au moins celle-ci a un comportement compréhensible.
Voyons voir...
HttpUtility.UrlEncode(" ") == "+" //breaks ASP.NET when used in paths, non-
//standard, undocumented.
Uri.EscapeUriString("a?b=e") == "a?b=e" // makes sense, but rarely what you
// want, since you still need to
// escape special characters yourself
Mais mon préféré doit être HttpUtility.UrlPathEncode - cette chose est vraiment incompréhensible. Il encode:
Il contient également la documentation MSDN joliment spécifique «Encode la partie chemin d'une chaîne URL pour une transmission HTTP fiable du serveur Web à un client». - sans vraiment expliquer ce qu'il fait. Vous êtes moins susceptible de vous tirer une balle dans le pied avec un Uzi ...
En bref, respectez Uri.EscapeDataString .
?
et qui peut dire lesquels doivent être encodés et lesquels servent de séparateurs? Quant à l'espace: dans les deux cas, l'espace est dans le hachage, donc la présence ou l'absence d'un fragment de requête ne devrait pas avoir d'importance. Et enfin, il est inexcusable de corrompre un Uri comme dans le deuxième exemple contenant un%. La UrlPathEncode
méthode est simple et ne doit jamais être utilisée.
Avance rapide de près de 9 ans depuis que cela a été demandé pour la première fois, et dans le monde de .NET Core et .NET Standard, il semble que les options les plus courantes que nous ayons pour le codage d'URL soient WebUtility.UrlEncode (sous System.Net
) et Uri.EscapeDataString . À en juger par la réponse la plus populaire ici et ailleurs, Uri.EscapeDataString semble être préférable. Mais est-ce vrai? J'ai fait quelques analyses pour comprendre les différences et voici ce que j'ai trouvé:
WebUtility.UrlEncode
encode l'espace comme +
; Uri.EscapeDataString
l'encode comme %20
.Uri.EscapeDataString
cent-encode !
, (
, )
, et *
; WebUtility.UrlEncode
ne fait pas.WebUtility.UrlEncode
pourcent-encode ~
; Uri.EscapeDataString
ne fait pas.Uri.EscapeDataString
jette un UriFormatException
sur les chaînes de plus de 65 520 caractères; WebUtility.UrlEncode
ne fait pas. ( Un problème plus courant que vous ne le pensez, en particulier lorsqu'il s'agit de données de formulaire encodées en URL .)Uri.EscapeDataString
jette un UriFormatException
sur les personnages de substitution élevés ; WebUtility.UrlEncode
ne fait pas. (C'est une chose UTF-16, probablement beaucoup moins courante.)À des fins de codage d'URL, les caractères entrent dans l'une des 3 catégories suivantes: non réservés (légaux dans une URL); réservé (légal mais a une signification particulière, vous pouvez donc vouloir l'encoder); et tout le reste (doit toujours être encodé).
Selon la RFC , les caractères réservés sont::/?#[]@!$&'()*+,;=
Et les caractères non réservés sont alphanumériques et -._~
Uri.EscapeDataString définit clairement sa mission:% -encode tous les caractères réservés et illégaux. WebUtility.UrlEncode est plus ambigu à la fois dans sa définition et dans sa mise en œuvre. Curieusement, il encode certains caractères réservés mais pas d'autres (pourquoi des parenthèses et pas des crochets ??), et plus étrange encore, il encode ce caractère innocemment non réservé ~
.
Par conséquent, je suis d'accord avec le conseil populaire: utilisez Uri.EscapeDataString lorsque cela est possible et comprenez que les caractères réservés aiment /
et ?
seront encodés. Si vous devez gérer des chaînes potentiellement volumineuses, en particulier avec du contenu de formulaire encodé en URL, vous devrez soit vous rabattre sur WebUtility.UrlEncode et accepter ses bizarreries, soit contourner le problème.
EDIT: J'ai tenté de rectifier TOUTES les bizarreries mentionnées ci - dessus dans Flurl par les Url.Encode
, Url.EncodeIllegalCharacters
et les Url.Decode
méthodes statiques. Ceux-ci sont dans le package de base (qui est minuscule et n'inclut pas tous les éléments HTTP), ou n'hésitez pas à les extraire de la source. Je suis heureux de recevoir vos commentaires / commentaires à ce sujet.
Voici le code que j'ai utilisé pour découvrir quels caractères sont encodés différemment:
var diffs =
from i in Enumerable.Range(0, char.MaxValue + 1)
let c = (char)i
where !char.IsHighSurrogate(c)
let diff = new {
Original = c,
UrlEncode = WebUtility.UrlEncode(c.ToString()),
EscapeDataString = Uri.EscapeDataString(c.ToString()),
}
where diff.UrlEncode != diff.EscapeDataString
select diff;
foreach (var diff in diffs)
Console.WriteLine($"{diff.Original}\t{diff.UrlEncode}\t{diff.EscapeDataString}");
Gardez à l'esprit que vous ne devriez probablement pas utiliser l'une de ces méthodes. La bibliothèque de scripts anti-intersite de Microsoft comprend des remplacements pour HttpUtility.UrlEncode
et HttpUtility.HtmlEncode
qui sont à la fois plus conformes aux normes et plus sécurisés. En prime, vous bénéficiez également d'une JavaScriptEncode
méthode.