Кодування та декодування URL: пояснення для розробників
Вставте пробіл в URL, або кириличне слово, або амперсанд, що належить вашим даним, а не адресі як такій, — і щось має поступитися. Вебмережа гарантує безпечну передачу лише невеликого, передбачуваного набору символів ASCII. Все інше потрібно обгорнути у формат, з яким згодні маршрутизатори, сервери та браузери. Цей формат називається відсотковим кодуванням, або більш звично — URL-кодуванням, і ця сторінка дозволяє перетворювати текст у будь-якому напрямку безпосередньо у вашому браузері.
Що таке відсоткове кодування насправді
Правило є механічним і простим. Будь-який символ, що не може з'явитися буквально, замінюється знаком %, за яким йдуть дві шістнадцяткові цифри, що відображають байтове значення цього символу. Пробіл стає %20. Знак плюса стає %2B. Символ решітки стає %23. Коли символ відображається на кілька байтів, як більшість тексту не-ASCII у кодуванні UTF-8, ви просто отримуєте кілька триплетів поспіль: знак євро перетворюється на %E2%82%AC. Декодування є зворотним процесом: кожен триплет повертається до свого вихідного байта.
Ця конвенція визначена в специфікації URI (RFC 3986) і навмисно нудна. Нудність — це і є мета. Кожен коректно реалізований HTTP-клієнт і сервер у світі дотримується одних і тих самих правил, тому посилання, правильно закодоване в одному місці, надходить неушкодженим в будь-яке інше.
Чому це необхідно
URL містять два види символів з дуже різними функціями. Зарезервовані символи, такі як /, ?, #, &, = та :, є структурними. Вони вказують парсеру, де закінчується шлях і починається рядок запиту, або де зупиняється один параметр і починається наступний. Якщо ваші фактичні дані містять один із цих символів, його потрібно закодувати, щоб парсер не сплутав його з пунктуацією. Посилання замовлення на кшталт A&B/2024, вставлене в рядок запиту «як є», буде прочитано як два параметри та сегмент шляху.
Є також небезпечні та не-ASCII символи: пробіли, лапки, кутові дужки, літери з діакритикою, емодзі — все, що виходить за межі звичайного ASCII. Вони не мають права з'являтися буквально в URL, оскільки або спотворяться при передачі, або не мають визначеного представлення. Їхнє кодування робить посилання чистими та передбачуваними замість того, щоб покладатися на випадок.
Де це зустрічається в реальній роботі
Рядки запиту — класичний випадок. Кожне значення, яке ви додаєте до ?key=..., має бути закодованим, щоб введені користувачем дані не могли порушити структуру. Те саме стосується HTML-форм, що надсилаються у форматі application/x-www-form-urlencoded, де браузер кодує значення полів автоматично (і, за традицією, замінює пробіли на +, а не %20). Ви також зустрінете це при побудові посилань на сторінки з нелатинськими назвами, при ручному формуванні API-запитів, при передачі цільових адрес переспрямування як параметрів і при налагодженні ситуацій, коли запит, що виглядає нормально в адресному рядку, надходить на сервер спотвореним.
encodeURI проти encodeURIComponent
JavaScript має два кодувальники, і вибір неправильного є поширеним джерелом помилок. Різниця полягає в масштабі. encodeURIComponent призначений для одного фрагмента даних, наприклад одного значення параметра запиту. Він кодує майже все, включаючи зарезервовані символи /, ?, :, @, &, =, + і #. Це саме те, що потрібно, коли дані можуть містити ці символи як звичайний текст.
encodeURI призначений для цілої адреси, яка має залишатись робочою. Він залишає структурні символи недоторканими, тому косі риски, двокрапки та знаки питання, що утримують URL, зберігаються. Використовуйте його, коли маєте повний URL і хочете лише прибрати пробіли або символи не-ASCII; звертайтеся до encodeURIComponent завжди, коли вставляєте значення у більший URL. Просте правило: кодуйте весь URL за допомогою encodeURI, а значення, що вставляються, — за допомогою encodeURIComponent.
Все залишається на вашій машині
Цей інструмент працює повністю у вашому браузері. Текст, який ви вставляєте, кодується або декодується локально за допомогою тих самих стандартних підпрограм і ніколи не передається на сервер, що робить його безпечним для токенів, підписаних параметрів або будь-чого іншого, що ви не хочете передавати по мережі. Якщо ви працюєте з іншими текстовими перетвореннями, конвертер Base64 знаходиться поруч, і ви можете переглянути повний набір інструментів для розробників для повсякденних завдань.
Часті запитання
Що означає %20 в URL?
Це закодований пробіл. Символ пробілу не допускається буквально в URL, тому він замінюється знаком відсотка та шістнадцятковим значенням 20, яке є байтовим значенням пробілу.
Чому іноді замість %20 бачу знак плюса?
HTML-дані форми типу application/x-www-form-urlencoded за традицією кодують пробіли знаком плюса. У звичайному шляху або запиті пробіл кодується як %20. Обидва декодуються назад до пробілу у відповідному контексті.
Коли слід використовувати encodeURIComponent замість encodeURI?
Використовуйте encodeURIComponent для одного значення, що вставляється в URL, наприклад параметра запиту, оскільки він кодує також зарезервовані символи. Використовуйте encodeURI для повної адреси, коли хочете зберегти косі риски, двокрапки та знаки питання, що утримують її разом.
Чи змінює URL-кодування значення моїх даних?
Ні. Кодування є повністю зворотним. Декодування результату дає точно вихідний текст, байт за байтом, якщо на обох кінцях використовується один і той самий набір символів.
Як обробляються символи не-ASCII, наприклад букви з діакритикою або емодзі?
Вони спочатку перетворюються на байти UTF-8, а потім кожен байт стає власним відсотковим триплетом. Тому одна буква з діакритикою або емодзі може розгорнутися в кілька триплетів у закодованому виводі.
Чи передається мій текст на сервер при використанні цього інструменту?
Ні. Кодування та декодування відбуваються повністю у вашому браузері. Нічого з того, що ви вставляєте, не завантажується, тому це безпечно для приватних або чутливих рядків.