Конвертер 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)	Байти у escape-послідовності %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 → текст, щоб повернути символи.