web-dev-qa-db-fra.com

Server.UrlEncode vs. HttpUtility.UrlEncode

Existe-t-il une différence entre Server.UrlEncode et HttpUtility.UrlEncode?

asp.net.neturlencode
171
Manu

HttpServerUtility.UrlEncode utilisera HttpUtility.UrlEncode en interne. Il n'y a pas de différence spécifique. La raison d'être de Server.UrlEncode est compatible avec ASP classique.

131
Mehrdad Afshari

J'ai eu des maux de tête importants avec ces méthodes auparavant, Je vous recommande éviter toute variante de UrlEncode, et utiliser plutôt Uri.EscapeDataString - au moins celui-là 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 favori personnel doit être HttpUtility.UrlPathEncode - cette chose est vraiment incompréhensible. Il code:

  • "" ==> "% 20"
  • "100% true" ==> "100 %% 20true" (ok, votre URL est cassée maintenant)
  • "test A.aspx # ancre B" ==> "test% 20A.aspx# ancre% 20B"
  • "test A.aspx? hmm # ancre B" ==> "test% 20A.aspx? hmm#ancheur B"( notez la différence avec la séquence d'échappement précédente !)

Il contient également la documentation MSDN très spécifique "Encode la partie chemin d'une chaîne d'URL pour une transmission HTTP fiable du serveur Web à un client". - sans réellement expliquer ce que ça fait. Vous êtes moins susceptible de vous tirer une balle dans le pied avec un Uzi ...

En résumé, tenez-vous-en à ri.EscapeDataString.

253
Eamon Nerbonne

Près de 9 ans se sont écoulés depuis que cela a été demandé, et dans le monde de .NET Core et .NET Standard, il semble que les options les plus courantes 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? J'ai fait quelques analyses pour comprendre les différences et voici ce que j'ai trouvé:

Pour les besoins du codage d’URL, les caractères entrent dans l’une des trois catégories suivantes: non réservé (légal dans une URL); reserved (légal dans mais a une signification spéciale, donc vous pourriez-vous voulez l'encoder); et tout le reste (doit toujours être encodé).

Selon le RFC , les caractères réservés sont: :/?#[]@!$&'()*+,;=

Et les caractères non réservés sont alphanumériques et -._~

Le verdict

Uri.EscapeDataString définit clairement sa mission:% -encode tous les caractères réservés et illégaux. WebUtility.UrlEncode est plus ambigu en définition et en implémentation. Bizarrement, il code certains caractères réservés mais pas d’autres (pourquoi des parenthèses et non des crochets?), Et plus étrange encore, il code ce caractère ~ Innocentement non réservé.

Par conséquent, je suis d'accord avec le conseil populaire - utilisez Uri.EscapeDataString lorsque cela est possible et comprenez que des caractères réservés, tels que / Et ? Sera encodé. Si vous devez gérer des chaînes potentiellement volumineuses, en particulier du contenu de formulaire codé en URL, vous devez soit vous replier sur WebUtility.UrlEncode , puis accepter. ses bizarreries, ou autrement contourner le problème.

EDIT: J'ai tenté de rectifier TOUTES les bizarreries mentionnées ci-dessus dans Flurl via le Url.Encode, Url.EncodeIllegalCharacters Et Url.Decode Méthodes statiques. Celles-ci se trouvent dans le paquet 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 me réjouis de vos commentaires/réactions sur ceux-ci.

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}");
44
Todd Menier

N'oubliez pas que vous ne devriez probablement pas utiliser l'une ou l'autre de ces méthodes. La bibliothèque de scripts Anti-Cross Site Scripting Library de Microsoft inclut des remplacements pour HttpUtility.UrlEncode et HttpUtility.HtmlEncode qui sont à la fois plus conformes aux normes et plus sûrs. En bonus, vous obtenez également une méthode JavaScriptEncode.

26
Joel Mueller

Server.UrlEncode () est là pour fournir une compatibilité ascendante avec Classic ASP,

Server.UrlEncode(str);

Est équivalent à:

HttpUtility.UrlEncode(str, Response.ContentEncoding);
10
CMS

Le même, Server.UrlEncode() appelle HttpUtility.UrlEncode()

4
andleer