Почему твой URL сломался (и как это исправить)
Кодирование URL не опционально. Вот почему специальные символы вызывают проблемы и что с этим делать.
Ты вставляешь URL в email. Кто-то кликает по нему. Получают 404.
URL выглядел нормально. Но где-то между твоим браузером и их, пробел стал %20, амперсанд исчез, или плюс превратился во что-то совсем другое.
Кодирование URL существует, потому что URL могут содержать только определённые символы. Всё остальное нужно переводить.
Проблема со специальными символами
URL были разработаны в ранние дни интернета с ограниченным набором символов. Это безопасно:
A-Z a-z 0-9 - _ . ~
Всё остальное? Потенциально проблематично.
Пробелы становятся %20 или + в зависимости от контекста. URL с буквальным пробелом сломается.
Амперсанды (&) разделяют параметры запроса. Если твои данные содержат амперсанд, парсер URL думает, что начинается новый параметр.
Вопросительные знаки (?) сигнализируют начало строк запроса. Один в твоих данных путает всё.
Когда кодирование происходит автоматически
Браузеры кодируют URL, когда ты их печатаешь. Вот почему ты можешь вставить "рестораны нью-йорка" в Google, и это работает.
Но автоматизированные системы часто не кодируют. API, скрипты, email-клиенты — они могут передавать твой URL точно как написано. Если он содержит небезопасные символы, он ломается.
Ловушка двойного кодирования
Вот где это становится раздражающим.
Ты кодируешь URL. Затем ты помещаешь его в другой URL как параметр. Система кодирует его снова. Теперь %20 становится %2520.
При декодировании ты получаешь %20 вместо пробела.
Это постоянно происходит с URL перенаправлений, параметрами отслеживания и OAuth-колбэками. Если твой URL выглядит искажённым с лишними знаками процента, проверь на двойное кодирование.
Частые ошибки кодирования
Кодирование всего URL. Не надо. Кодируй только значения, а не структуру. https:// не должен становиться https%3A%2F%2F.
Забываешь про знак плюс. В строках запроса + означает пробел. Если твои данные имеют буквальный знак плюс, ему нужно кодирование, или он исчезнет.
Предполагаешь, что кодирование идемпотентно. Кодирование уже закодированной строки производит другой вывод. Проверь, закодировано ли что-то, перед кодированием.
Практические примеры
Поисковый запрос с пробелами:
До: https://example.com/search?q=new york pizza
После: https://example.com/search?q=new%20york%20pizza
URL колбэка как параметр:
callback = https://mysite.com/auth?token=abc
Закодирован: https%3A%2F%2Fmysite.com%2Fauth%3Ftoken%3Dabc
Email-адрес в URL:
До: user+tag@example.com
После: user%2Btag%40example.com
Отладка проблем с URL
Проверь фактический запрос. Инструменты разработчика браузера показывают тебе, что отправляется. Сравни с тем, что ты ожидал.
Декодируй и инспектируй. Если URL не работает, декодируй его, чтобы увидеть, что сервер фактически получает.
Тестируй со специальными символами. Включай пробелы, амперсанды и знаки плюс в свои тестовые данные. Если работает с "test", но не работает с "test & verify", у тебя проблема с кодированием.
Кодирование URL — это одна из тех вещей, которая работает невидимо, пока не перестаёт. Понимание правил помогает тебе отлаживать быстрее, когда URL таинственно ломаются.