Punycode / IDN-muunnin

Punycode ei siis ole kieli, fontti eikä maakoodi — se on käännös kahden saman nimen kirjoitusasun välillä. Unicode-kirjoitusasua kutsutaan U-osaksi (中文.com, bücher.de), ASCII-kirjoitusasua A-osaksi (xn--fiq228c.com, xn--bcher-kva.de), ja koko ajatusta kansainvälisten nimien laittamisesta DNS:ään kutsutaan IDN:ksi (kansainväliset verkkotunnukset) tai IDNA:ksi, joka on sen päälle rakennettu sääntöjoukko.

Se on olemassa, koska DNS suunniteltiin 1980-luvun alussa tarkoituksella hyvin pienen aakkoston varaan. Isäntänimen, joka kulkee DNS:n kautta vyöhyketiedostoon, selvittäjän välimuistiin, lokirivin tai TLS-varmenteeseen, on oltava tavallista ASCII-merkkiä — siirtomuodossa ei yksinkertaisesti ole kenttää mihinkään muuhun. Punycode on pakoreitti: se antaa ei-ASCII-nimen kulkea kuin se olisi ASCII-muotoinen, ja vastaanottava pää pystyy rakentamaan alkuperäiset merkit täsmälleen. Siksi kiinalainen verkkotunnus toimii ylipäätään selaimessa, ja siksi xn-- on se yksi merkkijono, jonka näet kaikkialla, missä Unicode-kirjoitusasua ei voi lähettää.

Mitä kirjoitetaan (U-osa)	Mitä DNS saa (A-osa)	Mitä se tarkoittaa
中文.com	xn--fiq228c.com	Sanat “kiinan kieli” kiinaksi
中国	xn--fiqs8s	“Kiina” kiinaksi
例え.jp	xn--r8jz45g.jp	Japanilaiset esimerkit
bücher.de	xn--bcher-kva.de	Saksa bücher, “kirjat”
münchen.de	xn--mnchen-3ya.de	München
😂.com	xn--e28h.com	Emoji-osa — sallittu koodauksessa, ei useimmissa rekistereissä

Vertailun arvoinen pituusero: 中文 on 2 merkkiä ja 6 tavua UTF-8:ssa, mutta xn--fiq228c on 11 ASCII-tavua. Punycode tekee nimestä yleensä pidemmän, ei koskaan lyhyemmän.

Otetaan bücher ja katsotaan kolme siirtoa. Moottoria kutsutaan bootstringiksi, ja koko algoritmi on vain muutama kymmenen koodirivia (sen voi lukea tämän sivun skriptistä).

1. Kopioi tavalliset merkit alkuun. Jokainen perus-ASCII-merkki kopioidaan alkuperäisessä järjestyksessään ja pidetään luettavana: bücher → bcher. Koska jotain kopioitiin ja jotain jäi jäljelle, rajaksi lisätään yksi -: bcher-.
2. Kirjoita loput kantaluvun 36 numeroina. Jäljellä olevat merkit käsitellään kasvavassa koodipistejärjestyksessä, ja jokainen kirjoitetaan muuttuvanpituisena lukuna kantaluvussa 36, jossa a=0 … z=25 ja 0=26 … 9=35. Sanalle bücher jäljelle jäävä merkki ü muuttuu numeroiksi kva.
3. Kiinnitä etuliite. Koodattu osa kopioidun osan perään antaa bcher-kva, ja verkkotunnuksen yhteydessä se kirjoitetaan muodossa xn--bcher-kva.

Temppu, joka tekee tästä älykkään, on se, mitä kantaluvun 36 numerot sisältävät: ei itse merkkiä, vaan delta — kuinka kaukana merkki on edellisestä koodatusta koodipisteestä, sekä se, mihin kohtaan merkkijonoa se kuuluu. Koodain käy koodipisteitä läpi nousevassa järjestyksessä, ja jokainen numerojono kuvaa paikan ja etäisyyden. Jokaisen merkin jälkeen yhteinen luku, bias, säädetään niin, että seuraava luku tarvitsee mahdollisimman vähän numeroita.

Kaksi seurausta, jotka näkyvät yllä olevassa esimerkissä:

• Samankaltaiset merkit ovat halpoja. Koska tallennetaan vain etäisyyksiä, saman merkin jono maksaa lähes ei mitään: 30 kopiota 中:stä koodautuu muotoon xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, vain 36 tavua. Mitattu, toisiinsa liittymätön mutta lähekkäinen kiinalainen merkkisekoitus pakkautuu noin 41 merkkiin yhteen sallittuun 63 tavun osaan, ja yksi toistuva merkki saavuttaa 57.
• Hajallaan olevat merkit ovat kalliita. Merkki, joka on kaukana edellisestä, tarvitsee pidemmän delta-luvun. Monen eri merkin kiinalainen teksti maksaa tyypillisesti noin 2–3 ylimääräistä kirjainta merkkiä kohden, minkä vuoksi CJK-osa loppuu tilasta noin 20–40 merkin kohdalla, vaikka osan raja on 63 tavua.

