Конвертер Punycode / IDN

Так что Punycode — не язык, не шрифт и не код страны — это перевод между двумя записями одного и того же имени. Запись в Unicode называется U-меткой (中文.com, bücher.de), запись в ASCII называется A-меткой (xn--fiq228c.com, xn--bcher-kva.de), а вся идея помещения международных имён в DNS называется IDN (интернационализированные доменные имена) или IDNA — набор правил, построенных поверх неё.

Она существует, потому что DNS создавалась в начале 1980-х вокруг намеренно крошечного алфавита. Имя хоста, которое путешествует через DNS, в файл зоны, кэш резолвера, строку журнала или сертификат TLS, должно быть обычным ASCII — в формате передачи просто нет поля для чего-то другого. Punycode — это обходной путь: он позволяет имени, не являющемуся ASCII, путешествовать как будто оно ASCII, а принимающей стороне восстановить исходные символы точно. Поэтому китайский домен вообще работает в браузере, а xn-- — единственная строка, которую вы увидите везде, где Unicode-запись нельзя отправить.

Что вы вводите (U-метка)	Что получает DNS (A-метка)	Что это значит
中文.com	xn--fiq228c.com	Китайские слова «китайский язык»
中国	xn--fiqs8s	«Китай» по-китайски
例え.jp	xn--r8jz45g.jp	Японские примеры
bücher.de	xn--bcher-kva.de	Немецкое bücher, «книги»
münchen.de	xn--mnchen-3ya.de	Мюнхен
😂.com	xn--e28h.com	Метка из эмодзи — допустима в кодировании, но не в большинстве реестров

Сравнение длины, которое стоит запомнить: 中文 — 2 символа и 6 байт в UTF-8, а xn--fiq228c — 11 ASCII-байт. Punycode обычно делает имя длиннее, но никогда короче.

Возьмите bücher и посмотрите на три шага. Движок называется bootstring, а весь алгоритм занимает всего несколько десятков строк кода (его можно прочитать в скрипте этой страницы).

1. Скопируйте обычные символы в начало. Каждый базовый ASCII-символ копируется в исходном порядке и остаётся читаемым: bücher → bcher. Поскольку что-то было скопировано и что-то осталось, в качестве границы добавляется один -: bcher-.
2. Запишите остальное как числа в системе по основанию 36. Оставшиеся символы обрабатываются в порядке возрастания кодовых точек, и каждый записывается как число переменной длины в системе по основанию 36, где a=0 … z=25 и 0=26 … 9=35. Для bücher оставшийся символ ü становится цифрами kva.
3. Прикрепите префикс. Закодированная часть, добавленная к скопированной, даёт bcher-kva, а в контексте домена записывается как xn--bcher-kva.

Хитрость, которая делает это изящным, — в том, что содержат эти числа в системе по основанию 36: не сам символ, а дельту — насколько символ отстоит от предыдущей закодированной кодовой точки плюс его позицию внутри строки. Кодировщик обходит кодовые точки по возрастанию, и каждая группа цифр описывает позицию и расстояние. После каждого символа общее число, называемое смещением (bias), корректируется, чтобы следующее число требовало как можно меньше цифр.

Два следствия, которые вы можете увидеть сами выше:

• Похожие символы дешевы. Поскольку хранятся только расстояния, серия одинакового символа почти ничего не стоит: 30 копий 中 кодируются как xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, всего 36 байт. Измеренная смесь близких, но не связанных китайских символов упаковывает около 41 символа в одну допустимую метку длиной 63 байта, а один повторяющийся символ достигает 57.
• Разбросанные символы дороги. Символ, далёкий от предыдущего, требует более длинного числа-дельты. Китайский текст с множеством разных символов обычно стоит примерно на 2–3 буквы больше на символ, поэтому метка CJK заканчивает место где-то на 20–40 символах, хотя лимит метки — 63 байта.

Декодирование — тот же рецепт, но в обратном порядке: скопируйте ASCII-префикс, прочитайте цифры, превратите дельты обратно в кодовые точки и вставьте каждый новый символ в строку в позицию, которую кодирует дельта. В bootstring существуют только строчные цифры, поэтому заглавная буква внутри закодированной части отвергается, а не угадывается — DNS не чувствителен к регистру, и разрешение обоих регистров сделало бы два разных написания неоднозначными.

• В адресной строке. Браузеры могут показывать xn--fiq228c.com вместо 中文.com. Это тот же сайт. Некоторые браузеры намеренно показывают форму Punycode, когда имя смешивает письменности, именно для того, чтобы похожий символ (кириллическая а против латинской a) не мог спрятаться в URL.
• В самом DNS. Файлы зон, ответы dig / nslookup / DNS-over-HTTPS и журналы резолвера содержат только форму xn--; обычный Unicode отвергается или молча искажается.
• В сертификатах TLS. Альтернативное имя субъекта для международного домена хранится как A-метка (DNS:xn--fiq228c.com), поэтому сертификат, не похожий на имя, которое вы ввели, — норма, а не несоответствие.
• В конфигурации и инструментах. Записи server_name веб-сервера / виртуальных хостов, домены cookie, панели хостинга и CDN, почтовые домены, ключи API, привязанные к домену, и ключи баз данных безопаснее в виде A-меток.
• В тестировании и конвейерах данных. Некоторые библиотеки передают Unicode напрямую резолверу и падают; стандартное решение — сначала перевести в Punycode. Поскольку отображение канонично — одна Unicode-метка соответствует ровно одной A-метке, — форма xn-- также служит стабильным идентификатором для журналов и поиска.

