URL кодировщик / декодер

Кодируйте и декодируйте URL и строки запросов с процентным кодированием. Выберите режим компонента, полного URI или данных формы и конвертируйте в обоих направлениях по мере ввода.

Процентно кодируйте текст для URL или декодируйте обратно. Вводите в любое из полей, и другое обновляется мгновенно. Выберите режим, соответствующий тому, где будет использоваться значение: отдельный параметр запроса, целый URL или отправка HTML-формы.

Процентное кодирование, разъяснённое правильно

Почему URL вообще нужно кодировать

URL — это не произвольный текст. Символы вроде ?, #, &, / и = зарезервированы: они несут структурный смысл, обозначая, где заканчивается путь и начинается запрос, или отделяя один параметр от следующего. Если значение, которое вы хотите передать, случайно содержит один из этих символов, парсер на другом конце неверно прочитает ваш URL. Процентное кодирование решает это, заменяя проблемный байт на % с последующим его двузначным шестнадцатеричным значением, поэтому & внутри значения передаётся как %26 и никогда не может быть принят за разделитель.

Незарезервированные, зарезервированные и всё остальное

RFC 3986 делит пространство символов на три группы.

  • НезарезервированныеA-Z a-z 0-9 - . _ ~. Они никогда не нуждаются в кодировании и должны оставаться как есть. Кодировать их всё равно законно, но получаются менее красивые URL, и это может сломать наивные сравнения строк.
  • Зарезервированные: / ? # [ ] @ ! $ & ' ( ) * + , ; =. Они безопасны только там, где призваны быть структурными. Внутри значения они должны кодироваться.
  • Всё остальное — пробелы, управляющие символы и любой не-ASCII текст. Они всегда требуют кодирования.

Не-ASCII текст и UTF-8

Процентное кодирование работает с байтами, а не с символами, поэтому текст сначала должен быть преобразован в байты. Современный ответ — всегда UTF-8. Знак состоит из трёх байтов в UTF-8 (E2 82 AC), поэтому он кодируется как %E2%82%AC. Старые системы иногда использовали собственную кодировку страницы, поэтому вы изредка всё ещё встречаете mojibake-URL, закодированный как Latin-1 или GBK. Этот инструмент использует UTF-8 повсюду, что соответствует ожиданиям браузеров и всех современных серверных фреймворков.

Три режима и когда каждый из них ошибочен

encodeURIComponent — это безопасное умолчание, и он экранирует все зарезервированные символы. Используйте его всякий раз, когда вставляете значение в URL. encodeURI намеренно сохраняет зарезервированные символы, чтобы полный URL оставался целым — используйте его только чтобы причесать уже собранный URL, никогда для отдельного параметра, потому что он с радостью оставит & в вашем значении и испортит строку запроса.

Режим формы — странный на фоне остальных. Сериализация application/x-www-form-urlencoded, которая предшествует современным спецификациям URL, кодирует пробел как + вместо %20. Оба варианта корректны в строке запроса, и серверы принимают любой, но если вы вручную строите тело POST-запроса, вам следует соответствовать соглашению формы.

Неоднозначность +

Поскольку кодирование формы придаёт + специальный смысл, буквальный знак плюса в значении формы сам должен кодироваться как %2B. Это самая распространённая ошибка кодирования на практике: строка base64 или номер телефона в международном формате передаётся как есть, и принимающая сторона превращает каждый + в пробел. Если ваши данные могут содержать знаки плюса, либо кодируйте их явно, либо избегайте режима формы.

Двойное кодирование

Кодирование уже закодированной строки превращает каждый % в %25, поэтому %20 становится %2520. Обычно это ошибка — она возникает, когда значение кодируется кодом приложения, а затем снова — фреймворком или прокси. Если вы видите %25 в URL там, где не планировали буквальный знак процента, перед вами двойное кодирование. Двойное декодирование восстанавливает оригинал, но настоящее решение — убрать один из шагов кодирования.

Примечание open source: реализовано с использованием стандартных функций JavaScript encodeURIComponent, encodeURI, decodeURIComponent и decodeURI. Сторонние библиотеки не используются.

Часто задаваемые вопросы

Использовать %20 или + для пробела?
Оба принимаются в строке запроса. Используйте %20, если хотите одно представление, валидное везде, включая сегмент пути, где + означает буквальный плюс. Используйте + только при создании данных application/x-www-form-urlencoded.
Почему мой знак плюса превращается в пробел?
Что-то в цепочке разбирает значение как данные формы, где + — это кодирование пробела. Кодируйте буквальные знаки плюса как %2B перед отправкой.
Нужно ли кодировать слэш?
Только когда слэш является частью значения, а не разделителем пути. Имя файла, содержащее слэш, должно передаваться как %2F, иначе сервер прочитает его как дополнительный уровень каталога. Учтите, что некоторые серверы по умолчанию отвергают %2F в путях как меру защиты от обхода.
Чувствительно ли кодирование к регистру?
Шестнадцатеричные цифры могут быть в верхнем или нижнем регистре, и оба декодируются одинаково, но RFC 3986 рекомендует предпочитать верхний регистр. %2F и %2f — один и тот же символ; %2F — каноническое написание.
Почему декодирование не удаётся для моей строки?
За знаком процента должны следовать ровно две шестнадцатеричные цифры. Голый % или что-то вроде %zz некорректны, и декодер выбрасывает ошибку. Если ваш текст законно содержит знак процента, он должен был быть закодирован как %25.
Отправляет ли это мои данные куда-либо?
Нет. Кодирование и декодирование выполняются в вашем браузере с использованием встроенных URI-функций. Ничего не загружается.