Uno spazio html viene visualizzato come% 2520 anziché% 20


109

Il passaggio di un nome file al browser Firefox fa sì che sostituisca gli spazi con %2520 invece di %20.

Ho il seguente codice HTML in un file chiamato myhtml.html:

<img src="C:\Documents and Settings\screenshots\Image01.png"/>

Quando carico myhtml.htmlin Firefox, l'immagine si presenta come un'immagine interrotta. Quindi faccio clic con il pulsante destro del mouse sul collegamento per visualizzare l'immagine e mostra questo URL modificato:

file:///c:/Documents%2520and%2520Settings/screenshots/Image01.png
                    ^
                    ^-----Firefox changed my space to %2520.

Che diamine? Ha convertito il mio spazio in un file %2520. Non dovrebbe convertirlo in un %20?

Come posso modificare questo file HTML in modo che il browser possa trovare la mia immagine? Cosa sta succedendo qui?

Risposte:


219

Un po 'di spiegazioni su cosa %2520sia:

Il carattere dello spazio comune è codificato %20come hai notato tu stesso. Il %carattere è codificato come %25.

Il modo in cui ottieni %2520è quando il tuo URL ha già un %20in esso e viene nuovamente codificato, il che trasforma il file %20in %2520.

Sei (o un framework che potresti utilizzare) caratteri a doppia codifica?

Modifica: espansione un po 'su questo, in particolare per i link LOCALI . Supponendo che tu voglia collegarti alla risorsa C:\my path\my file.html:

  • se fornisci solo un percorso di file locale, il browser dovrebbe codificare e proteggere tutti i caratteri forniti (in precedenza, dovresti assegnarlo con spazi come mostrato, poiché %è un carattere di nome file valido e come tale verrà codificato) durante la conversione a un URL appropriato (vedere il punto successivo).
  • se fornisci un URL con il file://protocollo, in pratica stai affermando di aver preso tutte le precauzioni e di aver codificato ciò che necessita di codifica, il resto dovrebbe essere trattato come caratteri speciali. Nell'esempio sopra, dovresti quindi fornire file:///c:/my%20path/my%20file.html. Oltre a correggere le barre, i client non dovrebbero codificare i caratteri qui.

