Kodowanie i dekodowanie URL

Kodowanie i dekodowanie URL stosuje kodowanie procentowe RFC 3986 do tekstu i odwraca sekwencje %HH z powrotem na znaki. Tryb komponentu koduje znaki zarezerwowane, takie jak /, ? i &, aby mogły bezpiecznie leżeć w jednym parametrze zapytania. Tryb pełnego URI zachowuje strukturalne separatory, więc pełny adres pozostaje użytecznym linkiem. Obsługa spacji obejmuje zarówno %20, jak i znak plus w kodowaniu formularza.

Całe kodowanie i dekodowanie działa w przeglądarce. Wklejone dane nie trafiają na serwer.

Kodować tekst do bezpiecznego użycia w URL

Kodowanie procentowe zastępuje niebezpieczne lub zarezerwowane bajty znakiem procentu i dwoma cyframi szesnastkowymi. Cyfry to wartość bajtu, zwykle z UTF-8. Wpisz ciąg, wybierz tryb komponentu lub pełnego URI i skopiuj wynik do ciągu zapytania, segmentu ścieżki lub celu przekierowania.

Znaki już w zbiorze niezarezerwowanym przechodzą bez zmian. Reszta staje się sekwencjami %HH w trybie komponentu. Kodowanie jest odwracalne, gdy te same reguły stosuje się przy dekodowaniu; mieszanie plusa z kodowania formularza ze ścieżkowym %20 to najczęstsze źródło zepsutych przejść tam i z powrotem.

Dekodować ciąg z kodowaniem procentowym

Dekodowanie znajduje każdy % z dwoma cyframi hex, zamienia tę parę na bajt i odbudowuje oryginalny tekst w wybranym kodowaniu znaków. Samotny % lub % z cyframi niehex to błąd. Znaki plus można opcjonalnie traktować jako spacje, gdy dane pochodzą z ciał application/x-www-form-urlencoded.

Zagnieżdżone kodowanie pojawia się, gdy wartość była kodowana dwukrotnie. Jedno dekodowanie może zostawić sekwencje %25 reprezentujące literalny procent. Dekoduj ponownie tylko wtedy, gdy druga warstwa była zamierzona; ślepe podwójne dekodowanie psuje dane zawierające prawdziwy znak %.

Zrozumieć znaki zarezerwowane i niezarezerwowane

RFC 3986 dzieli ASCII na znaki niezarezerwowane, które nigdy nie wymagają kodowania w URI, oraz znaki zarezerwowane niosące znaczenie strukturalne, np. separatory. Niezarezerwowane litery, cyfry i -_.~ pozostają literalne. Zarezerwowane znaki jak /, ? i & muszą być kodowane procentowo, gdy występują jako dane, a nie składnia ramująca URL.

Niezarezerwowane: A do Z, a do z, 0 do 9, myślnik -, podkreślenie _, kropka ., tylda ~

