Konwerter Punycode / IDN

Punycode nie jest więc językiem, czcionką ani kodem kraju — to tłumaczenie między dwoma zapisami tej samej nazwy. Zapis Unicode nazywa się etykietą U (中文.com, bücher.de), zapis ASCII to etykieta A (xn--fiq228c.com, xn--bcher-kva.de), a cała idea umieszczania międzynarodowych nazw w DNS nazywa się IDN (międzynarodowe nazwy domen) lub IDNA, czyli zbiór reguł zbudowanych na tym fundamencie.

Powstał, ponieważ DNS zaprojektowano na początku lat osiemdziesiątych wokół celowo niewielkiego alfabetu. Nazwa hosta, która przechodzi przez DNS, do pliku strefy, pamięci podręcznej resolwera, wiersza logu albo certyfikatu TLS, musi być czystym ASCII — format przesyłu po prostu nie ma pola na nic innego. Punycode to wyjście awaryjne: pozwala nazwie spoza ASCII podróżować tak, jakby była ASCII, a odbiorcy odtworzyć oryginalne znaki dokładnie. Dlatego chińska domena w ogóle działa w przeglądarce, a xn-- to jedyny ciąg, który widać wszędzie tam, gdzie zapis Unicode nie może zostać przesłany.

Co się wpisuje (etykieta U)	Co otrzymuje DNS (etykieta A)	Co to znaczy
中文.com	xn--fiq228c.com	Chińskie słowa oznaczające “język chiński”
中国	xn--fiqs8s	“Chiny” po chińsku
例え.jp	xn--r8jz45g.jp	Japońskie przykłady
bücher.de	xn--bcher-kva.de	Niemieckie bücher, “książki”
münchen.de	xn--mnchen-3ya.de	Monachium
😂.com	xn--e28h.com	Etykieta z emoji — dozwolona w kodowaniu, ale nie w większości rejestrów

Warto zapamiętać porównanie długości: 中文 to 2 znaki i 6 bajtów w UTF-8, a xn--fiq228c to 11 bajtów ASCII. Punycode zwykle wydłuża nazwę, nigdy jej nie skraca.

Weź bücher i obserwuj trzy kroki. Silnik nazywa się bootstring, a cały algorytm to zaledwie kilkadziesiąt linii kodu (można go przeczytać w skrypcie tej strony).

1. Skopiuj zwykłe znaki na początek. Każdy podstawowy znak ASCII jest kopiowany w oryginalnej kolejności i pozostaje czytelny: bücher → bcher. Ponieważ coś zostało skopiowane i coś pozostało, jako granicę dopisuje się pojedynczy -: bcher-.
2. Pozostałe znaki zapisz jako liczby o podstawie 36. Pozostałe znaki są przetwarzane w rosnącej kolejności punktów kodowych, a każdy zapisywany jest jako liczba o zmiennej długości w systemie o podstawie 36, gdzie a=0 … z=25, a 0=26 … 9=35. Dla bücher pozostały znak ü staje się cyframi kva.
3. Dołącz prefiks. Zakodowana część dopisana do skopiowanej daje bcher-kva, a w kontekście domeny zapisuje się ją jako xn--bcher-kva.

Sprytne w tym jest to, co zawierają te liczby o podstawie 36: nie sam znak, lecz deltę — jak daleko znak jest od poprzednio zakodowanego punktu kodowego, plus gdzie należy w ciągu. Koder przechodzi punkty kodowe rosnąco, a każdy ciąg cyfr opisuje pozycję i odległość. Po każdym znaku wspólna liczba zwana biasem jest korygowana, tak aby kolejna liczba potrzebowała jak najmniej cyfr.

Dwie konsekwencje, które można sprawdzić powyżej:

• Podobne znaki są tanie. Ponieważ zapisywane są tylko odległości, ciąg tego samego znaku kosztuje prawie nic: 30 kopii 中 koduje się jako xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, zaledwie 36 bajtów. Zmierzona, niezwiązana, ale bliska mieszanka chińskich znaków mieści około 41 znaków w jednej dozwolonej etykiecie 63-bajtowej, a pojedynczy powtarzany znak dochodzi do 57.
• Rozproszone znaki są kosztowne. Znak odległy od poprzedniego wymaga dłuższej liczby delta. Chiński tekst z wieloma różnymi znakami zwykle kosztuje około 2–3 dodatkowe litery na znak, dlatego etykieta CJK kończy miejsce mniej więcej na 20–40 znakach, mimo że limit etykiety to 63 bajty.

