. UrlEncode .NET non funziona?

Question

Secondo http://www.w3schools.com/tags/ref_urlencode.asp Quando le richieste vengono inoltrate, sono codificate come URL, quindi ad esempio lo spazio viene trasformato in% 20. Fin qui tutto bene.

Ho un problema con!. Inviandolo nel modulo lo converte in% 21 come dovrebbe. Tuttavia (o il suo partner WebUtility) o Uri.EscapeDataString torneranno tutti! Si tratta di un comportamento previsto? Come dovrei codificare il mio input da C# in modo da convertirlo in valori corretti?

Answer 1

Un punto esclamativo è considerato un carattere ASCII sicuro URL e quindi non codificato in percentuale.

Da MSDN

Il metodo UrlEncode URL-codifica qualsiasi carattere che non è nel set di caratteri ASCII che è considerato per essere sicuro per le URL. Gli spazi sono codificati come caratteri ASCII "+". I caratteri ASCII sicuri per URL includono i caratteri ASCI (dalla A alla Z e dalla a alla z), i numeri (da 0 a 9) e alcuni segni di punteggiatura . Nella tabella seguente sono elencati i segni di punteggiatura considerati caratteri ASCII sicuri per URL.

La tabella contiene - _ . ! * ()

Aggiornamento

Secondo this answer, Uri.EscapeDataString dovrebbe codificare il ! quando rivolte NET 4.5 progetti, ma io sono in grado di provarlo sulla mia macchina corrente. EscapeDataString sui precedenti framework .NET non codifica in percentuale i caratteri sopra. Potrebbe essere semplicemente necessario utilizzare String.Replace e sostituire i caratteri sopra dall'URI sfuggito.

Answer 2

Quindi abbiamo alcuni caratteri che si trovano nella zona "grigia" e possono essere ma non devono essere codificati.

Tutti i caratteri possono essere codificati. http://stackoverflow.com/questions e http://stackoverflow.com/%71%75%65%73%74%69%6F%6E%73 sono entrambi identici.

L'unica volta che un carattere non può essere codificato, è se viene utilizzato in un modo che ha un significato speciale con gli URI, come ad esempio gli elementi del percorso di separazione /.

L'unica volta che un carattere deve essere codificato, se:

1. È uno di quei caratteri speciali-significato, e non viene utilizzato con quel significato speciale.
2. È uno dei caratteri riservati che può avere un significato speciale in uno schema URI particolare o in un luogo particolare.
3. Ha un punto di codice su U + 007F.

Tuttavia, ci sono delle eccezioni agli ultimi due.

Nel terzo caso se si utilizza un IRI quindi non codificare tali caratteri, che è praticamente la definizione di un IRI. È possibile convertire tra IRI e URI eseguendo o annullando tale codifica. (Qualsiasi carattere di questo tipo nella parte host deve essere codificato in modo punycode, non codificato con URI).

Nel secondo caso è sicuro non codificare il carattere se non viene utilizzato come delimitatore nel contesto in questione. Ad esempio, & può essere lasciato come in alcuni URI ma non in URI HTTP in cui viene spesso utilizzato come separatore per i dati della query. Questo però dipende dalla conoscenza particolare del particolare schema URI. Probabilmente anche non vale la pena rischiare che qualche altro processo non si renda conto che va bene.

! è un esempio di questo. RFC 3986 comprende la produzione:

reserved = gen-delims/sub-delims 

gen-delims = ":"/"/"/"?"/"#"/"["/"]"/"@" 

sub-delims = "!"/"$"/"&"/"'"/"("/")" 
      /"*"/"+"/","/";"/"=" 

E così ! è nel set di caratteri che possono essere sicuro di lasciare non codificata o meno, a seconda dello schema in uso.

In generale, se si sta scrivendo il proprio codice di codifica (come ad esempio durante la scrittura di un'implementazione HttpEncoder) probabilmente stai meglio solo sempre la codifica !, ma se si sta utilizzando un encoder che non codifica ! tutto il tempo che probabilmente va bene anche a me; certamente negli URI HTTP non dovrebbe fare alcuna differenza.