Konverter Punycode / IDN

Jadi Punycode bukan bahasa, bukan font, dan bukan kode negara — ia adalah terjemahan antara dua ejaan dari nama yang sama. Ejaan Unicode disebut U-label (中文.com, bücher.de), ejaan ASCII disebut A-label (xn--fiq228c.com, xn--bcher-kva.de), dan seluruh gagasan memasukkan nama internasional ke DNS disebut IDN (nama domain internasional) atau IDNA, kumpulan aturan yang dibangun di atasnya.

Ini ada karena DNS dirancang pada awal 1980-an di sekitar alfabet yang sengaja sangat kecil. Nama host yang melewati DNS, masuk ke berkas zona, cache resolver, baris log, atau sertifikat TLS, harus berupa ASCII murni — format kabel memang tidak memiliki kolom untuk hal lain. Punycode adalah jalan keluarnya: ia memungkinkan nama yang bukan ASCII berjalan seolah-olah ASCII, dan ujung penerima dapat merekonstruksi karakter aslinya dengan tepat. Itulah sebabnya domain Mandarin berfungsi di browser sama sekali, dan mengapa xn-- adalah satu-satunya string yang Anda lihat di setiap tempat di mana ejaan Unicode tidak dapat dikirim.

Yang Anda ketik (label-U)	Yang diterima DNS (label-A)	Artinya
中文.com	xn--fiq228c.com	Kata-kata Mandarin untuk “bahasa Mandarin”
中国	xn--fiqs8s	“China” dalam bahasa Mandarin
例え.jp	xn--r8jz45g.jp	Contoh bahasa Jepang
bücher.de	xn--bcher-kva.de	Bahasa Jerman bücher, “buku”
münchen.de	xn--mnchen-3ya.de	Munich
😂.com	xn--e28h.com	Label emoji — legal dalam pengodean, tidak di sebagian besar registri

Perbandingan panjang yang layak diingat: 中文 adalah 2 karakter dan 6 byte dalam UTF-8, tetapi xn--fiq228c adalah 11 byte ASCII. Punycode biasanya membuat nama lebih panjang, tidak pernah lebih pendek.

Ambil bücher dan amati ketiga langkahnya. Mesinnya disebut bootstring, dan seluruh algoritmanya hanya beberapa lusin baris kode (Anda dapat membacanya di skrip halaman ini).

1. Salin karakter biasa ke depan. Setiap karakter ASCII dasar disalin dengan urutan asalnya dan tetap dapat dibaca: bücher → bcher. Karena ada yang disalin dan ada sisa, satu - ditambahkan sebagai batas: bcher-.
2. Tulis sisanya sebagai bilangan basis-36. Karakter yang tersisa ditangani menurut urutan titik kode yang meningkat, dan setiap karakter ditulis sebagai bilangan panjang variabel dalam basis 36 dengan a=0 … z=25 dan 0=26 … 9=35. Untuk bücher karakter sisa ü menjadi digit kva.
3. Tempelkan awalannya. Bagian yang dikodekan ditambahkan pada bagian yang disalin menghasilkan bcher-kva, dan dalam konteks domain ditulis sebagai xn--bcher-kva.

Trik yang membuat ini cerdas adalah isi dari bilangan basis-36 tersebut: bukan karakter itu sendiri, melainkan delta — seberapa jauh karakter itu dari titik kode yang dikodekan sebelumnya, ditambah di mana ia berada di dalam string. Pengodean menelusuri titik kode secara menaik dan setiap rangkaian digit menggambarkan posisi dan jarak. Setelah setiap karakter, bilangan bersama yang disebut bias disesuaikan agar bilangan berikutnya memerlukan digit sesedikit mungkin.

Dua konsekuensi yang dapat Anda lihat sendiri di atas:

• Karakter yang mirip itu murah. Karena hanya jaraknya yang disimpan, deretan karakter yang sama hampir tidak memakan biaya: 30 salinan 中 dikodekan menjadi xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, hanya 36 byte. Campuran karakter Mandarin yang berdekatan namun tidak berhubungan yang diukur muat sekitar 41 karakter dalam satu label 63 byte yang legal, dan satu karakter yang diulang mencapai 57.
• Karakter yang tersebar itu mahal. Karakter yang jauh dari karakter sebelumnya memerlukan bilangan delta yang lebih panjang. Teks Mandarin dengan banyak karakter berbeda biasanya menambah sekitar 2–3 huruf ekstra per karakter, itulah sebabnya label CJK kehabisan ruang di suatu tempat sekitar 20–40 karakter meskipun batas label adalah 63 byte.

