Kodowanie/odkodowywanie URL

Obsługuje kodowanie i dekodowanie procentowe adresów URL, obsługę znaków specjalnych, spacji i tekstu wielojęzycznego. Automatycznie wykrywa format kodowania, obsługuje przetwarzanie parametrów zapytania, odpowiednie do wywołań API, przesyłania formularzy i udostępniania linków.

Instrukcja użycia

🚀 Szybki start

Wpisz powyżej zawartość (URL, tekst, CJK itp.)
Kliknij „Koduj” lub „Dekoduj”, aby przełączyć tryb
Kliknij przycisk, aby rozpocząć; wynik pojawi się w tym samym polu tekstowym
Użyj przycisku kopiowania poniżej, aby skopiować wynik

📌 Typowe scenariusze

Parametry API: koduj parametry zapytań i treść żądań, aby poprawnie przesyłać znaki specjalne
Wysyłanie formularzy: obsługa danych GET/POST; w tym tekstu CJK i symboli specjalnych
Udostępnianie linków: generuj adresy URL z CJK/znakami specjalnymi bez ryzyka zniekształceń
Zapytania wyszukiwania: koduj słowa kluczowe, zwłaszcza gdy zawierają & = # ?

🧭 Wskazówki użycia

Unikaj podwójnego kodowania: sprawdź, czy zawartość nie zawiera już sekwencji %XX
Częściowe kodowanie: koduj tylko wartości parametrów (np. ?key=encoded), zachowując strukturę URL
Debugowanie: dekoduj parametry w żądaniach sieciowych, aby szybciej lokalizować problemy
Znaki zastrzeżone: : / ? # [ ] @ ! $ & ' ( ) * + , ; = mają specjalne znaczenie; gdy występują jako dane, zwykle wymagają kodowania (zależnie od kontekstu, szczególnie : / ? # & = +)
Kodowanie znaków: znaki spoza ASCII są kodowane w UTF‑8 jako 1–4 bajty, każdy bajt zapisywany jako %HH

⚠️ Ograniczenia i kompatybilność

Kodowanie URL ≠ szyfrowanie: to odwracalne przekształcenie formatu, które nie chroni danych wrażliwych
Długość URL: zalecana całkowita długość < 2048 znaków (zależnie od przeglądarki/serwera)
Spacje: w ciągach zapytań mogą być reprezentowane jako + (formularze) lub %20 (ogólnie); to narzędzie domyślnie używa %20
Bardzo długie teksty: mogą powodować spowolnienie lub brak reakcji przeglądarki; rozważ podział na części

🔒 Prywatność i bezpieczeństwo

Całe przetwarzanie odbywa się w Twojej przeglądarce; dane nie opuszczają Twojego urządzenia.
Wrażliwe dane (hasła, klucze, tokeny) powinny być szyfrowane, a nie tylko kodowane

❓ Najczęstsze pytania

Czym jest URL i dlaczego należy go „kodować”?

URL (Uniform Resource Locator) został wprowadzony jako czytelny dla człowieka sposób opisu schematu/hosta/ścieżki/zapytania/fragmentu. Aby uniknąć mylenia znaków danych z separatorami (np. ? & # = /) oraz obsłużyć spacje, tekst spoza ASCII i emoji, takie znaki przekształca się na kodowanie procentowe %HH (np. spacja→%20, „/” w wartości parametru→%2F). W kontekście application/x‑www‑form‑urlencoded spacje mogą być również zapisywane jako „+” (poza formularzami zalecane jest %20). Kodowanie URL to odwracalne formatowanie łącza, a nie szyfrowanie.

Czy kodowanie chroni informacje wrażliwe?

Nie. Kodowanie jest odwracalnym przekształceniem formatu. Hasła, klucze API i inne sekrety muszą być szyfrowane.

Dlaczego spacja bywa zapisywana jako +, a czasem jako %20?

Formularze (application/x-www-form-urlencoded) używają +, natomiast RFC 3986 ogólnie zaleca %20. To narzędzie domyślnie używa %20 dla lepszej zgodności; jeśli potrzebujesz +, użyj go w kontekście formularzy lub zamień ręcznie.

Jak rozpoznać, że treść jest już zakodowana?

Zakodowana treść zawiera sekwencje %XX (% i dwie szesnastkowe cyfry, np. %E4%BD%A0). Jeśli widzisz ich dużo, to najpewniej jest już zakodowana – unikaj ponownego kodowania.

Dlaczego znaki spoza ASCII muszą być kodowane?

Standard URL dopuszcza wyłącznie znaki ASCII. Tekst spoza ASCII (np. litery z akcentami, emoji) musi zostać zakodowany procentowo (bajty UTF‑8 jako %HH), aby można go było bezpiecznie przesyłać.

Czy ukośnik / musi być kodowany?

To zależy od miejsca: jako separator ścieżki nie powinien być kodowany (np. /api/users). Jako wartość parametru powinien być kodowany jako %2F (np. ?path=%2Fhome%2Fuser).