Czasami spacje są kodowane URL-em do +
znaku, innym razem do %20
. Jaka jest różnica i dlaczego tak się dzieje?
Czasami spacje są kodowane URL-em do +
znaku, innym razem do %20
. Jaka jest różnica i dlaczego tak się dzieje?
Odpowiedzi:
+
oznacza spację tylko w application/x-www-form-urlencoded
treści, taką jak część adresu URL zapytania:
http://www.example.com/path/foo+bar/path?query+name=query+value
W tym adresie URL nazwa parametru jest query name
spacją, a wartość query value
spacją, ale nazwa folderu na ścieżce jest dosłownie foo+bar
, a nie foo bar
.
%20
jest prawidłowym sposobem kodowania spacji w dowolnym z tych kontekstów. Jeśli więc musisz zakodować adres URL ciągu znaków, aby uwzględnić go w części adresu URL, zawsze możesz bezpiecznie zastąpić spacje %20
znakiem plus %2B
. Oto co np. encodeURIComponent()
robi w JavaScript. Niestety, nie jest to, co robi urlencode w PHP ( rawurlencode jest bezpieczniejszy).
Zobacz także Aplikacja do specyfikacji HTML 4.01 / x-www-form-urlencoded
query+name=query+value
parametr z formularza za pomocą <input name="query name" value="query value">
. Nie utworzy query%20name
z formularza, ale można go bezpiecznie używać, np. jeśli składasz razem formularz do złożenia XMLHttpRequest
. Jeśli masz adres URL ze spacją, na przykład <a href="http://www.example.com/foo bar/">
, to przeglądarka go zakoduje, %20
abyś mógł naprawić swój błąd, ale prawdopodobnie nie należy na nim polegać.
foo bar
do foo+bar
?
encodeURIComponent(s).replace(/%20/g, '+')
jeśli naprawdę potrzebujesz+
http://www.example.com/some/path/to/resource?param1=value1
Część przed znakiem zapytania musi używać kodowania% (czyli %20
spacji), po znaku zapytania można użyć jednej %20
lub +
spacji. Jeśli potrzebujesz faktury +
po znaku zapytania, użyj %2B
.
decodeURIComponent
nie dekoduje go.
+
jest to znak zastrzeżony , zostanie zachowany przez przeglądarkę.
+
domyślnie również dekodują spacje za pomocą ( { foo: 'bar bar'}.to_query
=> foo=bar+bar
)
Tak więc odpowiedzi tutaj są nieco niekompletne. Użycie „% 20” do zakodowania spacji w adresach URL jest wyraźnie zdefiniowane w RFC3986 , która definiuje sposób budowania identyfikatora URI. W tej specyfikacji nie ma wzmianki o używaniu „+” do kodowania spacji - jeśli przechodzisz wyłącznie przez tę specyfikację, spacja musi być zakodowana jako „% 20”.
Wzmianka o używaniu „+” do kodowania spacji pochodzi z różnych wcieleń specyfikacji HTML - szczególnie w sekcji opisującej typ zawartości „application / x-www-form-urlencoded”. Służy do publikowania danych formularza.
Teraz specyfikacja HTML 2.0 (RFC1866) wyraźnie stwierdza w sekcji 8.2.2, że część zapytania w ciągu znaków adresu URL żądania GET powinna być zakodowana jako „application / x-www-form-urlencoded”. Teoretycznie sugeruje to, że dozwolone jest użycie znaku „+” w adresie URL w ciągu zapytania (po „?”).
Ale ... czy to naprawdę? Pamiętaj, że HTML sam w sobie jest specyfikacją treści, a adresy URL z ciągami zapytań mogą być używane z treściami innymi niż HTML. Ponadto, podczas gdy późniejsze wersje specyfikacji HTML nadal definiują „+” jako dozwolone w treści „application / x-www-form-urlencoded”, całkowicie pomijają tę część, mówiąc, że ciągi zapytań GET są zdefiniowane jako ten typ. W rzeczywistości nie ma żadnej wzmianki o kodowaniu ciągu zapytania w niczym po specyfikacji HTML 2.0.
Które pozostawia nam pytanie - czy jest ważne? Na pewno jest DUŻO starszego kodu, który obsługuje „+” w ciągach zapytań, a także dużo kodu, który go generuje. Tak więc szanse są dobre, że nie złamiesz się, jeśli użyjesz „+”. (I faktycznie przeprowadziłem wszystkie badania na ten temat niedawno, ponieważ odkryłem główną witrynę, która nie zaakceptowała „% 20” w zapytaniu GET jako spacji. W rzeczywistości nie udało im się dekodować ŻADNEGO procentu zakodowanego znaku. Więc usługa może być również istotne).
Ale po czystym przeczytaniu specyfikacji, bez przeniesienia języka ze specyfikacji HTML 2.0 do późniejszych wersji, adresy URL są w całości objęte RFC3986, co oznacza, że spacje powinny zostać przekonwertowane na „% 20”. I zdecydowanie tak powinno być, jeśli żądasz czegoś innego niż dokument HTML.
%20
( <a href="?q=a b">
), ale podczas wysyłania formularza używa +
znaku. Możesz to zmienić, jawnie używając +
znaku ( <a href="?q=a+b">
) lub wysyłając formularz za pomocą XMLHTTPRequest
.
Lepiej zawsze kodować spacje jako% 20, a nie jako „+”.
To była RFC-1866 (specyfikacja HTML 2.0), która określa, że znaki spacji powinny być kodowane jako „+” w „pary klucz-wartość typu application / x-www-form-urlencoded”. (patrz ust. 8.2.1. akapit 1). Ten sposób kodowania danych formularza jest również podany w późniejszych specyfikacjach HTML, poszukaj odpowiednich akapitów na temat application / x-www-form-urlencoded.
Oto przykład takiego ciągu w adresie URL, w którym RFC-1866 zezwala na kodowanie spacji jako plusów: „http://example.com/over/there?name=foo+bar”. Tak więc, tylko po „?” Spacje można zastąpić plusami, zgodnie z RFC-1866. W innych przypadkach spacje powinny być kodowane do% 20. Ponieważ jednak trudno jest określić kontekst, najlepszą praktyką jest, aby nigdy nie kodować spacji jako „+”.
Poleciłbym procentowe kodowanie wszystkich znaków oprócz „niezarezerwowanych” zdefiniowanych w RFC-3986, str. 2.3
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Jaka jest różnica: zobacz inne odpowiedzi.
Kiedy używać +
zamiast %20
? Użyj, +
jeśli z jakiegoś powodu chcesz, aby ciąg zapytania URL ( ?.....
) lub fragment skrótu ( #....
) były bardziej czytelne. Przykład: Możesz to przeczytać:
https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces
( %2B
= +)
Ale o wiele trudniej jest przeczytać: (przynajmniej dla mnie)
Myślę, że +
jest mało prawdopodobne, aby cokolwiek zepsuć, ponieważ Google używa +
(patrz pierwszy link powyżej) i prawdopodobnie o tym pomyśleli. Użyję +
siebie tylko dlatego, że czytelny + Google uważa, że jest OK.