Dekode adalah resep yang sama dibalik: salin awalan ASCII, baca digitnya, ubah delta kembali menjadi titik kode, dan sisipkan setiap karakter baru ke dalam string pada posisi yang dikodekan oleh delta. Hanya digit huruf kecil yang ada dalam bootstring, itulah sebabnya huruf kapital di dalam bagian yang dikodekan ditolak alih-alih ditebak — DNS tidak peka huruf besar-kecil, sehingga mengizinkan keduanya akan membuat dua ejaan berbeda menjadi ambigu.

• Di bilah alamat. Browser mungkin menampilkan xn--fiq228c.com alih-alih 中文.com. Itu situs yang sama. Beberapa browser sengaja menampilkan bentuk Punycode ketika nama mencampur skrip, justru agar karakter yang mirip (Sirilik а versus Latin a) tidak bisa bersembunyi di URL.
• Dalam DNS itu sendiri. Berkas zona, jawaban dig / nslookup / DNS-over-HTTPS, dan log resolver hanya memuat bentuk xn--; Unicode biasa ditolak atau rusak tanpa pemberitahuan.
• Dalam sertifikat TLS. Subject alternative name untuk domain internasional disimpan sebagai label-A (DNS:xn--fiq228c.com), sehingga sertifikat yang tidak terlihat seperti nama yang Anda ketik adalah hal normal, bukan ketidakcocokan.
• Dalam konfigurasi dan alat. Entri server_name server web / host virtual, domain cookie, panel hosting dan CDN, domain surel, kunci API yang terikat pada domain, dan kunci basis data semuanya lebih aman dalam bentuk label-A.
• Dalam pengujian dan pipeline data. Beberapa pustaka meneruskan Unicode langsung ke resolver dan gagal; mengonversi ke Punycode terlebih dahulu adalah perbaikan standar. Karena pemetaannya kanonik — satu label Unicode dipetakan tepat ke satu label-A — bentuk xn-- juga menjadi pengenal yang stabil untuk log dan pencarian.

Punycode adalah ejaan yang dapat dibalik, tidak lebih. Ia bukan enkripsi dan bukan fitur keamanan: siapa pun dapat mendekodenya dengan alat di atas, sehingga label xn-- hanya menyatakan “ini telah dikodekan” dan tidak menyatakan apa pun tentang siapa pemiliknya. Ia juga bukan kompresi — biasanya membuat teks lebih panjang, seperti contoh 6 byte menjadi 11 byte di atas. Dan ia bukan hal yang sama dengan cara lain Unicode berpindah di internet; cara-cara itu memecahkan lapisan masalah yang berbeda.

Skema	Mengubah apa menjadi apa	Di mana digunakan	中文 menjadi
Punycode (RFC 3492)	Label domain Unicode menjadi huruf dan digit ASCII	Hanya label domain internasional	xn--fiq228c
UTF-8 (RFC 3629)	Titik kode menjadi byte	Setiap berkas dan permintaan web	E4 B8 AD E6 96 87 (6 byte)
Pengodean persen (RFC 3986)	Byte menjadi escape %XX	Jalur URL, string kueri, isi formulir	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Byte menjadi 64 karakter ASCII	Biner di dalam teks, JSON, surel, URL data	5Lit5paH
Entitas HTML	Titik kode menjadi referensi bernama atau numerik	Sumber HTML dan XML	中文
Escape Unicode	Titik kode menjadi \uXXXX	Kode sumber dan string literal JSON	\u4e2d\u6587

Kesimpulan praktisnya: Punycode berlaku untuk label domain dari sebuah URL, bukan untuk seluruh URL. Jalur dan string kueri adalah masalah yang berbeda dan menggunakan pengodean persen (lihat Pengodean URL).

