Převodník Punycode / IDN

Převeďte Unicode text na ASCII Punycode (RFC 3492, kódování za doménovými jmény xn--) nebo dekódujte štítek / doménu xn-- zpět na původní znaky. Můžete zadat jeden štítek (např. 中文) nebo celou tečkovanou doménu (např. 例え.jp); každý štítek s ne-ASCII znaky se kóduje samostatně. Také: Kodéry URL | Ascii85 | Base32 / Base58.
Veškeré zpracování probíhá lokálně ve vašem prohlížeči — nic se nenahrává.
Nikdy jste o Punycode neslyšeli? Co je Punycode — vysvětleno prostou češtinou (s příklady, mýty a pravidly, která skutečně kousnou).
Jak to funguje: Štítky obsahující jakýkoli ne-ASCII znak (CJK, latinka s diakritikou, emoji, ...) se převedou na ASCII Punycode a dostanou předponu xn--. Čistě ASCII štítky (a prázdné části za koncovou tečkou) projdou beze změny. Štítek jen se základními ASCII znaky se nikdy nemění.
Příklady: 中文 → xn--fiq228c  ·  例え.jp → xn--r8jz45g.jp  ·  bücher.de → xn--bcher-kva.de  ·  😂.com → xn--e28h.com
Jak to funguje: Každý štítek začínající na xn-- (předpona bez ohledu na velikost písmen) se dekóduje zpět na Unicode; ostatní ASCII štítky projdou beze změny. Velké písmeno A-Z v kódované části (za poslední pomlčkou) je nejednoznačné a je odmítnuto — vkládejte štítky A malými písmeny.
Vstup
Výstup
Ctrl+Enter ve vstupu spustí aktivní režim.
Zvolte směr a spusťte převod. Veškeré zpracování zůstává ve vašem prohlížeči.
Punycode podle RFC 3492 na pohled:
Punycode je kódování bootstring: nejprve se zkopírují základní ASCII kódové body (písmena, číslice, pomlčky), poté se každý ne-ASCII kódový bod vloží po jednom jako malé celé číslo v proměnlivé délce v základu 36 s adaptivním biasem (číslice a-z, poté 0-9). V doménových jménech dostane každý zakódovaný štítek předponu xn--, aby jej prohlížeče a DNS odlišily od běžného štítku. Kódový bod - slouží jako oddělovač mezi zkopírovanou ASCII částí a kódovanou částí.

Známé vektory — 中文 → xn--fiq228c, 例え → xn--r8jz45g, 中国 → xn--fiqs8s, bücher → xn--bcher-kva.
Co je Punycode?
Jednou větou: Punycode je způsob, jak psát znaky, které nejsou prostá anglická písmena — čínštinu, latinku s diakritikou, cyrilici, emoji — pouze pomocí 37 znaků, pro něž byl systém doménových jmen navržen: a-z, 0-9 a -. Je definován v RFC 3492 a v doménovém jménu jej poznáte podle předpony xn--: 中文 se změní na xn--fiq228c.

Punycode tedy není jazyk, písmo ani kód země — je to převod mezi dvěma zápisy téhož jména. Zápis Unicode se nazývá U-štítek (中文.com, bücher.de), zápis ASCII se nazývá A-štítek (xn--fiq228c.com, xn--bcher-kva.de) a celá myšlenka dávání mezinárodních jmen do DNS se nazývá IDN (mezinárodní doménová jména), resp. IDNA, soubor pravidel postavený nad ní.

Existuje proto, že DNS bylo navrženo na počátku 80. let kolem záměrně malé abecedy. Jméno hostitele, které putuje DNS, do zónového souboru, do mezipaměti resolveru, do řádku logu nebo do certifikátu TLS, musí být prostý ASCII — formát na drátě prostě nemá pole pro nic jiného. Punycode je záchranný východ: umožňuje, aby jméno, které není ASCII, putovalo, jako by jím bylo, a aby přijímací strana přesně rekonstruovala původní znaky. Proto vůbec funguje čínská doména v prohlížeči a proto je xn-- jediný řetězec, který uvidíte všude, kde nelze odeslat tvar Unicode.

Punycode za 30 sekund
Co zadáte vy (U-štítek) Co dostane DNS (A-štítek) Co to znamená
中文.comxn--fiq228c.comČínská slova pro “čínský jazyk”
中国xn--fiqs8s“Čína” v čínštině
例え.jpxn--r8jz45g.jpJaponské příklady
bücher.dexn--bcher-kva.deNěmecké bücher, “knihy”
münchen.dexn--mnchen-3ya.deMnichov
😂.comxn--e28h.comŠtítek s emoji — v kódování legální, ve většině registrů ne

Stojí za zapamatování srovnání délky: 中文 má 2 znaky a 6 bajtů v UTF-8, ale xn--fiq228c má 11 bajtů ASCII. Punycode jméno obvykle prodlouží, nikdy nezkrátí.

Jak kódování ve skutečnosti funguje