Dekodowanie to ten sam przepis wstecz: skopiuj prefiks ASCII, odczytaj cyfry, zamień delty z powrotem na punkty kodowe i wstaw każdy nowy znak do ciągu na pozycji, którą koduje delta. W bootstring istnieją tylko małe cyfry, dlatego wielka litera wewnątrz zakodowanej części jest odrzucana zamiast zgadywana — DNS nie rozróżnia wielkości liter, więc dopuszczenie obu przypadków sprawiłoby, że dwa różne zapisy byłyby dwuznaczne.

• W pasku adresu. Przeglądarki mogą wyświetlać xn--fiq228c.com zamiast 中文.com. To ta sama strona. Niektóre przeglądarki celowo pokazują postać Punycode, gdy nazwa miesza pisma, właśnie po to, by znak podobny wyglądem (cyrylicka а zamiast łacińskiego a) nie mógł ukryć się w adresie.
• W samym DNS. Pliki stref, odpowiedzi dig / nslookup / DNS-over-HTTPS i logi resolwerów zawierają wyłącznie postać xn--; zwykły Unicode jest odrzucany albo po cichu psuty.
• W certyfikatach TLS. Alternatywna nazwa podmiotu dla domeny międzynarodowej jest zapisywana jako etykieta A (DNS:xn--fiq228c.com), więc certyfikat niewyglądający jak wpisana nazwa to norma, a nie niezgodność.
• W konfiguracji i narzędziach. Wpisy server_name serwera WWW / hosty wirtualne, domeny ciasteczek, panele hostingu i CDN, domeny poczty, klucze API przypisane do domeny oraz klucze baz danych są bezpieczniejsze w postaci etykiet A.
• W testach i potokach danych. Niektóre biblioteki przekazują Unicode wprost do resolwera i zawodzą; standardową poprawką jest najpierw zamiana na Punycode. Ponieważ odwzorowanie jest kanoniczne — jedna etykieta Unicode odpowiada dokładnie jednej etykiecie A — postać xn-- jest też stabilnym identyfikatorem w logach i wyszukiwaniu.

Punycode to odwracalny zapis, nic więcej. Nie jest szyfrowaniem ani funkcją bezpieczeństwa: każdy może go zdekodować narzędziem powyżej, więc etykieta xn-- mówi “to zostało zakodowane” i nic o tym, kto jest jej właścicielem. To także nie kompresja — zwykle wydłuża tekst, jak pokazuje powyższy przykład 6 do 11 bajtów. I nie jest tym samym co inne sposoby przesyłania Unicode w internecie; rozwiązują one inne warstwy problemu.

Schemat	Zamienia co na co	Gdzie jest używany	中文 staje się
Punycode (RFC 3492)	Etykieta domeny Unicode na litery i cyfry ASCII	Tylko międzynarodowe etykiety domen	xn--fiq228c
UTF-8 (RFC 3629)	Punkty kodowe na bajty	Każdy plik i każde żądanie sieciowe	E4 B8 AD E6 96 87 (6 bajtów)
Kodowanie procentowe (RFC 3986)	Bajty na sekwencje %XX	Ścieżki URL, ciągi zapytań, dane formularzy	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Bajty na 64 znaki ASCII	Dane binarne w tekście, JSON, e-mailu, adresach data URL	5Lit5paH
Encje HTML	Punkty kodowe na odwołania nazwane lub numeryczne	Źródło HTML i XML	中文
Sekwencje ucieczki Unicode	Punkty kodowe na \uXXXX	Kod źródłowy i literały łańcuchów JSON	\u4e2d\u6587

Praktyczny wniosek: Punycode dotyczy etykiet domenowych adresu URL, a nie całego adresu. Ścieżka i ciąg zapytania to inny problem i używają kodowania procentowego (zob. Kodery URL).