Purkaminen on sama resepti takaperin: kopioi ASCII-etuliite, lue numerot, muunna deltat takaisin koodipisteiksi ja lisää jokainen uusi merkki merkkijonoon siihen kohtaan, jonka delta koodaa. Bootstringissä on vain pieniä numeroita, minkä vuoksi koodatun osan iso kirjain hylätään sitä arvaamatta — DNS ei erota kirjainkokoa, joten molempien kirjainkokojen sallimat tekisivät kaksi eri kirjoitusasua epäselviksi.

• Osoitekentässä. Selaimet voivat näyttää xn--fiq228c.com sijaan 中文.com. Se on sama sivusto. Jotkin selaimet näyttävät tarkoituksella Punycode-muodon, kun nimessä sekoittuu kirjoitusjärjestelmiä, juuri jotta näennäisesti samannäköinen merkki (kyrillinen а vastaan latinalainen a) ei voi piiloutua URL-osoitteeseen.
• DNS:ssä itsessään. Vyöhykkeiden tiedostot, dig / nslookup / DNS-over-HTTPS -vastaukset ja selvittäjien lokit sisältävät aina vain xn---muodon; tavallinen Unicode hylätään tai vääristyy hiljaa.
• TLS-varmenteissa. Kansainvälisen verkkotunnuksen aihevaihtoehtoinen nimi tallennetaan A-osana (DNS:xn--fiq228c.com), joten varmenne, joka ei näytä kirjoittamasi nimeltä, on normaali eikä virhe.
• Kokoonpanossa ja työkaluissa. Web-palvelimen server_name- / virtuaalisen isännän merkinnät, evästeiden verkkotunnukset, isännöinti- ja CDN-paneelit, sähköpostiverkkotunnukset, verkkotunnukseen sidotut API-avaimet ja tietokantojen avaimet ovat kaikki turvallisempia A-osamuodossa.
• Testauksessa ja datavirroissa. Jotkin kirjastot välittävät Unicoden suoraan selvittäjälle ja epäonnistuvat; muunnos Punycodeksi ensin on vakiokorjaus. Koska kuvaus on kanoninen — yksi Unicode-osa vastaa täsmälleen yhtä A-osaa — xn---muoto on myös vakaa tunniste lokeille ja hauille.

Punycode on kääntyvä kirjoitusasu, ei mitään muuta. Se ei ole salaus eikä turvaominaisuus: kuka tahansa voi purkaa sen yllä olevalla työkalulla, joten xn---osa kertoo vain, että tämä on koodattu, eikä mitään siitä, kuka sen omistaa. Se ei myöskään ole pakkausta — se yleensä pidentää tekstiä, kuten yllä oleva 6-tavun ja 11-tavun esimerkki osoittaa. Eikä se ole sama asia kuin muut tavat, joilla Unicode kulkee internetissä; ne ratkaisevat ongelman eri kerroksissa.

Järjestelmä	Muuttaa mitä mihin	Missä sitä käytetään	中文 muuttuu muotoon
Punycode (RFC 3492)	Unicode-verkkotunnusosa ASCII-kirjaimiksi ja numeroiksi	Vain kansainväliset verkkotunnusosat	xn--fiq228c
UTF-8 (RFC 3629)	Koodipisteet tavuiksi	Jokainen tiedosto ja verkkopyyntö	E4 B8 AD E6 96 87 (6 tavua)
Prosenttikoodaus (RFC 3986)	Tavut %XX-pakoihin	URL-polut, kyselymerkkijonot, lomakkeen rungot	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Tavut 64 ASCII-merkkiin	Binääri tekstin, JSON:n, sähköpostin ja data-URL:ien sisällä	5Lit5paH
HTML-entiteetit	Koodipisteet nimettyihin tai numeerisiin viitteisiin	HTML- ja XML-lähdekoodi	中文
Unicode-pakot	Koodipisteet muotoon \uXXXX	Lähdekoodi ja JSON-merkkijonoliteraalit	\u4e2d\u6587

Käytännön johtopäätös: Punycode koskee URL-osoitteen verkkotunnuksen osia, ei koko URL-osoitetta. Polku ja kyselymerkkijono ovat eri ongelma ja käyttävät prosenttikoodausta (katso URL-koodaajat).