Punycode — обратимое написание, и ничего более. Это не шифрование и не функция безопасности: любой может декодировать его инструментом выше, поэтому метка xn-- говорит «это было закодировано» и ничего о том, кому она принадлежит. Это также не сжатие — обычно он делает текст длиннее, как показывает пример 6 байт → 11 байт выше. И это не то же самое, что другие способы передачи Unicode через интернет; они решают другие уровни проблемы.

Схема	Превращает что во что	Где используется	中文 становится
Punycode (RFC 3492)	Unicode-метку домена в буквы и цифры ASCII	Только международные метки доменов	xn--fiq228c
UTF-8 (RFC 3629)	Кодовые точки в байты	Каждый файл и веб-запрос	E4 B8 AD E6 96 87 (6 байт)
Процентное кодирование (RFC 3986)	Байты в экранирование %XX	Пути URL, строки запроса, тела форм	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Байты в 64 ASCII-символа	Двоичные данные внутри текста, JSON, электронной почты, data URL	5Lit5paH
HTML-сущности	Кодовые точки в именованные или числовые ссылки	Исходный код HTML и XML	中文
Escape-последовательности Unicode	Кодовые точки в \uXXXX	Исходный код и строковые литералы JSON	\u4e2d\u6587

Практический вывод: Punycode применяется к меткам домена URL, а не ко всему URL. Путь и строка запроса — другая задача, и для них используется процентное кодирование (см. Кодировщики URL).

• Ограничения размера идут от DNS, а не от Punycode. Одна метка может быть не длиннее 63 байт, а полное имя — не длиннее 255 байт (RFC 1034 / 1035). Поскольку A-метка — чистый ASCII, число байт равно числу символов, и каждый не-ASCII символ тратит часть этого бюджета — примерно 1 символ бюджета на 1–4 буквы Punycode.
• Punycode переводит что угодно; реестры допускают не всё. Поверх работают правила IDNA, которые ограничивают, какие кодовые точки вообще можно зарегистрировать — заглавные буквы, пробелы, знаки препинания вроде ! и флаги не допускаются в настоящем домене. Эта страница выполняет преобразование по RFC 3492, поэтому охотно закодирует текст, который реестр отверг бы.
• Оставайтесь в одной письменности. IDNA не одобряет смешивание письменностей внутри одной метки именно из-за атак с похожими символами. Имя может быть закодировано и всё же непригодно, или пригодно, но занесено в чёрный список браузерами.
• Не кодируйте дважды. xn--, за которым идёт уже закодированный текст, недопустим, а метка из чистого ASCII не меняется вовсе — кодировать нечего, поэтому префикс не добавляется.
• Завершающая точка допустима. 例え.jp. — полностью квалифицированное имя, и пустая метка в конце сохраняется; пустые метки в середине не являются допустимыми именами хостов.

«Почему мой китайский домен отображается как xn--fiq228c.com в адресной строке?»

Потому что браузер решил показать A-метку. Сайт тот же; используйте направление «Декодировать» на этой странице, чтобы увидеть форму Unicode, или закодируйте форму Unicode, чтобы проверить, что обе записи совпадают.

«Нужно ли менять записи DNS, сертификат или хостинг?»

Нет. Держите A-метку xn-- везде, где имя читает машина (DNS, сертификаты, конфигурации), а форму Unicode используйте только там, где его читает человек.

«Почему результат длиннее того, что я ввёл?»

Потому что кодирование несёт не сами символы, а расстояния в системе по основанию 36, и алфавит из 36 символов должен записывать числа, которые могут быть большими. Рост ожидаем, это не ошибка.

«Почему при декодировании говорится о „заглавной букве“?»

Потому что цифры bootstring определены только в нижнем регистре (a-z, 0-9). Заглавная A-Z после последнего дефиса неоднозначна с учётом нечувствительности DNS к регистру, поэтому её сообщают, а не молча угадывают.

«Применяется ли Punycode к части до @ в адресе электронной почты?»

Только доменная часть является именем DNS и может быть в Punycode. Локальная часть обрабатывается почтовой системой, а не DNS, поэтому это кодирование к ней не применяется.

«Могут ли два разных Unicode-имени дать одну и ту же A-метку?»

Нет. Кодирование инъективно: разные последовательности кодовых точек всегда дают разные bootstring, поэтому декодирование xn--fiq228c возвращает ровно 中文 и ничего другого. Может совпасть внешний вид — разные символы, которые выглядят одинаково, — и это свойство набора Unicode, а не кодирования.

• RFC 3492 — Punycode, кодирование bootstring, реализованное на этой странице. Приведённые выше известные примеры сверены с образцами строк в этом документе.
• RFC 5890, RFC 5891, RFC 5892 и Unicode UTS #46 — IDNA2008 и его интерпретация на стороне браузера, правила, которые решают, какие символы допустимы, как нормализуются метки и как можно смешивать письменности.
• RFC 1034 и RFC 1035 — ограничения 63 байта на метку и 255 байт на имя, унаследованные от DNS.
• RFC 3490 и RFC 3491 — старое поколение IDNA2003, замещённое IDNA2008. Если имя ведёт себя иначе в старом ПО, обычно причина именно в этом.

Примечание об области: этот инструмент выполняет только преобразование RFC 3492 и ничего более. Это не валидатор IDN и не проверяет правила регистрации, цены или доступность домена — а поскольку он никогда не обращается к сети, он не может сказать, существует ли имя.

Попробуйте выше: вставьте 中文 и нажмите Закодировать текст → Punycode, чтобы увидеть A-метку, или вставьте xn--fiq228c и нажмите Декодировать Punycode → текст, чтобы получить символы обратно.