APPUNTI:

  • Direzione barra: le barre in avanti /vengono utilizzate negli URL, le barre inverse \nei percorsi di Windows, ma la maggior parte dei client funzionerà con entrambe convertendole nella barra in avanti corretta.
  • Inoltre, ci sono 3 barre dopo il nome del protocollo, poiché ti riferisci silenziosamente alla macchina corrente invece che a un host remoto (il percorso completo non abbreviato sarebbe file://localhost/c:/my%20path/my%file.html), ma ancora una volta la maggior parte dei client funzionerà senza la parte host (cioè solo due barre ) assumendo che tu intenda la macchina locale e aggiungendo la terza barra.

1
Hexblot è effettivamente corretto qui. Di solito questo accade quando si sta codificando l'URL dei propri URL tramite programmazione, e un bot entra e lo codifica una seconda volta. I bot hanno la cattiva abitudine di farlo. Ci sono due modi in cui puoi gestire questo problema. 1) È possibile 404 o 401 con un'eccezione try catch oppure è possibile scrivere una piccola funzione che decodificherà i valori a doppia decodifica prima di passarla a un altro metodo per la logica aziendale.
Ryan Watts

Questo mi ha aiutato a capire perché lo stavo ricevendo quando inviavo una richiesta jQuery ajax. Stavo impostando l'attributo data in una richiesta GET ajax con la funzione encodeURIComponent sul valore, ma jQuery lo fa già per impostazione predefinita, quindi perché stavo ottenendo% 2520. Grazie davvero utili.
Asher

Non c'è un argomento della riga di comando per Chrome per dirgli di interpretare o non interpretare il collegamento?
AleX_

Ho http://mysite/test & that... If I use UrlEncode` che cambia in http://mysite/test%20&%20thatma voglio anche che &cambi in% 26, quindi è mysite / test% 20% 26% 20che `Come posso farlo?
Si8

10

Per qualche motivo, forse valido, l'URL è stato codificato due volte. %25è il %segno urlencoded . Quindi l'URL originale sembrava:

http://server.com/my path/

Quindi è stato codificato nell'URL una volta:

http://server.com/my%20path/

e due volte:

http://server.com/my%2520path/

Quindi non dovresti fare l'URLencoding - nel tuo caso - poiché altri componenti sembrano farlo già per te. Usa semplicemente uno spazio


Ho riscontrato lo stesso problema ma non capisco perché la codifica URL predefinita sia stata elaborata due volte la prima volta.
jungwon jin

A seconda della situazione, la doppia codifica può essere un risultato perfettamente valido dell'utilizzo corretto della codifica. Questa risposta può creare l'impressione che la doppia codifica sia sempre sbagliata e che puoi semplicemente risolvere i problemi di codifica aggiungendo tutte le chiamate di codifica / unencode necessarie per "farlo funzionare". Questo è sbagliato, ed è così che i bug di codifica vengono in primo luogo. -1
Florian Winter

@FlorianWinter Non vedo davvero dove l'hai letto tra le righe. Puoi darmi una mano? (Si prega di leggere la domanda e la mia risposta)
hek2mgl

7

Quando provi a visitare un nome di file locale tramite il browser Firefox, devi forzare il file:\\\protocollo ( http://en.wikipedia.org/wiki/File_URI_scheme ) altrimenti firefox codificherà il tuo spazio DUE VOLTE. Cambia lo snippet html da questo:

<img src="C:\Documents and Settings\screenshots\Image01.png"/>

a questa:

<img src="file:\\\C:\Documents and Settings\screenshots\Image01.png"/>

o questo:

<img src="file://C:\Documents and Settings\screenshots\Image01.png"/>

Quindi viene notificato a firefox che si tratta di un nome di file locale e visualizza correttamente l'immagine nel browser, codificando correttamente la stringa una volta.

Link utile: http://support.mozilla.org/en-US/questions/900466


0

Il seguente frammento di codice ha risolto il mio problema. Ho pensato che questo potrebbe essere utile ad altri.

var strEnc = this.$.txtSearch.value.replace(/\s/g, "-");
strEnc = strEnc.replace(/-/g, " ");

Piuttosto usando il default, la encodeURIComponentmia prima riga di codice converte tutto spacesin un hyphenspattern regex /\s\ge la riga seguente fa solo il contrario, cioè converte tutto di hyphensnuovo in spacesun altro regex pattern /-/g. Qui /gè effettivamente responsabilefinding all corrispondenza dei caratteri.

Quando invio questo valore alla mia chiamata Ajax, attraversa come normal spaceso semplicemente %20e quindi se ne sbarazza double-encoding.


1
Presumo perché non stai risolvendo la questione, ma solo coprendola - la causa principale è ancora da qualche parte lì, e stai facendo un doppio lavoro (da qualche parte stai codificando accidentalmente due volte e da qualche altra parte stai decodificando manualmente per coprire su). Supponendo che tu voglia fare le cose "correttamente", la cosa migliore sarebbe eseguire il debug e trovare il vero colpevole.
Nick Andriopoulos

In realtà la soluzione ha funzionato per me ovunque ho riscontrato questo problema. Quindi ho postato.
Subrata Sarkar

2
@NiladriSarkar quello che hexbolt stava cercando di dire è che mentre il tuo codice funziona, non è una soluzione praticabile, piuttosto una soluzione sporca, e dovrebbe essere evitato ...
2Dee

-1

Prova questo?

encodeURIComponent('space word').replace(/%20/g,'+')


1
Benvenuto in StackOverflow! In genere le risposte sono più utili se includono qualche spiegazione sul motivo per cui il tuo suggerimento risolverà il problema dell'OP, piuttosto che solo uno snippet di codice. Inoltre, poiché questa domanda ha già una risposta accettata, sarebbe una buona idea aggiungere qualche spiegazione sul motivo per cui la tua risposta è più corretta di quella.
DaveyDaveDave
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.