Инструменты разработчика · Кодер и декодер URL
encodeURI vs encodeURIComponent: какие символы каждый оставляет в покое
· Как это работает
URL-кодировка javascript рабочий процесс разработчика
Две функции JavaScript различаются ровно на одиннадцать символов, и выбор неправильной функции либо нарушает URL, либо не позволяет экранировать значение. В этом посте подробно описаны наборы и дано правило, которое вы можете запомнить.
Поиск, который выдал все, потому что & в «R&D» разделил запрос — конкретная ошибка не той функции
Поиск R&D может случайно вернуть результаты для R, если код вручную создает ?q=R&D. Амперсанд — это разделитель между параметрами запроса; оно не сохраняется как часть q, если вы не закодируете значение. Выбор encodeURI для этого небольшого фрагмента — это ошибка, а не ошибка сервера. Самым безопасным вариантом в коде приложения часто является URLSearchParams, но понимание двух примитивов JavaScript значительно упрощает отладку существующего кода.
Что общего у обеих функций — незарезервированный набор, который они никогда не трогают, и процентное кодирование UTF-8, которое они обе применяют.
Оба метода оставляют ASCII букв, цифр и незарезервированный знак препинания - _ . ! ~ * ' ( ) не затрагивается правилами кодирования JavaScript. Они преобразуют символы, отличные от ASCII, в UTF-8 байты перед записью тройки процентов: é становится %C3%A9, а не одной латиницей-1 byte. Они также кодируют пробел как %20. Процентное кодирование заключается в сохранении структуры URI; это не экранирование HTML, проверка ввода или защита от вредоносного сценария на принимающей странице.
Одиннадцать символов кодируют только сохранение URI — ; , / ? : @ & = + $ # и почему каждый из них имеет структурное значение в URL
encodeURI дополнительно сохраняет одиннадцать структурных символов, которые кодирует encodeURIComponent: ; , / ? : @ & = + $ #. Если оставить косую черту и вопросительный знак для полного адреса, путь и синтаксис запроса сохраняются. Для значения запроса пропуск & или = приведет к изменению списка параметров, а неэкранированный # может начать фрагмент. Функции различаются именно тем, что одна предназначена для всего адреса, а другая — для компонента внутри этого адреса.
Действующее правило: значения получают encodeURIComponent, полные URL-адреса получают encodeURI — и почему «полный URL» встречается реже, чем кажется
Значения почти всегда получают encodeURIComponent; полные, уже структурированные адреса — менее распространенный случай encodeURI. Для URL, который вы создаете программно, используйте URL API для обработки пути и параметров поиска вместо объединения закодированных и необработанных фрагментов. Не кодируйте весь URL с помощью encodeURIComponent, а затем ожидайте, что косая черта и двоеточие будут продолжать вести себя как разделители. И наоборот, не передавайте термин запроса пользователя через encodeURI и оставляйте его амперсанд активным.
Рабочий пример: одна и та же строка через обе функции — таблица вывода значения с пробелами, &, / и акцентом.
Возьмите R&D/cafe в качестве одного значения запроса. encodeURIComponent возвращает R%26D%20%2F%20caf%C3%A9, защищая амперсанд и косую черту. encodeURI возвращает R&D%20/%20caf%C3%A9, с сохранением структурной пунктуации; наивный префикс ?q= теперь создаст непреднамеренный разделитель. Оба кодируют пробел и акцент, поэтому тест, использующий только «привет, мир», упускает важное различие. Сравните сгенерированные строки в ToolAcre, затем вставьте их в парсер URL и проверьте, сколько параметров запроса появляется.
Распространенные ошибки — полное кодирование URL с помощью encodeURIComponent и декодирование с использованием неправильного аналога.
Кодирование полного URL как одного компонента дает %3A%2F%2F, где потребитель ожидал://. Декодирование всего адреса перед его проверкой может повторно ввести зарезервированные разделители с новыми значениями. Также избегайте двойного кодирования значения, уже содержащего %26: сам знак процента может стать %25, поэтому второй уровень декодирования может снова изменить значение. Соедините encodeURIComponent с decodeURIComponent для компонента и рассматривайте неправильные экранированные проценты как ошибки ввода.
Чего это не касается — кодирование формы с помощью + и создание URL-адресов с помощью URLSearchParams.
Кодировка запроса формы HTML использует знак плюса для пробела в приложении /x-www-form-urlencoded,, который отличается от вывода %20 этих двух функций. URLSearchParams обрабатывает эти правила формы за вас. В этой статье не рассматривается нормализация пути, преобразование имени хоста в Юникоде или решение о том, безопасно ли запрашивать декодированный URL; Кодирование URL — это этап представления, а не политика авторизации.
Вывод: кодируйте части, а не целое — как кодировщик и декодер URL отображают оба режима, чтобы вы могли увидеть разницу на собственном входе.
Запоминающаяся граница — это части и целое: значение параметра — это часть, поэтому используйте encodeURIComponent или URLSearchParams. Кодер и декодер URL отображает обе функции браузера для одной и той же строки и сохраняет эксперимент локальным. Проверьте ввод, содержащий &, =, #, косую черту и акцент, прежде чем решить, что два кодировщика взаимозаменяемы.