Кодувальник URL

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

Що таке кодування URL і навіщо воно потрібне?

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

Наприклад, амперсанд розділяє параметри запиту. Тому амперсанд усередині значення потрібно закодувати як %26. Пробіли також обробляються особливим чином. Цей інструмент використовує функцію PHP urlencode, яка замінює пробіл знаком плюса.

До кодування: tea and cake

Після кодування: tea+and+cake

Закодований для URL текст можна зустріти в таких випадках:

• у рядках запиту, надісланих через вебформи;
• в URI даних із текстом, який не можна вказати буквально;
• у посиланнях, доданих до електронних листів;
• у значеннях URL, що зберігаються в даних JSON;
• у параметрах переспрямування та зворотного виклику, які використовують вебзастосунки;
• в URL, пов'язаних з інтернаціоналізованими доменами, хоча для самого доменного імені замість відсоткового кодування може знадобитися Punycode.

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

Як користуватися Кодувальником URL?

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

Обробка відбувається на сервері. Введені дані передаються на сервер через HTTPS і не зберігаються. Попри це, не додавай до URL паролі, токени сеансів або конфіденційні персональні дані, адже вебадреси можуть потрапляти в історію браузера, аналітичні системи та журнали серверів.

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

Кодувати весь URL чи лише значення параметра?

Зазвичай потрібно кодувати кожне значення параметра, а не весь URL. Під час кодування повної адреси також буде замінено структурні символи, зокрема двокрапку, скісні риски, знак питання та знак рівності.

Припустімо, пошукове значення має вигляд green tea & coffee. Його закодована форма, green+tea+%26+coffee, може стояти після назви параметра. Якщо закодувати всю адресу, роздільники, за якими браузер визначає схему, хост, шлях і рядок запиту, також буде приховано.

Цей інструмент використовує urlencode, тому добре підходить для параметрів запиту у форматі HTML-форм. Однак деякі API та сегменти шляху дотримуються правил RFC 3986, де пробіл записується як %20, а не +. Перевір, якого формату очікує система-одержувач: кодування форми з + чи формат RFC 3986 із %20.

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

Літери ASCII та цифри залишаються читабельними. Пробіли перетворюються на знаки плюса, а зарезервовані розділові знаки й текст поза ASCII подаються як закодовані байти.

• hello world перетворюється на hello+world.
• tea & cake перетворюється на tea+%26+cake.
• email=test@example.com перетворюється на email%3Dtest%40example.com.
• 100% ready перетворюється на 100%25+ready.
• café перетворюється на caf%C3%A9, якщо початковий текст використовує UTF-8.

Літери з діакритичними знаками та символи нелатинських систем письма спочатку подаються як байти відповідно до певного кодування символів, зазвичай UTF-8 у вебсередовищі. Потім кожен байт поза дозволеним набором отримує власну відсоткову escape-послідовність. Тому один видимий символ може утворити кілька груп, що починаються з %.

Цифри не потребують особливої обробки. Порожнє введення не створює закодованого вмісту. Дуже довгі вхідні дані можуть істотно збільшитися в обсязі, оскільки кожен закодований байт займає три символи.

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

Зазвичай декодування не вдається, якщо вхідні дані було закодовано за іншими правилами, закодовано кілька разів або вони не є текстом у очікуваному наборі символів.

• Різна обробка пробілів. Декодер форм сприймає + як пробіл, тоді як строгий декодер відсоткових послідовностей може залишити його знаком плюса.
• Подвійне кодування. Знак відсотка в %26 також може перетворитися на %25, у результаті чого утвориться %2526. Після одного декодування буде отримано %26, а не початковий амперсанд.
• Неправильне кодування символів. Якщо байти UTF-8 декодувати як інший набір символів, можуть з'явитися символи заміни або спотворені літери.
• Двійкові, а не текстові дані. Декодовані байти можуть бути зображенням, архівом або іншим файлом, тому спроба показати їх як текст дає незрозумілий результат.
• Неправильний формат або алфавіт. URL-безпечний Base64, стандартний Base64 і відсоткове кодування є різними форматами. Декодер URL не відновить потрібне значення з тексту Base64.

У кодуванні URL немає символів доповнення. Якщо декодер повідомляє про відсутнє доповнення, імовірно, вхідні дані мають формат Base64 або інший формат із доповненням, а не відсоткове кодування.

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

Чи однакові відсоткові послідовності з великими й малими літерами?

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

Чи можна закодувати міжнародне доменне ім'я через кодування URL?

Ні. Для міток домену, наприклад імені із символом é, зазвичай потрібна обробка інтернаціоналізованих доменних імен і ASCII-подання Punycode, що починається з xn--. Відсоткове кодування використовується для інших компонентів URL і не замінює такого перетворення.

Як кодуються переноси рядків і табуляція?

Байти табуляції та переносу рядка кодуються у відсотковому форматі, оскільки їх не можна буквально вставити у звичайне значення URL. Табуляція зазвичай подається як %09, а кодування закінчень рядків залежить від того, які символи використовує джерело, LF чи CRLF.

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

Застосунок може очікувати необроблене значення та кодувати його самостійно, що спричиняє подвійне кодування. Він також може відхилити URL через обмеження загальної довжини або через те, що зарезервований символ було закодовано в структурній частині адреси. Перед кодуванням перевір, який саме компонент потрібно ввести в застосунок.

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

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