Наш URL кодер та декодер перетворює URL-адреси й текст у формат із відсотковим кодуванням і назад у реальному часі. Кодуйте спеціальні символи, параметри запитів, сегменти шляху та текст Unicode для безпечного використання в URL. Декодуйте рядки з відсотковим кодуванням назад у зручний для читання текст. Підтримує стандартне кодування RFC 3986, кодування компонентів та повне кодування URL із підтримкою UTF-8. Уся обробка виконується на стороні клієнта — ваші дані ніколи не покидають ваш браузер.
Виберіть «Кодувати», щоб перетворити текст у URL-кодування, або «Декодувати», щоб повернути текст із відсотковим кодуванням.
Виберіть «Компонент» (для значень запитів), «URI» (для повних URL) або «Дані форми» (+ для пробілів).
Введіть або вставте ваш текст (для кодування) або закодовану URL-адресу (для декодування).
Результат з'являється миттєво. Натисніть «Копіювати», щоб скопіювати в буфер обміну.
URL-кодування (процентне кодування) замінює небезпечні або зарезервовані символи знаком відсотка (%), за яким слідують дві шістнадцяткові цифри, що представляють байтове значення символу. Наприклад, пробіл стає %20, а '&' стає %26. Символи UTF-8 використовують кілька відсотково закодованих байтів (наприклад, '€' → %E2%82%AC). Незарезервовані символи (літери, цифри, -, _, ., ~) ніколи не кодуються.
URL Encoding = replace unsafe characters → %HH (hex byte value)
Використовуйте encodeURIComponent для значень параметрів запиту — він кодує все, крім A-Z a-z 0-9 - _ . ~
Використовуйте encodeURI для повних URL — він зберігає :, /, ?, #, &, = та інші символи структури URL
Пробіли можуть кодуватися як %20 (стандарт) або + (дані форми / application/x-www-form-urlencoded)
Завжди кодуйте введені користувачем дані перед вставкою в URL, щоб запобігти ін'єкційним атакам
Символи UTF-8, такі як емодзі, кодуються як кілька байтів %HH (наприклад, 😀 → %F0%9F%98%80)
Подвійне кодування трапляється, коли ви кодуєте вже закодований рядок — спершу декодуйте, якщо не впевнені
RFC 3986 визначає стандарт: нерезервовані символи (A-Z a-z 0-9 - _ . ~) ніколи не кодуються
Наш безкоштовний калькулятор віку... перетворює текст у відсотково закодований формат і назад миттєво. Кодуйте параметри запиту, сегменти шляху та спеціальні символи для безпечного використання URL-адрес. Декодуйте відсотково закодовані рядки назад у зручний для читання текст. Підтримує UTF-8 та всі символи Unicode.
Миттєво перетворюйте будь-який текст у безпечне для URL відсоткове кодування. Наш кодер обробляє пробіли, спеціальні символи, Unicode та емодзі.
Виберіть між:
Декодуйте будь-яку відсотково закодовану URL-адресу назад у читабельний текст. Вставте закодовані URL-адреси, рядки запитів або окремі параметри та миттєво побачте оригінальний текст.
Обробляє:
URL-кодування працює шляхом заміни будь-якого символу, який є небезпечним або зарезервованим у URL, знаком відсотка, за яким слідують дві шістнадцяткові цифри, що представляють байтове значення цього символу, схема, офіційно визначена в RFC 3986 IETF.
Пробіл стає %20, амперсанд стає %26, а слеш стає %2F. Символи, що не належать до ASCII, спочатку перетворюються на їхню послідовність байтів UTF-8, потім кожен байт відсотково закодовується, тому літера 'é' стає %C3%A9.
Згідно з документацією MDN Web Docs, браузери застосовують це автоматично через такі функції, як encodeURIComponent. Лише незарезервовані символи (A-Z, a-z, 0-9, дефіс, підкреслення, крапка, тильда) залишаються незмінними.
encodeURI кодує повну URL-адресу, зберігаючи зарезервовані структурні символи, тоді як encodeURIComponent кодує окремий компонент і також екранує ці структурні символи.
Як задокументовано в MDN Web Docs, encodeURI залишає :, /, ?, #, &, і = недоторканими, щоб вся адреса залишалася функціональною, що робить його правильним для повних URL-адрес. encodeURIComponent екранує все, крім набору незарезервованих за RFC 3986, тому це правильний вибір для значень параметрів запиту, сегментів шляху або тексту фрагмента, який може містити зарезервовані символи.
Використання encodeURI там, де потрібен encodeURIComponent, є поширеною помилкою: незакодований & всередині значення буде неправильно витлумачений як роздільник параметрів, що мовчки пошкодить запит.
RFC 3986 поділяє символи URL на набори незарезервованих і зарезервованих, і ця відмінність визначає, що підлягає відсотковому кодуванню.
Згідно зі специфікацією IETF, зарезервовані символи можуть з'являтися незакодованими, коли вони виконують свою роль роздільника, але повинні бути відсотково закодованими, коли використовуються буквально всередині компонента. Все, що знаходиться поза обома наборами, включаючи пробіли та Unicode, завжди має бути закодоване.
В URL використовується %20 для пробілів, оскільки символ пробілу не може з'являтися в буквальному вигляді в URI згідно з RFC 3986, тому він закодовується у відсотковий формат (percent-encoded) до свого байтового значення ASCII, шістнадцяткового 20.
Існує друга угода: у даних application/x-www-form-urlencoded, форматі, який використовується при надсиланні форм HTML і багатьох рядках запитів, пробіл кодується як знак плюс (+), а не %20, як зазначено в стандартах URL WHATWG та специфікаціях форм W3C.
Саму тому декодери повинні знати свій контекст. %20 є універсально безпечним у шляху, запиті та фрагменті, тоді як + означає лише пробіл усередині закодованих у формі даних запиту і є буквальним плюсом в інших місцях.
URL-кодування обробляє Unicode шляхом спочатку перетворення кожного символу в його байтову послідовність UTF-8, а потім відсоткового кодування кожного окремого байта. Консорціум Unicode визначає кодові точки, а UTF-8 (визначений у RFC 3629) зіставляє їх з одним-чотирма байтами.
Наприклад:
Документація MDN Web Docs зазначає, що функція encodeURIComponent у JavaScript за замовчуванням працює з UTF-8. Декодери зворотним шляхом збирають закодовані відсотками байти та переінтерпретують їх як потік UTF-8, щоб відновити оригінальний текст.
Подвійне кодування виникає, коли вже закодований у відсотковий формат рядок кодується знову, перетворюючи кожен % на %25, так що %20 стає %2520, і значення більше не може бути прочитано правильно.
Це поштове джерело пошкоджених посилань і, згідно з OWASP, проблема безпеки, оскільки зловмисники використовують подвійне кодування, щоб пропустити шкідливі вхідні дані повз фільтри, які виконують декодування лише один раз.
Щоб уникнути цього, закодуйте значення рівно один раз у момент його потрапляння в URL і ніколи не перекодовуйте дані, отримані з іншого закодованого джерела. Якщо ви не впевнені, чи вже закодовано рядок, спершу декодуйте його; якщо вихідні дані змінюються і виглядають читабельними, вони були закодовані, і вам не слід кодувати їх знову.
URL-кодування не є безпечним і не забезпечує конфіденційності; це зворотне перетворення для безпеки транспорту, а не шифрування. Будь-хто може миттєво розкодувати закодований у відсотки рядок, тому конфіденційні дані, розміщені в URL, залишаються повністю читабельними і, як попереджає OWASP, також висвітлюються в історії браузера, журналах сервера та заголовках Referer.
Кодування лише гарантує, що спеціальні символи не порушують синтаксис URL. Шифрування, натомість, використовує ключ та алгоритми на кшталт AES (стандартизовані NIST), щоб зробити дані нечитабельними без цього ключа.
Правильне використання кодування для безпеки поєднується з належним екрануванням вихідних даних для запобігання ін'єкціям; ніколи не сприймайте його як спосіб приховати чи захистити інформацію.
Щоб правильно закодувати рядок запиту, застосуйте encodeURIComponent до кожного ключа та значення параметра окремо, перш ніж об'єднувати їх за допомогою & та =, замість кодування всього зібраного рядка одразу.
Це гарантує, що зарезервовані символи всередині значення, такі як & або = у введених користувачем даних, будуть екрановані до %26 та %3D, щоб їх не можна було сплутати з розділювачами, відповідно до правил application/x-www-form-urlencoded, описаних стандартом URL WHATWG. Наприклад, значення 'hello world&x=1' має перетворитися на 'hello%20world%26x%3D1'.
Згідно з MDN Web Docs, API URLSearchParams автоматизує це безпечно. Завжди кодуйте надані користувачем дані перед вставкою їх у рядок запиту, щоб запобігти ін'єкціям параметрів та некоректним запитам.
Найпоширенішою помилкою URL-кодування є вибір неправильної функції: використання encodeURI для значення запиту залишає &, =, та ? неекранованими, дозволяючи введеним користувачем даним псувати структуру URL.
Інші часті помилки, кілька з яких відзначені OWASP та MDN Web Docs, включають:
Розробники також неправильно поводяться з UTF-8, декодуючи байти як Latin-1, що створює моїбаке для символів з діакритичними знаками та нелатинського тексту. Нарешті, ніколи не покладайтеся на кодування задля безпеки; невиконання додаткового екранування вихідних даних для цільового контексту залишає вразливості до ін'єкцій відкритими попри правильне відсоткове кодування.
Data sourced from trusted institutions
All formulas verified against official standards.