Zarezerwowane (gen-delims): `: / ?

Zarezerwowane (sub-delims): ! $ & ' ( ) * + , ; =

Znaki niezarezerwowane pozostają literalne. Znaki zarezerwowane trzeba kodować, gdy występują jako dane, a nie separatory. Znak zapytania w wartości parametru to dane; znak zapytania rozpoczynający ciąg zapytania to struktura. Wybór trybu mówi kalkulatorowi, jaką rolę pełni każdy znak.

Kodować cały URL a pojedynczy parametr

Kodowanie pełnego URI, podobne do JavaScript encodeURI, zostawia znaki strukturalne w spokoju, więc https:// i ukośniki ścieżki przetrwają. Kodowanie komponentu, podobne do encodeURIComponent, koduje te znaki, aby wartość mogła leżeć w parametrze bez psucia otaczającego URL. Zły tryb albo niszczy link, albo zostawia separatory dzielące zapytanie niepoprawnie.

Wejście	Styl pełnego URI	Styl komponentu
https://example.com/a b	https://example.com/a%20b	https%3A%2F%2Fexample.com%2Fa%20b
red&blue	red&blue	red%26blue
a=b	a=b	a%3Db

Kodowanie całego URL w trybie komponentu niszczy go jako link: dwukropek schematu i ukośniki stają się %3A i %2F. Kodowanie pojedynczego parametru w trybie pełnego URI zostawia & i = nietknięte, co niepoprawnie dzieli zapytanie. Wybierz tryb pasujący do miejsca, które ciąg zajmie.

Kodować ukośnik i znak zapytania

Ciąg testowy / and ? w trybie komponentu staje się %2F%20and%20%3F. Ukośnik i znak zapytania to zarezerwowane separatory traktowane tu jako tekst ładunku, więc każdy jest escapowany. Spacje stają się %20, a litery w and są niezarezerwowane i przechodzą bez zmian od lewej do prawej.

Znak	Powód	Zakodowany
/	zarezerwowany separator ścieżki	%2F
spacja	nie jest niezarezerwowana	%20
a, n, d	niezarezerwowane litery	bez zmian
?	zarezerwowany separator zapytania	%3F

Przejdź ciąg od lewej do prawej: zakoduj /, zakoduj spację, przepuść and, zakoduj spację, zakoduj ?. Wynik %2F%20and%20%3F jest bezpieczny w parametrze zapytania o nazwie na przykład q. Tryb pełnego URI na tym samym ciągu zostawi / i ? literalne, co jest poprawne tylko, gdy te znaki mają być strukturą, a nie ładunkiem.

Zrozumieć %20 a znak plus

Spacja koduje się jako %20 w segmentach ścieżki URI i we współczesnych ciągach zapytania zgodnych z RFC 3986. Formularze HTML wysyłane jako application/x-www-form-urlencoded historycznie kodowały spacje jako +. Oba konwencje występują w ruchu produkcyjnym, a traktowanie ich jako identycznych to najczęstszy błąd kodowania spacji przy dekodowaniu mieszanych wejść.

Kontekst	Kodowanie spacji
Segment ścieżki	%20
Zapytanie RFC 3986	%20
Ciało formularza / legacy query	+

Literalny znak plus w danych musi być zakodowany jako %2B, inaczej dekoder formularza potraktuje go jako spację. Kalkulator oznacza, która konwencja spacji jest aktywna, aby odkodowany + nie został pomylony ze znakiem plus przy trybie formularza, a %20 nie został odrzucony przy trybie ścieżki.

Rozłożyć URL na części

Typowy URL ma schemat, host, opcjonalny port, ścieżkę, ciąg zapytania i fragment, a reguły kodowania różnią się według części. Strukturalne separatory jak ://, /, ?, &, = i # pozostają literalne, gdy ramują adres.

Nazwy parametrów, wartości parametrów i segmenty ścieżki niosące dane koduje się indywidualnie w trybie komponentu, zanim separatory je połączą.

https://example.com:443/search?q=a%20b&lang=en#top
└─┬─┘   └─────┬─────┘ └─┬──┘ └───────┬───────┘ └┬┘
scheme       host     path        query      fragment

Część	Rola
Schemat	Protokół, np. https
Host	Domena lub IP, z opcjonalnym portem
Ścieżka	Lokalizacja zasobu, rozdzielana ukośnikami
Zapytanie	Lista parametrów po ?, łączona przez &
Fragment	Lokalizacja po stronie klienta po #, nie wysyłana do serwera tak samo jak URI żądania

Koduj nazwy i wartości parametrów indywidualnie w trybie komponentu, potem łącz literalnymi & i =. Koduj segmenty ścieżki indywidualnie, jeśli zawierają spacje lub znaki zarezerwowane, zachowując ukośniki rozdzielające segmenty jako literalne.

Czytać tabelę kodowania znaków

Poniższa tabela listuje typowe znaki zarezerwowane i niebezpieczne z ich formami procentowymi przy kodowaniu bajtów UTF-8. Spacja staje się %20, ampersand %26, hash %23. Znaki spoza ASCII rozwijają się na wiele jednostek %HH, bo każdy bajt UTF-8 koduje się osobno, a nie jako jeden abstrakcyjny glif.

Znak	Procent	Uwagi
spacja	%20	Lub + w kodowaniu formularza
!	%21
#	%23	Separator fragmentu
$	%24
&	%26	Separator par zapytania
'	%27
(	%28
)	%29
+	%2B	Literalny plus
,	%2C
/	%2F	Separator ścieżki
:	%3A	Separator schematu / hosta
;	%3B
=	%3D	Przypisanie parametru
?	%3F	Początek zapytania
@	%40	Separator userinfo
[	%5B
]	%5D

Tekst spoza ASCII najpierw wyraża się jako bajty UTF-8, potem każdy bajt koduje się procentowo. Jeden widoczny znak może więc rozszerzyć się na dwie lub trzy jednostki %HH. Głębokie omówienia kodowania znaków dla Shift JIS i podobnych zestawów legacy są przy narzędziu Base64; ta strona linkuje zamiast powtarzać katalog.

Często zadawane pytania

Podsumowanie

Kodowanie i dekodowanie URL koduje i dekoduje tekst procentowo według reguł RFC 3986, z osobnymi trybami dla pełnych URI i pojedynczych komponentów. Ciąg testowy / and ? staje się %2F%20and%20%3F w trybie komponentu. Spacje używają %20 w kontekstach URI i mogą używać + w kodowaniu formularza, co jest inną konwencją.

Znaki zarezerwowane zachowują znaczenie tylko, gdy pozostają literalne jako struktura; koduj je, gdy są ładunkiem. Cała praca zostaje na urządzeniu.