• Batas ukuran berasal dari DNS, bukan dari Punycode. Satu label boleh paling banyak 63 byte dan satu nama lengkap paling banyak 255 byte (RFC 1034 / 1035). Karena label-A adalah ASCII murni, jumlah byte sama dengan jumlah karakter, dan setiap karakter non-ASCII menghabiskan sebagian anggaran itu — kira-kira 1 karakter anggaran untuk setiap 1–4 huruf Punycode.
• Punycode mengonversi apa pun; registri hanya mengizinkan sebagian. Aturan IDNA berlaku di atasnya dan membatasi titik kode mana yang boleh didaftarkan — huruf kapital, spasi, tanda baca seperti !, dan simbol tidak legal dalam domain nyata. Halaman ini melakukan konversi RFC 3492, sehingga dengan senang hati akan mengodekan teks yang akan ditolak registri.
• Tetaplah dalam satu skrip. IDNA tidak menyarankan pencampuran skrip dalam satu label justru karena serangan karakter mirip. Sebuah nama dapat dikodekan dan tetap tidak dapat digunakan, atau dapat digunakan tetapi diblokir oleh browser.
• Jangan mengodekan dua kali. xn-- yang diikuti teks yang sudah dikodekan tidak valid, dan label yang ASCII murni tidak pernah berubah sama sekali — tidak ada yang perlu dikodekan, sehingga tidak ada awalan yang ditambahkan.
• Titik di akhir tidak masalah. 例え.jp. adalah nama yang memenuhi syarat penuh dan label kosong di akhir dipertahankan; label kosong di tengah tidak valid sebagai nama host.

“Mengapa domain Mandarin tampil sebagai xn--fiq228c.com di bilah alamat?”

Karena browser memilih untuk merender label-A. Situsnya identik; gunakan arah Dekode di halaman ini untuk melihat bentuk Unicode, atau kodekan bentuk Unicode untuk memeriksa bahwa kedua ejaan cocok.

“Apakah perlu mengubah catatan DNS, sertifikat, atau hosting?”

Tidak. Simpan label-A xn-- di mana pun mesin membaca nama (DNS, sertifikat, konfigurasi), dan gunakan bentuk Unicode hanya di tempat manusia membacanya.

“Mengapa hasilnya lebih panjang dari yang diketik?”

Karena pengodean tidak membawa karakter itu sendiri, melainkan membawa jarak basis-36, dan alfabet 36 karakter harus mengeja bilangan yang bisa besar. Pertumbuhan adalah hal yang diharapkan, bukan bug.

“Mengapa dekode menyebut ‘huruf kapital’?”

Karena digit bootstring didefinisikan hanya huruf kecil (a-z, 0-9). Huruf A-Z kapital setelah tanda hubung terakhir bersifat ambigu mengingat DNS tidak peka huruf besar-kecil, sehingga dilaporkan alih-alih ditebak diam-diam.

“Apakah Punycode berlaku untuk bagian sebelum @ dalam alamat surel?”

Hanya bagian domain yang merupakan nama DNS dan dapat berupa Punycode. Bagian lokal ditangani oleh sistem surel, bukan oleh DNS, sehingga pengodean ini tidak berlaku untuknya.

“Bisakah dua nama Unicode berbeda menghasilkan label-A yang sama?”

Tidak. Pengodean ini injektif: urutan titik kode yang berbeda selalu menghasilkan bootstring yang berbeda, sehingga mendekode xn--fiq228c mengembalikan tepat 中文 dan tidak yang lain. Yang bisa bertabrakan adalah tampilan — karakter berbeda yang terlihat mirip — yang merupakan sifat dari repertoar Unicode, bukan dari pengodean.

• RFC 3492 — Punycode, pengodean bootstring yang diimplementasikan di halaman ini. Vektor yang diketahui yang dikutip di atas diperiksa terhadap string contoh dalam dokumen itu.
• RFC 5890, RFC 5891, RFC 5892 dan Unicode UTS #46 — IDNA2008 dan interpretasi sisi browsernya, aturan yang menentukan karakter mana yang legal, bagaimana label dinormalisasi, dan bagaimana skrip boleh dicampur.
• RFC 1034 dan RFC 1035 — batas label 63 byte dan nama 255 byte yang diwarisi dari DNS.
• RFC 3490 dan RFC 3491 — generasi IDNA2003 yang lebih lama, digantikan oleh IDNA2008. Jika sebuah nama berperilaku berbeda di perangkat lunak lama, biasanya inilah penyebabnya.

Catatan ruang lingkup: alat ini hanya melakukan konversi RFC 3492 dan tidak lain. Ia bukan validator IDN dan tidak memeriksa aturan pendaftaran, harga, atau ketersediaan domain — dan karena tidak pernah menghubungi jaringan, ia tidak dapat memberi tahu apakah sebuah nama ada.

Coba di atas: tempel 中文 dan tekan Kodekan Teks → Punycode untuk melihat label-A, atau tempel xn--fiq228c dan tekan Dekode Punycode → Teks untuk mendapatkan kembali karakternya.