Quelle est la différence entre L'EscapeUriString et EscapeDataString?

Je n'ai pas trouvé les réponses existantes satisfaisantes donc j'ai décidé de creuser un peu plus pour régler cette question. Étonnamment, la réponse est très simple:

il n'y a aucune raison valable d'utiliser Uri.EscapeUriString . Si vous avez besoin de cent-encoder une chaîne de caractères, Utilisez toujours Uri.EscapeDataString .

pourquoi? Selon la documentation :

utilisez la Méthode d'enregistrement d'échappement pour préparer une chaîne D'URI non escapade pour être un paramètre pour le constructeur D'Uri.

cela n'a pas vraiment de sens. Selon RFC 2396 :

UN URI est toujours dans un "échappé", comme s'en échapper ou unescaping rempli URI peut changer sa sémantique.

alors que la RFC Citée a été obsolète par RFC 3986 , le point, est encore debout. Vérifions - le en regardant quelques exemples concrets:

1. vous avez un URI simple, comme ceci:

   http://example.org/
   

   Uri.EscapeUriString ne changera pas.

2. vous décidez d'éditer manuellement la chaîne de requête sans tenir compte pour échapper:

   http://example.org/?key=two words
   

   Uri.EscapeUriString va (correctement) échapper à l'espace pour vous:

   http://example.org/?key=two%20words
   

3. vous décidez d'éditer manuellement la chaîne de requête encore plus loin:

   http://example.org/?parameter=father&son
   

   cependant, cette chaîne n'est pas changée par Uri.EscapeUriString , car elle suppose que l'ampli signifie le début d'une autre paire de clés. Cela peut ou peut ne pas être ce que vous souhaitiez.

4. vous décidez que vous voulez en fait que le paramètre key soit father&son , donc vous fixez L'URL précédente en échappant manuellement à l'ampli:

   http://example.org/?parameter=father%26son
   

   cependant, Uri.EscapeUriString échappera aussi au caractère de pourcentage, conduisant à un double encodage:

   http://example.org/?parameter=father%2526son
   

comme vous pouvez le voir, l'utilisation de Uri.EscapeUriString pour son but prévu rend impossible l'utilisation de & comme partie d'une clé ou d'une valeur dans une chaîne de requête au lieu d'un séparateur entre plusieurs paires de valeurs de clés.

C'est parce que, dans une tentative malavisée de le rendre apte à échapper à la pleine URIs, il ignore les caractères réservés et échappe seulement les caractères qui ne sont ni réservés ni sans réserve, ce qui, BTW, est contraire à la documentation . De cette façon, vous ne finissent pas avec quelque chose comme http%3A%2F%2Fexample.org%2F , mais vous vous retrouvez avec les questions présentées ci-dessus.

à la fin, si votre URI est valide, il n'a pas besoin d'être échappé passer comme paramètre à L'URI construtor, et s'il n'est pas valide alors appeler Uri.EscapeUriString n'est pas une solution magique non plus. En fait, il fonctionne dans beaucoup de gens, sinon la plupart des cas, mais il n'est pas fiable.

vous devriez toujours construire vos URLs et chaînes de requête en recueillant les paires de valeurs de clé et le pourcentage-encodage et en les concaténant ensuite avec les séparateurs nécessaires. Vous pouvez utiliser Uri.EscapeDataString à cette fin, mais pas Uri.EscapeUriString , car il ne échapper les caractères réservés, comme mentionné ci-dessus.

les caractères plus (+) peuvent révéler beaucoup sur la différence entre ces méthodes. Dans un URI simple, le caractère plus signifie "espace". Pensez à Google pour "happy cat":

https://www.google.com/?q=happy+chat

C'est un URI valide (essayez-le), et EscapeUriString ne le modifiera pas.

considérez maintenant Google pour " happy c++":

https://www.google.com/?q=happy+c++

C'est un URI valide (essayez-le), mais il produit une recherche pour" happy c", parce que les deux plus sont interprétés comme des espaces. Pour le réparer, on peut passer "happy C++" à EscapeDataString et voilà ^* :

https://www.google.com/?q=happy+c % 2B%2B

^*) la chaîne de données encodée est en fait "happy%20c%2B %2B"; %20 est hex pour le caractère d'espace, et % 2B est hex pour le caractère plus.

si vous utilisez UriBuilder comme vous devriez l'être, alors vous n'aurez besoin de EscapeDataString que pour échapper correctement à certains composants de votre URI. @Livven, la réponse à cette question prouve qu'il n'y a vraiment aucune raison d'utiliser EscapeUriString .

commentaires dans le source traiter la différence clairement. Pourquoi cette information n'est pas transmise via les commentaires de la documentation XML est un mystère pour moi.

EscapeUriString:

cette méthode échappera à tout caractère qui n'est pas réservé ou caractère sans réserve, y compris les signes de pourcentage. Notez que EscapeUriString permettra également de ne pas échapper un signe#.

EscapeDataString:

cette méthode échappera à tout caractère qui n'est pas caractère, y compris les signes de pourcentage.

donc la différence est dans la façon dont ils traitent réservé caractères. EscapeDataString les échappe; EscapeUriString ne les échappe pas.

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

par souci d'exhaustivité, les caractères non réservés sont alphanumériques et -._~

les deux méthodes échappent aux caractères qui ne sont ni réservés ni sans réserve.

je suis en désaccord avec le général notion que EscapeUriString est le mal. Je pense une méthode qui échappe seulement illégal caractères (tels que les espaces) et non "1519300920 réservé Les caractères sont utiles. Mais il a une bizarrerie dans la façon dont il gère le caractère % . Les caractères codés en pourcentage ( % suivi de 2 chiffres hexadécimaux) sont legal dans une URI. Je pense que EscapeUriString serait beaucoup plus utile s'il détectait Ce modèle et évitait d'encoder % quand il est immédiatement procédé par 2 chiffres hexadécimaux.

un exemple simple

var data = "example.com/abc?DEF=あいう\x20えお";

Console.WriteLine(Uri.EscapeUriString(data));
Console.WriteLine(Uri.EscapeDataString(data));
Console.WriteLine(System.Net.WebUtility.UrlEncode(data));
Console.WriteLine(System.Web.HttpUtility.UrlEncode(data));

/*
=>
example.com/abc?DEF=%E3%81%82%E3%81%84%E3%81%86%20%E3%81%88%E3%81%8A
example.com%2Fabc%3FDEF%3D%E3%81%82%E3%81%84%E3%81%86%20%E3%81%88%E3%81%8A
example.com%2Fabc%3FDEF%3D%E3%81%82%E3%81%84%E3%81%86+%E3%81%88%E3%81%8A
example.com%2fabc%3fDEF%3d%e3%81%82%e3%81%84%e3%81%86+%e3%81%88%e3%81%8a
*/