Vezměte bücher a sledujte tři kroky. Engine se nazývá bootstring a celý algoritmus má jen několik desítek řádků kódu (můžete jej přečíst ve skriptu této stránky).

  1. Základní znaky se zkopírují na začátek. Každý základní ASCII znak se zkopíruje ve stejném pořadí a zůstane čitelný: bücher → bcher. Protože se něco zkopírovalo a něco zůstalo, připojí se jako hranice jediná -: bcher-.
  2. Zbytek zapište jako čísla v základu 36. Zbývající znaky se zpracovávají ve vzestupném pořadí kódových bodů a každý se zapíše jako číslo v proměnlivé délce v základu 36, kde a=0 … z=25 a 0=26 … 9=35. Pro bücher se zbylý znak ü změní na číslice kva.
  3. Připojte předponu. Zakódovaná část připojená ke zkopírované části dává bcher-kva a v kontextu domény se zapisuje jako xn--bcher-kva.

Trik, který to dělá chytrým, je v tom, co tato čísla v základu 36 obsahují: ne samotný znak, ale delta — jak daleko je znak od dříve zakódovaného kódového bodu, plus kde patří uvnitř řetězce. Kodér prochází kódové body vzestupně a každá běh číslic popisuje pozici a vzdálenost. Po každém znaku se upraví sdílené číslo zvané bias, aby následující číslo potřebovalo co nejméně číslic.

Dva důsledky, které můžete vidět sami výše:

  • Podobné znaky jsou levné. Protože se ukládají jen vzdálenosti, běh stejného znaku stojí téměř nic: 30 kopií 中 se zakóduje na xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, jen 36 bajtů. Změřená, nesouvisející, ale blízká směs čínských znaků se vejde zhruba 41 znaků do jednoho legálního štítku o 63 bajtech a jediný opakovaný znak dosáhne 57.
  • Rozptýlené znaky jsou drahé. Znak daleko od předchozího potřebuje delší číslo delta. Čínský text s mnoha různými znaky obvykle stojí zhruba 2–3 další písmena na znak, proto CJK štítek dojde místa zhruba u 20–40 znaků, i když limit štítku je 63 bajtů.

Dekódování je stejný postup pozpátku: zkopírujte ASCII předponu, přečtěte číslice, změňte delty zpět na kódové body a vložte každý nový znak do řetězce na pozici, kterou kóduje delta. V bootstringu existují jen malé číslice, proto se velké písmeno uvnitř kódované části odmítne místo odhadu — DNS nerozlišuje velikost písmen, takže by povolení obou velikostí učinilo dva různé zápisy nejednoznačnými.

Kde se s ním opravdu setkáte
  • V adresním řádku. Prohlížeče mohou zobrazit xn--fiq228c.com místo 中文.com. Je to tentýž web. Některé prohlížeče záměrně ukazují tvar Punycode, když jméno míchá písma, právě proto, aby se v URL nemohl schovat znak zaměnitelný s jiným (cyrilské а versus latinské a).
  • V samotném DNS. Zónové soubory, odpovědi dig / nslookup / DNS přes HTTPS a logy resolverů obsahují vždy jen tvar xn--; prostý Unicode je odmítnut nebo tiše pokažen.
  • V certifikátech TLS. Alternativní jméno subjektu pro mezinárodní doménu se ukládá jako A-štítek (DNS:xn--fiq228c.com), takže certifikát, který nevypadá jako jméno, jaké jste napsali, je běžný, ne neshoda.
  • V konfiguraci a nástrojích. Položky server_name webového serveru / virtuálních hostitelů, domény cookies, panely hostingu a CDN, poštovní domény, klíče API vázané na doménu a databázové klíče jsou v podobě A-štítků bezpečnější.
  • V testování a datových pipeline. Některé knihovny předávají Unicode přímo resolveru a selhávají; standardní náprava je nejprve převést na Punycode. Protože je mapování kanonické — jeden Unicode štítek odpovídá přesně jednomu A-štítku — je tvar xn-- také stabilním identifikátorem pro logy a vyhledávání.
Čím Punycode není

Punycode je reverzibilní zápis, nic víc. Není to šifrování ani bezpečnostní funkce: kdokoli jej dekóduje výše uvedeným nástrojem, takže štítek xn-- říká “toto bylo zakódováno” a nic o tom, kdo jej vlastní. Není to ani komprese — obvykle text prodlouží, jak ukazuje výše uvedený příklad 6 až 11 bajtů. A není to totéž co jiné způsoby, jimiž Unicode cestuje internetem; ony řeší jiné vrstvy problému.

Schéma Převádí co na co Kde se používá 中文 se změní na
Punycode (RFC 3492)Štítek domény Unicode na písmena a číslice ASCIIPouze mezinárodní doménové štítkyxn--fiq228c
UTF-8 (RFC 3629)Kódové body na bajtyKaždý soubor a webový požadavekE4 B8 AD E6 96 87 (6 bajtů)
Procentní kódování (RFC 3986)Bajty na escapy %XXCesty URL, řetězce dotazů, těla formulářů%E4%B8%AD%E6%96%87
Base64 (RFC 4648)Bajty na 64 znaků ASCIIBinární data v textu, JSON, e-mailu, datových URL5Lit5paH
Entity HTMLKódové body na pojmenované nebo číselné odkazyZdrojový kód HTML a XML中文
Úniky UnicodeKódové body na \uXXXXZdrojový kód a řetězcové literály JSON\u4e2d\u6587