• Limity rozmiaru pochodzą z DNS, a nie z Punycode. Jedna etykieta może mieć najwyżej 63 bajty, a cała nazwa najwyżej 255 bajtów (RFC 1034 / 1035). Ponieważ etykieta A to czysty ASCII, liczba bajtów równa się liczbie znaków, a każdy znak spoza ASCII zużywa część tego budżetu — mniej więcej 1 znak budżetu na 1–4 litery Punycode.
• Punycode zamienia wszystko; rejestry dopuszczają tylko niektóre rzeczy. Na to nakładają się reguły IDNA, które ograniczają, jakie punkty kodowe w ogóle można zarejestrować — wielkie litery, spacje, znaki interpunkcyjne jak ! i flagi nie są dozwolone w prawdziwej domenie. Ta strona wykonuje konwersję RFC 3492, więc chętnie zakoduje tekst, który rejestr by odrzucił.
• Trzymaj się jednego pisma. IDNA odradza mieszanie pism wewnątrz jednej etykiety właśnie przez ataki z podobnymi znakami. Nazwę można zakodować i mimo to być nieużywalną, albo użyteczną, a jednak blokowaną przez przeglądarki.
• Nie kodować dwukrotnie. xn-- po już zakodowanym tekście jest nieprawidłowe, a etykieta czysto ASCII nigdy się nie zmienia — nie ma nic do zakodowania, więc prefiks nie jest dodawany.
• Kropka końcowa jest w porządku. 例え.jp. to w pełni kwalifikowana nazwa, a pusta etykieta na końcu jest zachowana; puste etykiety w środku nie są poprawnymi nazwami hostów.

“Dlaczego moja chińska domena pojawia się jako xn--fiq228c.com w pasku adresu?”

Ponieważ przeglądarka wybrała wyświetlenie etykiety A. Strona jest identyczna; użyj kierunku Dekoduj na tej stronie, aby zobaczyć postać Unicode, albo zakoduj postać Unicode, by sprawdzić, czy oba zapisy się zgadzają.

“Czy trzeba zmieniać rekordy DNS, certyfikat lub hosting?”

Nie. Postać xn-- w postaci etykiety A należy zachowywać wszędzie tam, gdzie maszyna odczytuje nazwę (DNS, certyfikaty, konfiguracje), a postać Unicode używać wyłącznie tam, gdzie czyta ją człowiek.

“Dlaczego wynik jest dłuższy niż wpisany tekst?”

Ponieważ kodowanie nie przenosi samych znaków, tylko odległości w systemie o podstawie 36, a 36-znakowy alfabet musi zapisać liczby, które mogą być duże. Wzrost długości jest oczekiwany, a nie błędem.

“Dlaczego dekodowanie mówi o wielkiej literze?”

Ponieważ cyfry bootstring są zdefiniowane wyłącznie jako małe litery (a-z, 0-9). Wielka litera A-Z za ostatnim myślnikiem jest dwuznaczna po uwzględnieniu tego, że DNS nie rozróżnia wielkości liter, więc jest zgłaszana zamiast po cichu zgadywana.

“Czy Punycode dotyczy części przed znakiem @ w adresie e-mail?”

Tylko część domenowa jest nazwą DNS i może być zapisana w Punycode. Część lokalna jest obsługiwana przez system poczty, a nie przez DNS, więc to kodowanie się do niej nie stosuje.

“Czy dwie różne nazwy Unicode mogą dać tę samą etykietę A?”

Nie. Kodowanie jest różnowartościowe: różne ciągi punktów kodowych zawsze dają różne bootstringi, więc dekodowanie xn--fiq228c zwraca dokładnie 中文 i nic innego. Kolidować może wygląd — różne znaki, które wyglądają podobnie — a to cecha repertuaru Unicode, a nie kodowania.

• RFC 3492 — Punycode, kodowanie bootstring zaimplementowane na tej stronie. Wyżej podane znane wektory są sprawdzone względem przykładowych ciągów z tego dokumentu.
• RFC 5890, RFC 5891, RFC 5892 i Unicode UTS #46 — IDNA2008 i jej interpretacja po stronie przeglądarki, czyli reguły decydujące, które znaki są dozwolone, jak etykiety są normalizowane i jak można mieszać pisma.
• RFC 1034 i RFC 1035 — limity etykiety 63 bajtów i nazwy 255 bajtów odziedziczone po DNS.
• RFC 3490 i RFC 3491 — starsza generacja IDNA2003, zastąpiona przez IDNA2008. Jeśli nazwa zachowuje się inaczej w starym oprogramowaniu, zwykle to właśnie dlatego.

Zakres: to narzędzie wykonuje wyłącznie konwersję RFC 3492 i nic więcej. Nie jest walidatorem IDN i nie sprawdza zasad rejestracji, cen ani dostępności domeny — a ponieważ nigdy nie kontaktuje się z siecią, nie powie, czy dana nazwa istnieje.

Wypróbuj powyżej: wklej 中文 i naciśnij Koduj Tekst → Punycode, aby zobaczyć etykietę A, albo wklej xn--fiq228c i naciśnij Dekoduj Punycode → Tekst, aby odzyskać znaki.