Декодер URL

Декодер URL є безплатним інструментом, який перетворює URL-текст із відсотковим кодуванням назад на початковий рядок.

Що робить декодування URL?

Декодування URL скасовує екранування, яке дає змогу передавати пробіли, розділові знаки та інші байти через URL й інші визначені синтаксиси з відсотковим кодуванням. У такому кодуванні байт записується як знак відсотка з двома шістнадцятковими цифрами після нього. У кодуванні URL для форм пробіл також позначається знаком +. Наприклад, пробіл можна записати як %20, а амперсанд як %26.

Ось простий приклад до й після декодування:

Закодовані вхідні дані: red%20%26%20blue

Декодований результат: red & blue

Таке кодування потрібне, оскільки деякі символи мають структурне значення в URL. Знак питання відокремлює рядок запиту URL, а у даних запиту, закодованих у форматі форми, звичайний амперсанд зазвичай розділяє поля. Кодування дає застосунку змогу передавати ці символи саме як дані.

Кодування URL не є шифруванням і не забезпечує конфіденційності. Кожен, хто може прочитати закодоване значення, може його декодувати. Не вважай паролі, токени доступу чи персональну інформацію з відсотковим кодуванням захищеними даними.

Як користуватися декодером URL?

Встав або введи закодований текст, запусти обробку, а потім переглянь відновлене значення в полі результату Декодований URL. Інструмент використовує функцію PHP urldecode, тому перетворює коректні послідовності %HH і трактує знак плюса як пробіл.

1. Скопіюй закодований компонент, наприклад значення параметра запиту.
2. Введи значення в URL-кодуванні, не додаючи лапок, якщо вони насправді не є частиною значення.
3. Оброби введені дані URL і перевір результат у полі Декодований URL.
4. Якщо результат усе ще містить послідовності на зразок %2F або %20, перш ніж декодувати його знову, перевір, чи не було джерело закодоване кілька разів.

Обробка відбувається на сервері. Введені дані передаються на сервер через HTTPS і не зберігаються, однак під час обробки вони залишають твій пристрій. Не вставляй секретні дані в цей декодер URL, якщо серверна обробка для них неприйнятна.

Де використовують кодування URL?

Найчастіше кодування URL трапляється в рядках запиту, даних, надісланих через форми, і значеннях усередині посилань. Воно також використовується в менш очевидних випадках, коли дані потрібно передати через текстовий формат з обмеженим набором символів.

• Рядки запиту: пошуковий запит "tea & cake" може мати вигляд q=tea+%26+cake.
• URI даних: текстові дані можна закодувати відсотковим кодуванням після типу медіа, хоча Base64 також є поширеним способом подання.
• Посилання в електронній пошті: у посиланні mailto пробіли, перенесення рядків і розділові знаки в параметрах теми або тексту листа можуть бути закодовані. Кодування передавання MIME всередині електронного листа є окремими форматами.
• Дані JSON: JSON має власні правила екранування, але рядок JSON може містити вже закодований URL або значення запиту, яке потрібно декодувати окремо.
• Інтернаціоналізовані домени: у мітках доменів із символами поза ASCII зазвичай використовується Punycode, а не відсоткове кодування. Компоненти шляху й запиту все одно можуть містити байти UTF-8 із відсотковим кодуванням.

Якщо закодований текст є міткою домену, що починається з xn--, скористайся інструментом Конвертер IDN Punycode. Декодер URL призначений для компонентів URL із відсотковим кодуванням, а не для перетворення Punycode.

Приклади декодування URL

Наведені нижче приклади показують поширені вхідні дані та відповідний текст після декодування URL.

• hello%20world перетворюється на hello world.
• name=Tom+Jones перетворюється на name=Tom Jones.
• fish%26chips перетворюється на fish&chips.
• %C2%A3 перетворюється на £, якщо байти представляють текст UTF-8.
• %E6%9D%B1%E4%BA%AC перетворюється на 東京, якщо інтерпретувати дані як UTF-8.
• 100%25 перетворюється на 100%.