Praktické ponaučení: Punycode se vztahuje na doménové štítky URL, ne na celou URL. Cesta a řetězec dotazu jsou jiný problém a používají procentové kódování (viz Kodéry URL).

Limity a pravidla, která skutečně kousnou
  • Limity velikosti pocházejí z DNS, ne z Punycode. Jeden štítek smí mít nejvýše 63 bajtů a celé jméno nejvýše 255 bajtů (RFC 1034 / 1035). Protože je A-štítek čistě ASCII, počet bajtů se rovná počtu znaků a každý ne-ASCII znak spotřebuje část tohoto rozpočtu — zhruba 1 znak rozpočtu na 1–4 písmena Punycode.
  • Punycode převede cokoli; registry povolují jen některé věci. Nad tím leží pravidla IDNA, která omezují, které kódové body se vůbec mohou registrovat — velká písmena, mezery, interpunkce jako ! a příznaky nejsou v reálné doméně legální. Tato stránka provádí převod RFC 3492, takže ochotně zakóduje text, který by registr odmítl.
  • Držte se jednoho písma. IDNA odrazuje od míchání písem uvnitř jediného štítku právě kvůli útokům se zaměnitelnými znaky. Jméno lze zakódovat a přesto být nepoužitelné, nebo použitelné, ale prohlížeči zařazené na seznam blokovaných.
  • Nekódujte dvakrát. xn-- následované již zakódovaným textem je neplatné a štítek, který je čistě ASCII, se nikdy nemění — není co kódovat, takže se žádná předpona nepřidá.
  • Koncová tečka je v pořádku. 例え.jp. je plně kvalifikované jméno a prázdný štítek na konci se zachová; prázdné štítky uprostřed nejsou platná jména hostitelů.
Rychlé odpovědi

“Proč se moje čínská doména v adresním řádku zobrazí jako xn--fiq228c.com?”

Protože prohlížeč zvolil zobrazení A-štítku. Web je totožný; k zobrazení tvaru Unicode použijte směr Dekódovat na této stránce, nebo zakódujte tvar Unicode a ověřte, zda se oba zápisy shodují.

“Musím změnit své záznamy DNS, certifikát nebo hosting?”

Ne. Ponechte A-štítek xn-- všude, kde jméno čte stroj (DNS, certifikáty, konfigurace), a tvar Unicode používejte jen tam, kde jej čte člověk.

“Proč je výsledek delší, než co jsem napsal?”

Protože kódování nenese samotné znaky, nese vzdálenosti v základu 36 a 36znakové písmeno musí vyjádřit čísla, která mohou být velká. Růst je očekávaný, ne chyba.

“Proč dekódování hlásí ‘velké písmeno’?”

Protože číslice bootstringu jsou definovány jen malými písmeny (a-z, 0-9). Velké A-Z za poslední pomlčkou je nejednoznačné, když se zohlední, že DNS nerozlišuje velikost písmen, proto se nahlásí místo tichého odhadu.

“Vztahuje se Punycode na část před zavináčem v e-mailové adrese?”

Doménovou DNS jménem a kódovatelným Punycodem je jen doménová část. Lokální část zpracovává poštovní systém, ne DNS, takže se na ni toto kódování nevztahuje.

“Mohou dvě různá Unicode jména vytvořit stejný A-štítek?”

Ne. Kódování je injektivní: různé posloupnosti kódových bodů vždy vytvoří různé bootstringy, takže dekódování xn--fiq228c vrátí přesně 中文 a nic jiného. Kolidovat může vzhled — různé znaky, které vypadají stejně — což je vlastnost repertoáru Unicode, ne kódování.

Standardy, které tato stránka dodržuje
  • RFC 3492 — Punycode, kódování bootstring implementované na této stránce. Výše uvedené známé vektory jsou ověřeny proti vzorovým řetězcům v tomto dokumentu.
  • RFC 5890, RFC 5891, RFC 5892 a Unicode UTS #46 — IDNA2008 a jeho výklad v prohlížeči, pravidla, která rozhodují, jaké znaky jsou legální, jak se štítky normalizují a jak se písma smějí míchat.
  • RFC 1034 a RFC 1035 — limity 63 bajtů na štítek a 255 bajtů na jméno zděděné z DNS.
  • RFC 3490 a RFC 3491 — starší generace IDNA2003, nahrazená IDNA2008. Pokud se jméno ve starém softwaru chová jinak, bývá to právě proto.

Poznámka k rozsahu: tento nástroj provádí jen převod RFC 3492 a nic dalšího. Není to validátor IDN a nekontroluje pravidla registrace, ceny ani dostupnost domény — a protože se nikdy nespojuje se sítí, nemůže vám říct, zda jméno existuje.

Zkuste to výše: vložte 中文 a stiskněte Kódovat text → Punycode, abyste viděli A-štítek, nebo vložte xn--fiq228c a stiskněte Dekódovat Punycode → text, abyste dostali znaky zpět.