Alat pengembang · URL encoder & decoder
Punycode vs persen-encoding: bagaimana domain dan jalur non-ASCII ditangani
· Latar belakang
internasionalisasi kode kecil pengkodean url
URL dengan nama host non-ASCII dan jalur non-ASCII menggunakan dua pengkodean yang sangat berbeda. Posting ini menjelaskan IDNA dan punycode untuk host, pengkodean persen untuk yang lainnya, dan mengapa pemisahan itu terjadi.
Alamat yang menampilkan 'münchen.example' di satu browser dan 'xn--mnchen-3ya.example' di browser lain — satu host, dua ejaan
Kota München muncul dalam nama domain Jerman. Di bilah alamat browser Anda, Anda mungkin melihat münchen.example ditampilkan secara normal. Salin alamat dari aplikasi lain, dan alamat tersebut akan muncul sebagai xn--mnchen-3ya.example, sebuah string khusus ASCII yang tidak terlihat seperti teks bahasa Jerman. Satu URL, dua ejaan, keduanya benar-benar valid. Tidak ada yang salah; mereka mewakili domain yang sama menggunakan jaringan karakter yang sangat berbeda. Perbedaan tersebut mencerminkan kendala mendasar pada cara kerja DNS dan cara infrastruktur Internet mengharapkan nama host dikirimkan.
Segmen jalur seperti /café/ memerlukan pengkodean tetapi menggunakan sistem yang berbeda. Non-ASCII é menjadi %C3%A9 di jalur. Mengapa ada perbedaan? Batasan DNS memerlukan kode puny untuk nama host.
Mengapa nama host tidak dapat menggunakan pengkodean persen — DNS label, karakter yang diizinkan, dan batas panjang
Label DNS, segmen individual dari nama host yang dipisahkan oleh titik, memiliki aturan yang sangat ketat. Mereka hanya boleh berisi ASCII huruf, angka, tanda hubung, dan garis bawah. Mereka memiliki batasan panjang: setiap label dapat berisi paling banyak 63 oktet, dan nama host lengkap tidak boleh melebihi 255 oktet. Ini adalah batasan keras dari protokol DNS itu sendiri, yang ditetapkan beberapa dekade lalu sebelum nama domain internasional menjadi sebuah konsep. Pengkodean persen tidak dapat berfungsi untuk nama host karena string yang dihasilkan kemungkinan akan melebihi batas label pada kata yang lebih panjang.
Lebih penting lagi, DNS adalah sistem global yang dioperasikan oleh router dan server di seluruh dunia. Tidak semuanya memahami UTF-8 atau Unicode. Karakter berkode persen seperti %C3%A9 masih terdiri dari tiga karakter ASCII, sehingga sesuai dengan batasan DNS. Namun pendekatan itu berarti setiap pencarian harus melakukan enkode persen saat masuk dan mendekode saat keluar, sehingga menambah kompleksitas pada lapisan protokol itu sendiri. Solusi yang lebih baik diperlukan untuk nama host secara khusus.
IDNA dan punycode secara garis besar — awalan xn-- dan algoritme bootstring, dijelaskan secara kualitatif
IDNA, spesifikasi Nama Domain yang Diinternasionalkan dalam Aplikasi, memecahkan masalah nama host dengan menyandikan nama domain non-ASCII ke dalam ASCII yang dapat ditangani oleh DNS. Pengkodean yang digunakan disebut punycode, yaitu algoritma kompresi yang mengubah teks Unicode menjadi ASCII menggunakan awalan xn-- diikuti dengan representasi kode bootstring. Algoritmenya bersifat deterministik: münchen selalu menjadi xn--mnchen-3ya setiap saat. Nama host non-ASCII apa pun harus dikonversi dengan cara ini sebelum resolusi DNS dapat terjadi.
Awalan xn-- memberi sinyal ke DNS dan ke IDNA perangkat lunak yang mengetahui bahwa karakter berikut adalah kode puny, bukan huruf ASCII literal. Domain seperti example.xn--mnchen-3ya.com dipahami sebagai example.münchen.com oleh perangkat lunak yang sadar IDNA. Punycode hanya menggunakan ASCII huruf, angka, dan tanda hubung, sehingga cocok dengan label DNS tanpa masalah. Algoritme memampatkan informasi non-ASCII ke dalam representasi ASCII ini.
Jalur, kueri, dan fragmen tetap dikodekan dalam persen — UTF-8 byte hingga %XX, seperti di tempat lain
Segala sesuatu yang lain di URL—jalur, string kueri, fragmen—menggunakan pengkodean persen sebagai gantinya. Karakter non-ASCII terlebih dahulu dikonversi menjadi UTF-8 byte, kemudian setiap byte ditulis sebagai %HH dengan HH dalam heksadesimal. Jalur /café/ menjadi /caf%C3%A9/. String kueri ?name=josé menjadi ?name=jos%C3%A9. Pengkodean persen merupakan standar di mana pun di web: di HTTP URL permintaan, dalam formulir HTML, di API. Tidak memerlukan penanganan khusus oleh DNS atau router.
Pengkodean persen juga memungkinkan karakter khusus lainnya direpresentasikan dengan aman. Spasi menjadi %20, garis miring (jika harus muncul di dalam nilai) menjadi %2F, dan seterusnya. Skema ini konsisten dan universal. Ini tidak digunakan untuk nama host karena DNS tidak memahami URL atau pengkodean persen; ia hanya memahami label ASCII.
Contoh praktis: satu URL dengan keduanya — host dikonversi ke punycode, jalurnya dikodekan persen, berdampingan
Ambil URL "https://münchen.example/café?city=münchen". Nama host münchen harus dikonversi ke punycode sebelum pencarian DNS: https://xn--mnchen-3ya.example/café?city=münchen. Tapi tunggu—jalur dan kueri juga memiliki non-ASCII. Konversikan juga: https://xn--mnchen-3ya.example/caf%C3%A9?city=m%C3%BCnchen. Sekarang nama hostnya adalah punycode, jalur dan kuerinya dikodekan dalam persen. Browser akan ditampilkan versi Unicode asli agar mudah dibaca; permintaan HTTP membawa versi yang disandikan.
Di alat encoder & decoder URL, tempelkan jalur yang berisi teks non-ASCII dan bandingkan mode nilai tunggal (hanya jalurnya) dengan mode seluruh alamat (URL lengkap). Alat ini menunjukkan kepada Anda hasil yang dikodekan persen untuk jalur tersebut. Namun, nama host memerlukan konversi kode kecil yang terpisah; sebagian besar alat pengkodean tidak menangani inline tersebut, jadi bacalah dari dokumentasi alat.
Serangan homograf dan mengapa browser terkadang menampilkan punycode — alasan keamanan di balik aturan tampilan
Aktor jahat dapat mendaftarkan domain menggunakan huruf Sirilik yang secara visual terlihat identik dengan huruf Latin, seperti "https://xn--80akhbyknj4f.example" (versi Sirilik dari "example.example" dalam kode punycode). Jika browser menampilkannya yang didekodekan sebagai teks Sirilik, pengguna mungkin tidak menyadari perbedaannya. Untuk mencegah serangan homograf, browser terkadang menampilkan versi punycode alih-alih mendekodekannya. Sebuah peringatan muncul: domain ini seluruhnya atau sebagian besar non-ASCII, dan Anda mungkin tidak mengenali karakternya.
Encoder & decoder URL adalah alat untuk pengkodean dan penguraian kode, bukan untuk penilaian keamanan. Jika Anda bekerja dengan nama domain internasional, ketahuilah bahwa representasi punycode adalah apa yang dilihat jaringan.
Apa yang tidak tercakup di sini - menjalankan algoritma punycode dengan tangan atau perbedaan IDNA 2003 versus 2008
IDNA telah melewati beberapa versi dari waktu ke waktu: IDNA 2003 dan IDNA 2008 menangani kasus edge tertentu secara berbeda, khususnya seputar normalisasi dan karakter Unicode mana yang diizinkan berdasarkan spesifikasi. Beberapa sistem lama masih menggunakan IDNA 2003 sementara sistem lainnya telah bermigrasi ke IDNA 2008 untuk kepatuhan yang lebih baik. Perbedaannya sangat penting jika Anda membangun sistem yang harus kompatibel di berbagai versi. Periksa selalu persyaratan sistem Anda dengan cermat.
Punycode menggunakan kompresi bootstring. Penerapannya ada dalam bahasa umum, tetapi verifikasi kebijakan IDNA dengan sistem nama host Anda. Uji resolusi dan perilaku tampilan, bukan berasumsi.
Kesimpulan: dua pengkodean untuk dua pekerjaan — bagaimana encoder & decoder URL menangani bagian yang dikodekan persen, dan mengapa encoder persen adalah alat yang salah untuk nama host
Nama host memerlukan kode kecil karena DNS adalah protokol lama yang hanya memahami label ASCII dan memiliki batasan panjang dan karakter yang ketat. Jalur, kueri, dan fragmen menggunakan pengkodean persen karena bersifat universal di web dan tidak memiliki batasan tersebut. Keduanya adalah dua solusi terpisah untuk dua masalah yang sangat berbeda. Saat Anda menemukan non-ASCII URL, nama host mendapatkan konversi punycode terlebih dahulu, kemudian sisanya menggunakan pengkodean persen.
Untuk sebagian besar pekerjaan pengembangan, kerangka kerja atau pustaka Anda menangani konversi ini di belakang layar secara otomatis. Namun memahami mengapa ada dua penyandian berbeda akan mencegah kebingungan saat melakukan debug pada URL internasional atau berhasil menerapkan kode penanganan URL Anda sendiri.