Według RFC 3986 następujące znaki są zastrzeżone i muszą być procent kodowane w celu wykorzystania w URI innych niż ich zarezerwowanych zastosowań: :/?#[]@!$&'()*+,;=
Kiedy, jeśli w ogóle, znaki takie jak {i} (nawiasy klamrowe) muszą być kodowane procentowo w adresach URL?
Ponadto określa pewne znaki, które są specjalnie bezwarunkowe: a-zA-Z0-9\-._~
wydaje się oczywiste, że generalnie powinno się kodować znaków zastrzeżonych (aby zapobiec błędnej interpretacji), a nie kodowania znaków niezarezerwowane (dla czytelności), ale jak powinien znaki, które nie należą do żadnej kategorii obchodzić? Na przykład {
i }
nie pojawiają się na żadnej z tych list, ale są to standardowe znaki ASCII.
Wygląda na to, że dla nowoczesnych przeglądarek mają one różne zachowania. Na przykład, rozważmy wklejając URL https://www.google.com/search?q={
w pasku adresu przeglądarki internetowej:
- Chrome 34.0.1847.116 m go nie zmieni.
- Firefox 28.0 go nie zmienia.
- Program Internet Explorer 9.0 go nie zmienia.
- Safari 5.1.7 zmienia go
https://www.google.com/search?q=%7B
Jednakże, jeśli jeden pasty https://www.google.com/#q={
(usuwanie „szukaj” i zmieniając ?
do #
, dzięki czemu części charakter fragmentu/hash zamiast łańcucha zapytania) dowiadujemy się, że:
- Chrome 34.0.1847.116 m zmienia go
https://www.google.com/#q=%7B
(za pośrednictwem JavaScript) - Firefox 28.0 nie ją zmienić.
- Program Internet Explorer 9.0 go nie zmienia.
- Safari 5.1.7 zmienia go
https://www.google.com/#q=%7B
(przed wykonaniem JavaScript)
Ponadto, przy użyciu JavaScript, aby wykonać żądania asynchronicznie (czyli używając this MDN example zmodyfikowane, aby użyć URL ?q={
), adres URL nie jest procent - automatycznie zakodowane. (Zgaduję to dlatego, że API XMLHttpRequest zakłada, że adres URL jest kodowany/uciekł wcześniej).
chciałbym (z powodów związanych z dziwacznym życzenie klienta) używać {
i }
w części nazwy pliku Adresy URL bez (1) niszczenia rzeczy, a najlepiej bez (2) tworzenia brzydko wyglądających zapisanych procentowo wpisów w panelu sieciowym nowoczesnych przeglądarek internetowych/debuggerów.
Hmm, miałem nadzieję na odpowiedź od RFC3986, ponieważ to miało zastąpić RFC2396, ale doceniam twoją odpowiedź. Dodatek D mówi: "Sekcja 2, na znakach, została przepisana w celu wyjaśnienia, jakie znaki są zarezerwowane, kiedy są zarezerwowane i dlaczego są zarezerwowane, nawet jeśli nie są używane jako ograniczniki przez ogólną składnię ..." i domyślam się, że to przeróbka spowodowała dla mnie dwuznaczność. – iX3