Przestrzeń HTML wyświetla się jako% 2520 zamiast% 20

Question

Przekazywanie nazwy pliku do przeglądarki Firefox powoduje zastąpienie spacji przez %2520 zamiast %20.

mam następujące HTML w pliku o nazwie myhtml.html:

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

Kiedy załadować myhtml.html do Firefoksa, obraz pojawia się jako uszkodzonego obrazu. Klikam prawym przyciskiem myszy na link, aby zobaczyć zdjęcie, i pokazuje to zmodyfikowany adres URL:

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

Co do cholery? Przekształcił moją przestrzeń w %2520. Czy nie powinien on konwertować tego na %20?

Jak zmienić ten plik HTML, aby przeglądarka mogła znaleźć moje zdjęcie? Co tu się dzieje?

Answer 1

Trochę wyjaśniając, co to jest: %2520

Charakter wspólna przestrzeń jest zakodowany jako %20 jak zauważył sam. Znak % jest kodowany jako %25.

Sposób dostać %2520 jest, gdy adres URL ma już %20 w nim, i dostaje urlencoded znowu, który przekształca %20 do %2520.

Czy używasz (lub jakiejkolwiek innej struktury) podwójnego kodowania znaków?

Edit: Rozszerzając trochę na ten temat, zwłaszcza dla LOKALNYCH linki. Zakładając, że chcesz połączyć się z zasobem C:\my path\my file.html:

• jeśli podasz ścieżkę lokalną pliku tylko oczekuje się, że przeglądarka do kodowania i chronić wszystkie znaki podane (w powyższym należy podać go z przestrzeni, jak pokazano, ponieważ % jest prawidłową nazwą pliku i jako taki zostanie zakodowany) podczas konwersji na właściwy URL (patrz następny punkt).
• jeśli podasz URL z protokołem file://, zasadniczo twierdzisz, że podjąłeś wszystkie środki ostrożności i zakodowałeś to, co wymaga kodowania, reszta powinna być traktowana jako znaki specjalne. W powyższym przykładzie powinieneś podać file:///c:/my%20path/my%20file.html. Oprócz naprawiania ukośników klienci nie powinni tutaj kodować znaków.

UWAGI: kierunek

• Slash - ukośniki / są wykorzystywane w adresach URL, reverse ukośniki \ w ścieżkach Windows, ale większość klientów będzie współpracować zarówno poprzez przekształcenie ich do właściwego ukośnikiem.
• Dodatkowo po nazwie protokołu występują trzy ukośniki, ponieważ w trybie cichym mowa jest o bieżącej maszynie zamiast o zdalnym hoście (pełna nieskrócona ścieżka to file://localhost/c:/my%20path/my%file.html), ale znowu większość klientów będzie działać bez części hosta (tzn. tylko dwa ukośniki) zakładając, że masz na myśli lokalną maszynę i dodajesz trzeci ukośnik.

Answer 2

Gdy próbujesz odwiedzić lokalną nazwę pliku przez przeglądarkę Firefox, trzeba wymusić protokół file:\\\ (http://en.wikipedia.org/wiki/File_URI_scheme) albo Firefox będzie kodować swoje miejsce dwukrotnie. Zmienić fragment kodu HTML z tego:

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

do tego:

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

lub to:

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

Następnie firefox zostaje powiadomiony, że jest to lokalna nazwa pliku, a to sprawia, że ​​obraz poprawnie w przeglądarce, poprawnie kodując ciąg raz.

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

Answer 3

Z jakiegoś powodu URL został zakodowany dwukrotnie. %25 jest znakiem urlencoded %. Tak oryginalny url wyglądało:

http://server.com/my path/ 

Potem dostałem urlencoded raz:

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

i dwukrotnie:

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

więc należy zrobić, nie urlencoding jak inne składniki wydaje się, że już dla ciebie. Użyj po prostu przestrzeń

Answer 4

Poniższy fragment kodu rozwiązał mój problem. Pomyślałem, że może to być przydatne dla innych.

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

Raczej używając domyślnego encodeURIComponent moja pierwsza linia kodu jest konwersja wszystkich spaces do hyphens użyciu regex wzór /\s\g i następujący wiersz tylko robi na odwrót, czyli konwertuje wszystkie hyphens z powrotem do spaces użyciu innego regex pattern /-/g. W tym przypadku /g jest odpowiedzialny za dopasowanie znaków do siebie.

Kiedy wysyłam tę wartość do mojego wywołania Ajax, przemierza się jako normal spaces lub po prostu %20 i tym samym pozbywa się double-encoding.