Server.UrlEncode vs. HttpUtility.UrlEncode

StackOverflow https://stackoverflow.com/questions/602642

  •  03-07-2019
  •  | 
  •  

Domanda

C'è una differenza tra Server.UrlEncode e HttpUtility.UrlEncode?

È stato utile?

Soluzione

HttpServerUtility.UrlEncode utilizzerà HttpUtility.UrlEncode internamente. Non c'è alcuna differenza specifica. Il motivo dell'esistenza di Server.UrlEncode è la compatibilità con ASP classico

Altri suggerimenti

Ho avuto grossi mal di testa con questi metodi prima, ti consiglio di evitare qualsiasi variante di UrlEncode , e invece di usare Uri.EscapeDataString - almeno quello ha un comportamento comprensibile.

Vediamo ... 

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

Ma il mio preferito personale deve essere HttpUtility.UrlPathEncode - questa cosa è davvero incomprensibile. Codifica:

  • " & Quot; == > & Quot;% 20 "
  • " 100% vero " == > & Quot; 100 %% 20true " (ok, il tuo URL è rotto adesso)
  • " test A.aspx # anchor B " == > & Quot; Test% 20A.aspx # ancora% 20B "
  • "prova A.aspx? hmm # anchor B" == > "test% 20A.aspx? hmm #anchor B " ( nota la differenza con la precedente sequenza di escape! )

Ha anche la documentazione MSDN piacevolmente specifica "Codifica la parte del percorso di una stringa URL per una trasmissione HTTP affidabile dal server Web a un client." - senza realmente spiegare cosa fa. È meno probabile che ti spari al piede con un Uzi ...

In breve, attenersi a Uri.EscapeDataString .

Avanzamento rapido di quasi 9 anni da quando è stato chiesto per la prima volta, e nel mondo di .NET Core e .NET Standard, sembra che le opzioni più comuni che abbiamo per la codifica URL siano WebUtility.UrlEncode (sotto System.Net ) e Uri.EscapeDataString . A giudicare dalla risposta più popolare qui e altrove, Uri.EscapeDataString sembra essere preferibile. Ma è? Ho fatto alcune analisi per capire le differenze ed ecco cosa mi è venuto in mente:

Ai fini della codifica URL, i caratteri rientrano in una delle 3 categorie: senza prenotazione (legale in un URL); riservato (legale ma ha un significato speciale, quindi potresti voler codificarlo); e tutto il resto (deve essere sempre codificato).

Secondo RFC , i caratteri riservati sono: : ?! / # [] @ $ & amp; '() * +,; =

E i caratteri senza prenotazione sono alfanumerici e -._~

Il verdetto

Uri.EscapeDataString definisce chiaramente la sua missione:% -codifica tutti i personaggi riservati e illegali. WebUtility.UrlEncode è più ambiguo sia nella definizione che nell'implementazione. Stranamente, codifica alcuni caratteri riservati ma non altri (perché parentesi e non parentesi ??), e ancora più strano codifica quel carattere ~ innocentemente senza riserve.

Pertanto, concordo con il consiglio popolare: usa Uri.EscapeDataString quando possibile e comprendo che caratteri riservati come / e ? lo faranno codificato. Se hai bisogno di gestire stringhe potenzialmente grandi, in particolare con il contenuto del modulo con codifica URL, dovrai ricorrere a WebUtility.UrlEncode e accettarne le stranezze, o altrimenti risolvere il problema.

MODIFICA: ho tentato di rettificare TUTTO delle stranezze menzionate sopra in Flurl tramite Url.Encode , Url.EncodeIllegalCharacters e Url.Decode metodi statici. Questi sono nel pacchetto principale (che è piccolo e non include tutte le cose HTTP), o sentiti libero di strapparli dalla fonte. Sono lieto di ricevere qualsiasi commento / feedback in merito.

Ecco il codice che ho usato per scoprire quali caratteri sono codificati in modo diverso: 

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(<*>quot;{diff.Original}\t{diff.UrlEncode}\t{diff.EscapeDataString}");

Tieni presente che probabilmente non dovresti utilizzare nessuno di questi metodi. La Anti-Cross Site Scripting Library di Microsoft di Microsoft include sostituzioni per HttpUtility.UrlEncode e HttpUtility.HtmlEncode che sono entrambi più conformi agli standard e più sicuri. Come bonus, ottieni anche un metodo JavaScriptEncode .

Server.UrlEncode () è lì per fornire la retrocompatibilità con ASP classico, 

Server.UrlEncode(str);

È equivalente a: 

HttpUtility.UrlEncode(str, Response.ContentEncoding);

Lo stesso, Server.UrlEncode () chiama HttpUtility.UrlEncode()

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top