Инструменты разработчика · Кодер и декодер URL
RFC 3986 зарезервированные и незарезервированные символы: что говорит стандарт URI
· Фон
URL-кодировка rfc3986 процентное кодирование
RFC 3986 делит символы на зарезервированные, незарезервированные и все остальное, и это разделение объясняет каждое встреченное вами правило процентного кодирования. Этот пост ясно читает соответствующие разделы.
RFC 3986 зарезервированные и незарезервированные символы — что важно при создании URL-адресов
RFC 3986 делит символы на три категории: незарезервированные, зарезервированные и все остальное, что необходимо закодировать. Незарезервированные символы никогда не нуждаются в кодировании — это буквы, цифры, дефис, точка, подчеркивание и тильда. RFC явно перечисляет их в разделе 2.3, заявляя, что их можно безопасно оставлять незакодированными в любом контексте URI. Тестирование в кодировщике и декодере URL с этими символами показывает, что они проходят без изменений. Зарезервированные символы подразделяются на ген-разделители (: / ? # [ ] @) и подразделители (! $ & ' ( ) * + , ; =), каждый из которых имеет структурное значение в разных компонентах URL.
Когда символ нуждается в кодировании? Зарезервированные символы должны кодироваться в процентах только там, где они создают неоднозначность. Косая черта отмечает сегменты пути; в значении запроса должно быть %2F. Амперсанд разделяет параметры; & в значении требует %26. Незарезервированные символы никогда не нуждаются в кодировании — дефис остается дефисом. Стандарт URL обеспечивает правильный анализ. Тестирование с помощью кодера и декодера URL: ввод «hello/world» с помощью encodeURIComponent приводит к появлению «hello%2Fworld»; с encodeURI он сохраняет косую черту.
Незарезервировано: буквы, цифры, дефис, точка, подчеркивание и тильда — символы, которые никогда не требуют кодирования и никогда не должны кодироваться.
При процентном кодировании используется %HH, где HH — шестнадцатеричная запись. ASCII буква A (код 65) становится %41. Не-ASCII é требует кодировки UTF-8: é (U+00E9) становится %C3%A9. Современные стандарты определяют UTF-8 одинаково во всех браузерах.
Полные URL-адреса должны иметь неповрежденный структурный синтаксис; Для значений запроса нужны внутренние зарезервированные символы, которые безвредны. Параметр запроса ?q=R&D должен кодировать & как %26, если используется вручную, иначе амперсанд становится разделителем. Значения с косой чертой преобразуются в %2F в режиме компонента. Компонентное кодирование (encodeURIComponent) решает эту проблему, кодируя все, кроме незарезервированных букв, цифр и - _ . ! ~ * ' ( ). Тестирование ясно показывает разницу между методами.
Зарезервировано: ген-разделители и суб-разделители — две группы, их члены и их структурные роли.
Строки запроса демонстрируют, почему зарезервированные символы имеют значение. Амперсанд разделяет пары ключ=значение: ?utm_source=email&utm_campaign=sale означает два параметра. Внутри значения неэкранированный амперсанд завершает пару. Равно отделяет ключи от значений. Анализ происходит на нескольких уровнях; каждый применяет одни и те же правила.
Символы, требующие кодирования в значениях запроса, включают амперсанд, равенства, решетку, вопросительный знак, пробелы и буквы, отличные от ASCII. Хэш самый хитрый: #anything становится идентификатором фрагмента, который никогда не отправляется на сервер. Имена кампаний, заканчивающиеся хешем, теряют все после себя, прежде чем запрос покинет браузер. Пробелы должны стать %20. Тестирование с помощью кодера и декодера URL показывает режимы компонента и формы. Понимание позиции определяет необходимость кодирования.
Когда необходимо закодировать зарезервированные символы — только там, где они могут быть ошибочно приняты за разделитель, компонент за компонентом
Процентное кодирование сохраняется в RFC 3986. Незарезервированный набор остается небольшим, что обеспечивает мобильность. Незарезервированные символы с процентным кодированием можно декодировать без каких-либо изменений. Декодирование %41 в A правильное, поскольку A не зарезервировано. Декодирование %2F в / меняет значение, когда косая черта является данными, а не разделителем. RFC 3986 раздел нормализации 6 описывает синтаксические подходы.
Зарезервированные персонажи на разных позициях выполняют разные роли. Двоеточием на схеме обозначается схема: граница полномочий; двоеточие в информации о пользователе — это данные. Вопросительный знак открывает раздел запросов; косая черта в значении запроса является буквальной. Хэш отмечает начало фрагмента. Позиция определяет необходимость кодирования. Строки запроса содержат значения, которые сами являются URI. Кодирование перенаправления URL, например https://example.com/page?param=value, в качестве параметра требует кодирования косых черт и двоеточий в %2F и %3A. Контекст всегда определяет безопасные символы.
Рабочий пример: классификация каждого символа реального URL — незарезервировано, зарезервировано как разделитель, зарезервировано как данные
RFC 1738 (1994) считал многие символы небезопасными. Поскольку развертывания были стандартизированы на UTF-8, более поздние стандарты ослабили ограничения. Тильда (~) иллюстрирует эволюцию: RFC 1738 требуется %7E, RFC 2396 (1998) тильда перемещена в незарезервированную позицию, RFC 3986 подтверждена незарезервированный статус. Эволюция отражает уроки развертывания. Стандарты сохраняют обратную совместимость.
Нормализация RFC позволяет декодировать незарезервированные символы с ненужной процентной кодировкой. %41 безопасно нормализуется до A. Закодированные зарезервированные символы, такие как %2F, никогда не декодируются; изменение значения нарушает структуру. Современный консенсус использует RFC 3986 в качестве эталонного базового уровня. Кодер и декодер URL следует за RFC 3986 повсюду, предлагая фиксированную ссылку, отдельную от поведения браузера. WHATWG URL Стандарт добавляет наборы кодировок для конкретных компонентов помимо RFC. Сосуществуют стандарты: RFC 3986 для общего анализа URL, WHATWG для веб-браузеров. Библиотеки различаются; проверьте документацию.
Рекомендации по нормализации в разделе 6 — шестнадцатеричный регистр, правила безоговорочного декодирования и сегментов пути.
Тестирование на соответствие RFC 3986 гарантирует работоспособность URL-адресов в программном обеспечении на протяжении десятилетий. Кодер и декодер URL дают RFC 3986 базовую линию кодирования для применения к созданным компонентам. Прочтите стандартную документацию, объясняющую каждое решение по кодированию в библиотеках URL. WHATWG URL основан на RFC 3986, а не заменяет его полностью. Создаете URL-адреса для обычных браузеров? Следуйте RFC 3986; браузеры применяют правила WHATWG сверху. Старые системы? Тестируйте реальные реализации. Нормализация для хранения? Применяйте RFC 3986 последовательно. Понимание различия зарезервированных/unreserved подскажет вам безопасные символы.
Кодировка URL не является очисткой безопасности. Каждый контекст — SQL, HTML, JavaScript, URI — требует собственной кодировки вывода. Процентное кодирование защищает только структуру URL. Примените правильную защиту на правильном слое.
Что здесь не распространяется — различные наборы кодирования стандарта WHATWG URL и обработка IRI.
RFC 2396 (1998) уточняет наборы символов более строго, чем RFC 1738. Он формализовал зарезервированные символы, служащие структуре URI, и незарезервированные как литеральные данные. Незарезервированное расширение, включая дефис, точку, подчеркивание и тильду поверх исходных определений. RFC 2396 ввел различие между ген-разделителями (:, /, ?, #, [, ], @) и подразделителями (!, $, &, ', (, ), *, +, ,, ;, =). Каждая группа имеет разные структурные роли в URL-адресах. Именование уточняет разделение зарезервированных символов на две группы. Знание имен помогает в технических дискуссиях.
RFC 3986 (2005) — современный эталон. Он сохранил зарезервированное различие/unreserved, но упростил обозначения. Органы по стандартизации не разрывают сеть задним числом. Кодируйте сознательно, зная свой стандарт. Кодер и декодер URL предоставляют ссылку RFC 3986.
Вывод: стандарт краток и точен — как два режима кодера и декодера URL соответствуют кодированию данных и сохранению разделителей.
Выбор стандартов зависит от контекста. Создаете URL-адреса для обычных браузеров? Следуйте RFC 3986; браузеры применяют правила WHATWG. Старые системы? Тестируйте реальные реализации. Нормализация для хранения? Применяйте RFC 3986 последовательно. Правила процентного кодирования эволюционировали от консервативных RFC 1738 через уточненные RFC 2396 и RFC 3986 к многоуровневому WHATWG URL Standard. Каждое поколение отражало опыт. Современные строители следуют RFC 3986 или WHATWG контекстуально. Старые и новые URL-адреса сосуществуют, что требует продумывания совместимости. Понимание категорий предотвращает ошибки кодирования.
Перед развертыванием убедитесь, что URL-адреса кодируются правильно. Кодер и декодер URL демонстрирует сквозные правила RFC 3986. Посмотрите точные шестнадцатеричные значения и поймите, какие символы кодируются. Используйте этот инструмент при создании URL-адресов путем объединения частей. RFC 3986 наборы символов раздела зарезервированных и незарезервированных категорий для последовательного анализа URI.