Alat pembangun · URL pengekod & penyahkod
Punycode vs peratusan pengekodan: cara domain dan laluan bukanASCII dikendalikan
· Latar belakang
pengantarabangsaan punycode pengekodan url
URL dengan nama hos bukan ASCII dan laluan bukan ASCII menggunakan dua pengekodan yang berbeza sama sekali. Siaran ini menerangkan IDNA dan kod puny untuk hos, pengekodan peratus untuk semua yang lain dan sebab perpecahan itu wujud.
Alamat yang menunjukkan 'münchen.example' dalam satu pelayar dan 'xn--mnchen-3ya.example' dalam satu lagi — satu hos, dua ejaan
Bandar München muncul dalam nama domain Jerman. Dalam bar alamat pelayar anda, anda mungkin melihat münchen.example dipaparkan seperti biasa. Salin alamat daripada aplikasi lain dan ia kelihatan sebagai xn--mnchen-3ya.example, rentetan ASCII sahaja yang tidak kelihatan seperti teks Jerman. Satu URL, dua ejaan, kedua-duanya sah sepenuhnya. Tidak salah; mereka mewakili domain yang sama menggunakan set aksara yang sama sekali berbeza. Perbezaan ini mencerminkan kekangan asas tentang cara DNS berfungsi dan cara infrastruktur Internet menjangkakan nama hos dihantar.
Segmen laluan seperti /café/ memerlukan pengekodan tetapi menggunakan sistem yang berbeza. Non-ASCII é menjadi %C3%A9 dalam laluan. Mengapa perbezaannya? DNS kekangan memerlukan kod puny untuk nama hos.
Mengapa nama hos tidak boleh menggunakan pengekodan peratus — DNS label, aksara yang dibenarkan dan had panjang
Label DNS, segmen individu nama hos yang dipisahkan dengan titik, mempunyai peraturan yang sangat ketat. Ia sahaja boleh mengandungi ASCII huruf, digit, sempang dan garis bawah. Mereka mempunyai had panjang: setiap label boleh paling banyak 63 oktet dan nama hos penuh tidak boleh melebihi 255 oktet. Ini adalah kekangan keras daripada protokol DNS itu sendiri, yang ditakrifkan beberapa dekad yang lalu sebelum nama domain antarabangsa menjadi satu konsep. Pengekodan peratus tidak boleh berfungsi untuk nama hos kerana rentetan yang terhasil mungkin akan melebihi had label pada perkataan yang lebih panjang.
Lebih penting lagi, DNS ialah sistem global yang dikendalikan oleh penghala dan pelayan di seluruh dunia. Tidak semua daripada mereka memahami UTF-8 atau Unicode. Aksara yang dikodkan peratus seperti %C3%A9 masih mempunyai tiga aksara ASCII, jadi ia sesuai dengan kekangan DNS. Tetapi pendekatan itu bermakna setiap carian perlu mengekod peratus semasa masuk dan menyahkod semasa keluar, menambah kerumitan pada lapisan protokol itu sendiri. Penyelesaian yang lebih baik diperlukan untuk nama hos khususnya.
IDNA dan kod puny dalam garis besar — awalan xn-- dan algoritma rentetan tetapi, diterangkan secara kualitatif
IDNA, Spesifikasi Nama Domain Antarabangsa dalam Aplikasi, menyelesaikan masalah nama hos dengan mengekodkan nama domain bukan ASCII ke dalam ASCII yang boleh dikendalikan oleh DNS. Pengekodan yang digunakan dipanggil punycode, algoritma pemampatan yang menukar teks Unicode kepada ASCII menggunakan awalan xn-- diikuti dengan perwakilan berkod rentetan tetapi. Algoritma adalah deterministik: münchen sentiasa menjadi xn--mnchen-3ya setiap masa. Mana-mana nama hos bukanASCII mesti ditukar dengan cara ini sebelum resolusi DNS boleh berlaku.
Awalan xn-- memberi isyarat kepada DNS dan kepada perisian IDNA-sedar bahawa aksara berikut adalah kod puny, bukan huruf ASCII literal. Domain seperti example.xn--mnchen-3ya.com difahami bermaksud contoh.münchen.com oleh perisian IDNA-sedar. Punycode sahaja menggunakan ASCII huruf, digit dan sempang, jadi ia sesuai dengan kemas ke dalam label DNS tanpa masalah. Algoritma memampatkan maklumat yang tidak ASCII ke dalam perwakilan ASCII ini.
Laluan, pertanyaan dan serpihan kekal peratusan dikodkan — UTF-8 bait hingga %XX, seperti di tempat lain
Semua yang lain dalam URL—laluan, rentetan pertanyaan, serpihan—sebaliknya menggunakan pengekodan peratus. Aksara bukan ASCII mula-mula ditukar kepada UTF-8 bait, kemudian setiap bait ditulis sebagai %HH di mana HH ialah perenambelasan. Laluan /café/ menjadi /caf%C3%A9/. Rentetan pertanyaan ?name=josé menjadi ?name=jos%C3%A9. Pengekodan peratusan adalah standard di mana-mana di web: dalam HTTP meminta URL, dalam bentuk HTML, dalam API. Ia tidak memerlukan pengendalian khas oleh DNS atau penghala.
Pengekodan peratusan juga membenarkan aksara khas lain untuk diwakili dengan selamat. Ruang menjadi %20, garis miring (jika ia mesti muncul di dalam nilai) menjadi %2F dan seterusnya. Skim ini konsisten dan universal. Ia tidak digunakan untuk nama hos kerana DNS tidak memahami URL atau pengekodan peratus; ia sahaja memahami ASCII label.
Contoh berfungsi: satu URL dengan kedua-duanya — hos ditukar kepada kod puny, laluan dikodkan peratus, bersebelahan
Ambil URL "https://münchen.example/café?city=münchen". Nama hos münchen mesti ditukar kepada punycode sebelum ini DNS carian: https://xn--mnchen-3ya.example/café?city=münchen. Tetapi tunggu—laluan dan pertanyaan juga tidak mempunyaiASCII. Tukar mereka juga: https://xn--mnchen-3ya.example/caf%C3%A9?city=m%C3%BCnchen. Sekarang nama hos ialah punycode, laluan dan pertanyaan dikodkan peratus. Pelayar memaparkan versi Unicode asal untuk kebolehbacaan; yang HTTP permintaan membawa versi yang dikodkan.
Dalam alat pengekod & penyahkod URL, tampalkan laluan yang mengandungi teks bukan ASCII dan bandingkan mod nilai tunggal (sahaja laluan) dengan mod alamat keseluruhan (URL penuh). Alat ini menunjukkan kepada anda hasil peratusan yang dikodkan untuk laluan. Nama hos, bagaimanapun, memerlukan penukaran kod puny berasingan; kebanyakan alat pengekodan tidak mengendalikan sebaris itu, jadi bacalah dari dokumentasi alat.
Serangan homograf dan sebab pelayar kadangkala menunjukkan kod puny — alasan keselamatan di sebalik peraturan paparan
Pelakon berniat jahat boleh mendaftarkan domain menggunakan huruf Cyrillic yang kelihatan sama secara visual dengan huruf Latin, seperti "https://xn--80akhbyknj4f.example" (versi Cyrillic "example.example" dalam kod puny). Jika pelayar memaparkannya dinyahkodkan sebagai teks Cyrillic, pengguna mungkin tidak menyedari perbezaannya. Untuk mengelakkan serangan homograf, pelayar kadangkala menunjukkan versi amaran atau penyahkodan ini. kebanyakannya bukan-ASCII, dan anda mungkin tidak mengenali aksara.
Pengekod & penyahkod URL ialah alat untuk pengekodan dan penyahkodan, bukan untuk penilaian keselamatan. Jika anda bekerja dengan nama domain antarabangsa, ambil perhatian bahawa perwakilan kod puny ialah apa yang dilihat oleh rangkaian.
Perkara ini tidak meliputi — menjalankan algoritma punycode dengan tangan atau perbezaan IDNA 2003 berbanding 2008
IDNA telah melalui berbilang versi dari semasa ke semasa: IDNA 2003 dan IDNA 2008 mengendalikan kes tepi tertentu secara berbeza, terutamanya sekitar penormalan dan aksara Unicode yang dibenarkan mengikut spesifikasi. Sesetengah sistem lama masih menggunakan IDNA 2003 manakala yang lain telah berhijrah ke IDNA 2008 untuk pematuhan yang lebih baik. Perbezaannya amat penting jika anda membina sistem yang mesti serasi merentas berbilang versi. Semak keperluan sistem anda dengan teliti sentiasa.
Punycode menggunakan pemampatan rentetan tetapi. Pelaksanaan wujud dalam bahasa biasa, tetapi sahkan dasar IDNA dengan sistem nama hos anda. Resolusi ujian dan tingkah laku paparan dan bukannya mengandaikan.
Bawa pulang: dua pengekodan untuk dua kerja — cara pengekod & penyahkod URL mengendalikan bahagian yang dikodkan peratus dan sebab pengekod peratus ialah alat yang salah untuk nama hos
Nama hos memerlukan kod puny kerana DNS ialah protokol lama yang sahaja memahami label ASCII dan mempunyai kekangan panjang dan aksara yang ketat. Laluan, pertanyaan dan serpihan menggunakan pengekodan peratus kerana ia bersifat universal di web dan tidak mempunyai kekangan tersebut. Mereka adalah dua penyelesaian berasingan untuk dua masalah yang sama sekali berbeza. Apabila anda menemui bukan ASCII URL, nama hos mendapat penukaran kod puny dahulu, kemudian yang lain menggunakan pengekodan peratus.
Untuk kebanyakan kerja pembangunan, rangka kerja atau pustaka anda mengendalikan penukaran ini di belakang tabir secara automatik. Tetapi memahami mengapa dua pengekodan berbeza wujud menghalang kekeliruan apabila menyahpepijat URL antarabangsa atau melaksanakan kod pengendalian URL anda sendiri dengan jayanya.