Инструменты разработчика · Кодер и декодер URL
Как работает процентное кодирование: от символов до UTF-8 байтов до %XX последовательностей
· Как это работает
URL-кодировка utf-8 процентное кодирование разработчик
Процентное кодирование не кодирует символы; он кодирует байты. В этом посте показано, как символ превращается в UTF-8 байтов, а затем в шестнадцатеричные пары, и почему буква с акцентом занимает две группы %XX, а эмодзи — четыре.
Почему «é» превращается в %C3%A9, а не в %E9 — наблюдение, раскрывающее нижний слой байтов
Когда младший разработчик видит %C3%A9 в URL, процентное кодирование работает с байтами, а не с символами. Символ é занимает не один байт; UTF-8 кодирует его как два: C3 A9. Правило процентного кодирования из RFC 3986 простое: кодируйте каждый байт как знак процента, за которым следуют две шестнадцатеричные цифры. Это различие превращает объяснение из загадочного в логичное.
Понимание процентного кодирования требует понимания UTF-8. Текст необходимо преобразовать в байты с использованием кодировки символов. UTF-8 — это стандарт для URL-адресов и Интернета. Он выражает символы как последовательности байтов переменной длины: ASCII использует один байт, буквы с диакритическими знаками используют два, эмодзи используют четыре. Каждый этап индивидуален: символ, кодовая точка Unicode, UTF-8 байтов, затем %XX пар. Переход к шестнадцатеричному формату без понимания байтов упускает суть.
Правило процентного кодирования из RFC 3986 — один %, за которым следуют две шестнадцатеричные цифры на байт, предпочтительно в верхнем регистре.
RFC 3986 определяет одно правило: каждый байт кодируется как процент, за которым следуют две шестнадцатеричные цифры в верхнем регистре. Незарезервированные символы, не требующие кодирования, — это буквы, цифры, дефис, подчеркивание, точка и тильда. Все остальное должно быть закодировано. Пробелы становятся %20, косые черты становятся %2F, а знак процента становится %25. Это предотвращает нарушение структуры URL специальными символами в значениях запроса.
Пробел кодируется как байт 0x20, превращаясь в %20. Косая черта — 0x2F, становится %2F. Это ASCII символов, требующие одного байта. Акцентированные буквы и смайлы различаются. Знак процента становится %25. Зарезервированные разделители, такие как двоеточия, кодируются для сохранения структуры. Это предотвращает нарушение синтаксического анализа встроенного амперсанда или равенства в параметре запроса. Каждый байт становится %HH.
UTF-8 в качестве предполагаемой кодировки — почему современные URL-адреса имеют UTF-8 и где существуют устаревшие исключения
UTF-8 использует кодировку переменной длины. ASCII от кодовых точек 0 до 127 составляет один байт. Символы от 128 до 2047, включая буквы латинского алфавита с диакритическими знаками, составляют два байта. Символы от 2048 до 65535, распространенные в восточноазиатских алфавитах, имеют длину три байта. Символы выше 65535, включая большинство эмодзи, имеют размер четыре байта. Каждому байту предшествуют биты, указывающие, сколько байтов следует за ним.
Буква с акцентом é — это кодовая точка Юникода U+00E9. UTF-8 кодирует его как два байта: 0xC3 и 0xA9. Процентное кодирование создает %C3%A9. Немецкий ü (U+00FC) кодируется как 0xC3 0xBC, превращаясь в %C3%BC. Испанский – (U+00F1) кодируется как 0xC3 0xB1, превращаясь в %C3%B1. Схема последовательна: первый байт сигнализирует о двухбайтовой последовательности. Одна ударная буква в кодировке расширяется на шесть символов.
Рабочий пример: побайтовое кодирование «café 😀» — кодовые точки, байты UTF-8 и результирующая строка.
Emoji делает байтовый слой очевидным. Эмодзи с большим пальцем вверх 👍 — это код U+1F44D. UTF-8 кодирует его четырьмя байтами: F0 9F 91 8D. Процентное кодирование дает %F0%9F%918D: двенадцать символов для одного символа. Смайлик 😀 (U+1F600) кодируется как F0 9F 98 80, превращаясь в %F0%9F%9880. Четырехбайтовые последовательности становятся символами с двенадцатипроцентной кодировкой.
Смешанный текст показывает, почему важно понимать байты. Фраза «кафе 😀» содержит простой ASCII, акцент и смайлик. Буквы c, a, f кодируются как 63, 61, 66. é кодируется как C3 A9. Пробел кодируется как 20. Эмодзи кодируется как F0 9F 98 80. Результат: «caf%C3%A9%20%F0%9F%9880». Понимание того, какие байты нуждаются в кодировании, делает вывод предсказуемым.
Декодирование в обратном порядке — сбор групп %XX в байты и только потом интерпретация их как UTF-8
Декодирование обращает процесс вспять. Декодер сканирует пары %XX и собирает их в байтовые значения. Увидев %C3%A9, он извлекает байты C3 и A9. При декодировании UTF-8 они интерпретируются как символ é. Если последовательность неполная, например %C3, результатом будет ошибка. Декодер знает из битов префикса UTF-8, что C3 требует второго байта.
В шестнадцатеричных цифрах регистр не имеет значения; %C3%A9 и %c3%a9 декодируются одинаково. RFC допускает использование прописных и строчных букв, хотя прописные буквы предпочтительнее. Но для символов важен регистр: é (как %C3%A9) — это не то же самое, что É (как %C3%89). Сравнение URL должно нормализовать процентное кодирование, иначе существует риск того, что идентичные ресурсы будут рассматриваться как разные. Фреймворки нормализуются перед кэшированием.
Почему регистр не имеет значения в шестнадцатеричных цифрах, но имеет значение в других местах — правила нормализации и сравнение URL
RFC 3986 упоминает punycode для доменных имен и кодировку форм для отправки в качестве отдельных правил. Punycode кодирует доменные имена, отличные от ASCII, без знаков процента для совместимости с DNS. Домен 😀.example становится «xn--js8h.example». Кодирование формы изменяет процентное кодирование с одним исключением: вместо %20 пробелы становятся знаками плюса. В формах, отправленных как application/x-www-form-urlencoded, используйте плюс для пробелов.
Инструмент кодирования URL показывает все три режима: кодирование компонента, кодирование всего URL и кодирование формы. Кодирование компонента с помощью encodeURIComponent кодирует каждый специальный символ, включая разделители, подходящие для значений запроса. Кодировка Whole-URL с encodeURI сохраняет структурные символы для полных URL-адресов. Кодировка формы предназначена для тел POST. Каждый использует UTF-8; они отличаются только тем, какие байты остаются незакодированными.
Punycode и кодирование форм: родственные стандарты, а не расширения процентного кодирования
Байтовая перспектива разрешает URL загадок. Почему для одного смайлика нужно двенадцать символов? Потому что UTF-8 использует четыре байта, каждый из которых становится %HH. Почему в некоторых URL-адресах косая черта содержит %2F, а в других — обычная косая черта? Потому что режим кодирования решает: косая черта в сегменте пути остается незакодированной, но внутри значения запроса она должна быть %2F, чтобы избежать неправильного прочтения.
Думайте в байтах для предсказуемого процентного кодирования. Символ — это кодовая точка Юникода. UTF-8 — это его байтовое представление. Процентное кодирование — это формат передачи. Расширение символов происходит на уровне UTF-8. Шестнадцатеричный регистр не влияет на декодирование, а регистр символов влияет. Недопустимые последовательности байтов завершаются ошибкой в UTF-8 из-за строгих правил префиксов. Инструмент кодирования URL показывает этот прогресс.
Вывод: думайте в байтах — как кодировщик и декодер URL отображает точный результат %XX для любого текста, который вы вставляете в браузер.
Рабочий пример: кодировка «кафе 😀». В слове cafe буквы c, a, f представляют собой ASCII одиночные байты: 63, 61, 66. é — это UTF-8 два байта: C3 A9. Пространство 20. Эмодзи 😀 состоит из четырех байт: F0 9F 98 80. Незарезервированные буквы ASCII остаются видимыми. Результат: «caf%C3%A9%20%F0%9F%9880». Это показывает, почему один смайлик расширяется до двенадцати символов.
Вывод: думайте байтами, а не символами. Процентное кодирование применяется после кодирования UTF-8. Каждый байт становится %HH. UTF-8 переменной длины означает, что символы расширяются по-разному: ASCII становится %XX (два символа), двухбайтовые акценты становятся %XX%XX (шесть символов), четырехбайтовые эмодзи становятся %XX%XX%XX%XX (двенадцать символов). Вставьте текст в инструмент кодирования URL и наблюдайте за прогрессом.