• Kokorajat tulevat DNS:stä, eivät Punycodesta. Yksi osa saa olla enintään 63 tavua ja koko nimi enintään 255 tavua (RFC 1034 / 1035). Koska A-osa on puhdasta ASCII-merkkiä, tavumäärä on sama kuin merkkimäärä, ja jokainen ei-ASCII-merkki kuluttaa osan budjetista — noin 1 merkki budjettia 1–4 Punycode-kirjainta kohden.
• Punycode muuntaa mitä tahansa; rekisterit sallivat vain osan. IDNA-säännöt asettuvat päälle ja rajoittavat, mitä koodipisteitä voi ylipäätään rekisteröidä — isot kirjaimet, välilyönnit, välimerkit kuten ! ja liput eivät ole sallittuja oikeassa verkkotunnuksessa. Tämä sivu tekee RFC 3492 -muunnoksen, joten se koodaa iloisesti tekstiä, jonka rekisteri hylkäisi.
• Pysy yhdessä kirjoitusjärjestelmässä. IDNA kieltää sekoittamasta kirjoitusjärjestelmiä yhden osan sisällä juuri näennäisesti samannäköisten hyökkäysten vuoksi. Nimi voidaan koodata ja silti olla käyttökelvoton, tai käyttökelpoinen mutta selaimien estolistalla.
• Älä koodaa kahdesti. xn-- jonka perässä on jo koodattua tekstiä, on virheellinen, ja puhtaasti ASCII-osa ei muutu koskaan — koodattavaa ei ole, joten etuliitettä ei lisätä.
• Lopussa oleva piste on sallittu. 例え.jp. on täysin määritelty nimi, ja lopussa oleva tyhjä osa säilytetään; tyhjät osat keskellä eivät ole kelvollisia isäntänimiä.

“Miksi kiinankielinen verkkotunnus näkyy osoitekentässä muodossa xn--fiq228c.com?”

Koska selain päätti näyttää A-osan. Sivusto on sama; käytä tämän sivun purkusuuntaa Unicode-muodon näkemiseksi tai koodaa Unicode-muoto, jotta molemmat kirjoitusasut voidaan tarkistaa.

“Pitääkö DNS-tietueet, varmenne tai isännöinti vaihtaa?”

Ei. Pidä xn---A-osa kaikkialla, missä kone lukee nimen (DNS, varmenteet, kokoonpanot), ja käytä Unicode-muotoa vain siellä, missä ihminen sen lukee.

“Miksi tulos on pidempi kuin kirjoitettu teksti?”

Koska koodaus ei kanna itse merkkejä, vaan kantaluvun 36 etäisyyksiä, ja 36 merkin aakkosto joutuu kirjoittamaan lukuja, jotka voivat olla suuria. Kasvu on odotettua, ei virhe.

“Miksi purku sanoo ‘iso kirjain’?”

Koska bootstring-numerot on määritelty vain pienille kirjaimille (a-z, 0-9). Iso kirjain A-Z viimeisen väliviivan jälkeen on epäselvä, kun otetaan huomioon DNS:n kirjainkoosta riippumattomuus, joten se ilmoitetaan sen sijaan, että sitä arvattaisiin hiljaa.

“Koskeeko Punycode sähköpostiosoitteen @-merkin edessä olevaa osaa?”

Vain verkkotunnuksen osa on DNS-nimi ja voi olla Punycodea. Paikallinen osa käsitellään postijärjestelmän, ei DNS:n, toimesta, joten tämä koodaus ei koske sitä.

“Voivatko kaksi eri Unicode-nimeä tuottaa saman A-osan?”

Ei. Koodaus on injektiivinen: erilaiset koodipistejonot tuottavat aina erilaiset bootstringit, joten xn--fiq228c-merkkijonon purku palauttaa täsmälleen 中文 eikä mitään muuta. Sen sijaan ulkonäkö voi törmätä — eri merkit, jotka näyttävät samanlaisilta — ja se on Unicode-repertuaarin ominaisuus, ei koodauksen.

• RFC 3492 — Punycode, tämän sivun toteuttama bootstring-koodaus. Yllä lainatut tunnetut vektorit tarkistetaan kyseisen asiakirjan esimerkkijonoja vastaan.
• RFC 5890, RFC 5891, RFC 5892 ja Unicode UTS #46 — IDNA2008 ja sen selaimen puolen tulkinta, säännöt, jotka päättävät mitkä merkit ovat sallittuja, miten osat normalisoidaan ja miten kirjoitusjärjestelmiä saa sekoittaa.
• RFC 1034 ja RFC 1035 — 63 tavun osa- ja 255 tavun nimirajat, jotka DNS on perinyt.
• RFC 3490 ja RFC 3491 — vanhempi IDNA2003-sukupolvi, jonka IDNA2008 on korvannut. Jos nimi käyttäytyy eri tavalla vanhassa ohjelmistossa, syy on yleensä tämä.

Soveltamisala: tämä työkalu tekee RFC 3492 -muunnoksen eikä muuta. Se ei ole IDN-validaattori eikä tarkista rekisteröintisääntöjä, hintoja tai verkkotunnuksen saatavuutta — eikä se, koska se ei ota yhteyttä verkkoon, voi kertoa, onko nimi olemassa.

Kokeile yllä: liitä 中文 ja paina Koodaa teksti → Punycode, jolloin A-osa näkyy, tai liitä xn--fiq228c ja paina Pura Punycode → teksti, jolloin merkit palautuvat.