Звичайні літери, цифри та незакодовані розділові знаки переважно залишаються без змін. Якщо нічого не ввести, поле Декодований URL також буде порожнім. Для дуже довгих вхідних даних діють ті самі правила декодування, хоча браузери, сервери й системи-одержувачі можуть установлювати власні обмеження на довжину запиту або URL.

Символи з діакритичними знаками та символи нелатинських абеток зазвичай кодуються як послідовність байтів UTF-8, причому кожен байт записується окремо. Якщо початкова система використовувала інше кодування символів, декодовані байти можуть відображатися як символи заміни або як незрозумілий текст.

Чому URL не декодується або результат виглядає незрозуміло?

Результат декодування URL може залишитися без змін або виявитися неочікуваним, якщо вхідні дані містять неповні відсоткові послідовності, були закодовані кілька разів, інтерпретуються в неправильному кодуванні символів або взагалі не є даними в URL-кодуванні. Функція PHP urldecode залишає некоректні відсоткові послідовності без змін, а для двічі закодованих даних після одного проходу повертає проміжний результат. Перш ніж декодувати дані кілька разів поспіль, перевір початкове джерело.

• Двічі закодовані дані: після одного декодування %2520 перетворюється на %20, а пробіл з'являється лише після другого проходу. Декодуй повторно тільки тоді, коли точно знаєш, що існує ще один рівень кодування.
• Неповна відсоткова послідовність: для кожного закодованого байта потрібні дві шістнадцяткові цифри. Знак % у кінці або значення на зразок %2 є некоректними й не можуть представляти повний закодований байт, тому функція PHP urldecode залишає їх без змін.
• Неправильне кодування символів: відсоткове декодування відновлює байти. Наприклад, якщо інтерпретувати байти ISO-8859-1 як UTF-8, можна отримати незрозумілі символи, навіть якщо відсоткові послідовності були коректними.
• Двійкові, а не текстові дані: декодовані байти можуть представляти зображення, стиснений файл або інший двійковий вміст. Такий результат не повинен відображатися як читабельний текст.
• Інше сімейство кодування: якщо після декодування URL передати результат у Декодер Base64, той може завершити обробку помилкою через стандартний або безпечний для URL алфавіт, відсутнє доповнення = чи пошкоджені вхідні дані. Відсоткове кодування URL не має доповнення й не використовує алфавіт Base64, а декодування URL не перевіряє та не виправляє такі проблеми Base64.

Будь уважний зі звичайними знаками плюса. У кодуванні URL для форм + означає пробіл. Справжній знак плюса перед декодуванням зазвичай потрібно кодувати як %2B.

Поширені запитання

Декодувати весь URL чи лише окрему частину?

Якщо можливо, декодуй окремий сегмент шляху або значення параметра запиту. Під час декодування всього URL закодовані зарезервовані символи, як-от %26, %3F або %2F, можуть перетворитися на роздільники та змінити спосіб аналізу URL.

Чи розпізнає декодер URL шістнадцяткові коди з малими літерами?

Так. Регістр шістнадцяткових цифр у відсоткових послідовностях не має значення, тому %2f і %2F представляють той самий байт. Послідовності зі змішаним регістром також коректні.

Чи декодує інструмент те саме значення кілька разів?

Ні. Один виклик urldecode виконує лише один прохід декодування. Якщо %252F перетворюється на %2F, для отримання скісної риски потрібен ще один прохід. Однак повторне декодування може змінити дані, у яких відсоткова послідовність мала залишитися буквальною.

Чи можна відновити пошкоджений текст декодуванням URL?

Ні. Декодування може скасувати коректне відсоткове кодування, але не здатне відновити пропущені шістнадцяткові цифри або точно визначити початкове кодування символів. Якщо декодовані байти відображаються неправильно, перевір вихідну систему, заголовки HTTP або документацію.

Що робити зі значенням, яке починається з xn--?

Сприймай його як мітку домену Punycode, а не як звичайний текст із відсотковим кодуванням. Скористайся інструментом Конвертер IDN Punycode, а потім уважно перевір отриманий домен, оскільки візуально схожі символи Unicode можуть належати до різних систем письма.