2013-11-15 64 views
5

Qualcosa di una strana domanda, ma vediamo che tipo di risposta si ottiene ...Uri.EscapeUriString con piazza bretelle

Se il codice una console app (VS 2013, .NET 4.5.1) ed eseguire questa linea di codice:

Uri.EscapeUriString("[")

ottengo questo:

[

Tuttavia, se eseguo la stessa cosa (Beh, tecnicamente Uri.EscapeUriString("[").Dump()) in LINQPad sulla mia macchina ottengo questo:

%5B

a complicare ulteriormente le cose, according to this postUri.EscapeUriString("[") dovrebbe infatti tornare %5B .Il post è stato scritto su 27/06/2012.

Sto pensando che forse LINQPad fa riferimento a una DLL meno recente di quella utilizzata da VS, ma ciò implicherebbe che EscapeUriString è stato modificato relativamente di recente, di cui non riesco a trovare alcun record. Qualcuno ha qualche idea su cosa potrebbe causare questo comportamento?

+0

WT? Riesco a riprodurre in 4.5.1! –

risposta

5

Variabile tra .Net 4 e .Net 4.5, che è possibile verificare reindirizzando la versione del framework a .Net 4 ed eseguendo il programma di test.

Net 4 -> uscite "% 5B" .net 4.5 (o successivo) -> uscite "["

Questo è menzionato qui: Application Compatibility in the .NET Framework 4.5

nella sezione di Uri.EscapeDataString , Uri.EscapeUriString, e Uri.UnescapeDataString, in cui si afferma che (con .Net 4.5):

L'elenco dei caratteri riservati e senza riserve ora supporta RFC 3986.

cambiamenti specifici:

Unreserved escaped characters are un-escaped. 
EscapeDataString escapes reserved characters based on RFC 3986. 
EscapeUriString does not escape reserved characters. 
UnescapeDataString does not throw an exception if it encounters an invalid escape sequence. 

In particolare, è il EscapeUriString non sfugge caratteri riservati che è significativo.

2

Il nuovo comportamento sembra essere quello corretto in base a RFC 2396. In linea 566 si afferma:

566. Other characters are excluded because gateways and other transport 
567. agents are known to sometimes modify such characters, or they are 
568. used as delimiters. 
569. 
570. unwise  = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" 

Nella documentazione Uri.EscapeUriString s' si afferma che

Per impostazione predefinita, il metodo EscapeUriString converte tutti i caratteri, ad eccezione RFC 2396 caratteri senza riserve, alla loro rappresentazione esadecimale

Quindi sembrerebbe che ci fosse un bug fino a .NET 4.0 che è stato corretto in 4.5.1

+0

errato. Fino a .NET 4.0, RFC 2396 è seguito correttamente. I caratteri che non sono sfuggiti sono elencati alla riga 469, non al 570. dot Net 4.5.1 segue effettivamente i caratteri elencati nella stessa sezione di RFC 3986, che sono diversi. –

Problemi correlati