Инструменты разработчика · Кодер и декодер URL
Что за вас кодирует конструктор URL: наборы процентного кодирования браузера
· Как это работает
URL-кодировка javascript что веб-API
URL API автоматически процентно кодирует некоторые символы и оставляет другие в покое, в зависимости от того, в какой части URL они попадают. В этом посте объясняются наборы кодировок WHATWG и как прогнозировать выходные данные.
Пространство, которое стало %20, и | это осталось — конкретный случай, когда новый URL() частично закодировал путь
При запуске нового URL("https://example.com/hello world") пространство автоматически становится %20. Но новый URL("https://example.com/hello|world") оставляет канал нетронутым. Эта разница не случайна. Стандарт WHATWG URL определяет отдельные наборы символов для кодирования для каждого компонента URL: путь, запрос, фрагмент и информация о пользователе имеют свои собственные правила. Понимание этих наборов означает прогнозирование того, что будет делать конструктор.
Пространство требует процентного кодирования, поскольку оно небезопасно для HTTP и ухудшает читаемость. Канал отличается: это не зарезервированный символ, который разбивает структуру, поэтому браузер оставляет его в покое. Граница между безопасностью и читабельностью проводится WHATWG, а не догадками. Тестирование «привет, мир» показывает кодировку; тестирование «hello|world» выявляет границы каждой части URL.
Один URL, несколько наборов кодирования — путь, запрос, фрагмент и информация о пользователе имеют свой собственный список символов для экранирования.
Один URL содержит несколько регионов, каждый из которых имеет свои собственные правила кодирования. Путь следует за одним набором, запрос — за другим, фрагмент — за третьим, информация о пользователе — за четвертым. Пробел становится %20 в пути и запросе. Знак равенства остается в запросе, где он разделяет ключи и значения, но encodeURIComponent превращает его в %3D. Конструктор URL знает свой контекст и применяет правильные правила для каждой части.
Наборы кодирования точны и малы. Путь имеет свой собственный список символов; запрос имеет аналогичный, но другой список. Это отражает, какие символы имеют структурное значение. Косая черта разделяет сегменты пути, поэтому encodeURIComponent кодирует его как %2F. Во фрагменте может существовать косая черта, ничего не нарушая. Понимание правил WHATWG означает прогнозирование вывода без запуска кода.
Почему процентное кодирование является односторонним: то, что остается закодированным, остается таким
Конструктор URL выполняет одностороннюю нормализацию. Передайте "%20" новому URL, и он выдаст %20 без изменений. Конструктор распознает его как уже закодированный и оставляет в покое. Вот почему двойное кодирование имеет значение: закодируйте один раз, пройдите через конструктор, и кодировка останется неизменной. Конструктор не декодирует, не переинтерпретирует и не перекодирует; он читает вперед.
Это одностороннее свойство влияет на приложения, считающие URL.href каноническим. Если вы объединяете пользовательский ввод со своим путем, ввод нормализуется, но не декодируется. Значение типа «my+file» остается как есть или в некоторых контекстах становится «my%2Bfile». Более поздний код, использующий decodeURIComponent, может читать плюс как пробел из данных формы. Конструктор нормализуется один раз; после этого ваше значение фиксировано.
Рабочий пример: передача одной и той же беспорядочной строки через new URL() и чтение href, pathname и searchParams — три разных представления
Возьмите «hello world&foo=bar|test#anchor» и пропустите его через новый URL с другими компонентами. Пространство становится %20 повсюду. Амперсанд в пути остается (никакого структурного значения), но и в запросе он тоже остается (разделяет параметры, поэтому при нормализации потеряется граница между "q=" и "foo=bar"). Канал и хеш ведут себя по-разному в зависимости от местоположения.
Чтение href, pathname и searchParams показывает три разных представления. имя пути показывает закодированный путь без схемы, хоста или запроса. searchParams предоставляет декодированные параметры, поэтому «hello+world» из данных формы становится пробелом. Свойство поиска сохраняет литеральную строку. href показывает полный нормализованный файл URL. Они сосуществуют на одном объекте; какой вариант использовать, зависит от вашего следующего шага.
URLSearchParams и правило кодирования формы — почему он выдает + для пробелов, а имя пути — %20
URLSearchParams применяет кодировку формы: пробел становится плюсом, а не %20. new URLSearchParams({q: "hello world"}) выдает "q=hello+world", а не "q=hello%20world". Это историческое правило приложения/x-www-form-urlencoded. Но если вы передадите эту строку как необработанный запрос в новый URL, плюс останется плюсом; только URLSearchParams декодирует его как пробел. Конструктор верен тому, что видит.
Эта разница со знаком плюс вызывает распространенные ошибки. URL в адресной строке использует %20 для пробелов. Данные формы используют плюс. Если вы декодируете с помощью decodeURIComponent (который буквально читается как плюс) вместо URLSearchParams.get, пробелы становятся плюсовыми символами. Кодер и декодер URL показывает и то, и другое: вставку «hello+world» и сравнение режимов компонента и формы, чтобы увидеть, где появляется пробел.
Сравнение с encodeURI — где они совпадают, а где расходятся
Конструктор URL и encodeURIComponent — это разные инструменты. encodeURIComponent кодирует почти все, кроме незарезервированных букв, цифр и - _ . ! ~ * ' ( ). Он не предполагает никакого контекста. Конструктор URL анализирует фактический URL и применяет правила WHATWG для каждого компонента. encodeURIComponent превращает «hello/world» в «hello%2Fworld»; новый URL воспринимает косую черту как разделитель пути. Тот же вход, другой выход.
Используйте encodeURIComponent при создании URL путем объединения частей. Используйте URLSearchParams или конструктор URL для полных или частичных URL-адресов. Не используйте encodeURIComponent в целом URL; вы испортите схему. Сравните результат с намерением. Браузер применяет мнения структуры URL, а новый URL реализует их. Кодер и декодер URL отображает оба вида рядом.
Что здесь не распространяется — синтаксический анализ хоста, IDNA и специальные и неспециальные схемы.
Стандарт WHATWG URL является источником истины, хотя его чтение требует терпения. Наборы кодирования определяются во фрагментах алгоритма, а не в простых списках. На практике понимание принципа имеет большее значение, чем запоминание наборов. Путь позволяет использовать больше символов (косая черта является структурной); запрос имеет свои правила; фрагмент имеет наименьшее количество ограничений (обрабатывается на стороне клиента, никогда не отправляется на серверы). Каждый компонент имеет свои собственные правила; знание этого подскажет вам, где искать.
Нормализация и валидация — это разные границы. Конструктор нормализует: чистит проц-кодировку, применяет правила компонентов, придаёт каноническую форму. Он не проверяет: выдаются недопустимые символы, но принимаются пустые хосты. Конструктор строг в отношении формата, но снисходителен в отношении интерпретации. Для точного соответствия спецификациям прочтите раздел WHATWG о байтах с процентным кодированием. Для повседневного построения используйте URLSearchParams, URL API и реальные примеры.
Вывод: у синтаксического анализатора есть мнения — как кодировщик и декодер URL показывают вам простое процентное кодирование значения или адреса, чтобы вы могли сравнить его с тем, что выдал браузер.
Неподдерживаемые функции WHATWG здесь включают анализ хоста с преобразованием IDNA (международные доменные имена в ASCII) и обработку специальных и неспециальных схем. Файл: URL-адреса используют авторизацию с двойной косой чертой; данные: URL-адреса этого не делают. Конструктор обеспечивает соблюдение этих правил. Преобразование имен хостов и определение специального статуса относятся к чтению спецификаций, а не к процентному кодированию. Это важно при построении URL-адресов по разным схемам.
Проверьте свою конструкцию URL, сравнив интерпретацию браузера с ожиданиями. Создайте новый URL, прочитайте важные свойства: href для полной формы, имя пути для пути, поиск необработанного запроса, searchParams для декодированного. Если результат вас удивил, вставьте его в кодировщик и декодер URL и выполните преобразование шаг за шагом. Инструмент показывает нормализованный вывод наряду с необработанным кодированием, показывая разницу. Понимание наборов WHATWG означает понимание выбора браузера и того, как с ним работать.