Pemeriksa Homograf IDN

Nama hanya ASCII selama dua dekade pertama DNS, itulah sebabnya segala hal tentangnya diukur dalam byte dan huruf: label berisi huruf, angka, dan tanda hubung, paling banyak 63 byte masing-masing, paling banyak 255 byte secara total. Nama domain internasional (IDN) adalah hasil dari dibukanya aturan untuk seluruh Unicode, dan punycode (RFC 3492) adalah aturan ejaan yang membuat mesin lama tetap berfungsi: label yang mengandung apa pun di luar ASCII ditulis sebagai label xn--, string ASCII yang membawa karakter yang sama dalam bentuk terlipat. 中文.com berpindah sebagai xn--fiq228c.com, dan kedua ejaan itu menamai host yang sama.

Bagian yang penting di sini adalah apa yang tidak dilakukan punycode. Ia hanya mengonversi ejaan dan tidak ada yang lain. Ia tidak memiliki pendapat tentang apakah аpple.com boleh berdampingan dengan apple.com, dan pertanyaan itu tidak dapat diajukan kepadanya, karena pertanyaan itu menyangkut mata dan font, bukan byte. Registri memutuskan karakter apa yang akan dijual, browser memutuskan cara menampilkan nama yang dianggapnya aman, dan pembaca memutuskan apakah akan mengklik. Halaman ini menjawab pertanyaan di bawah ketiganya: karakter apa sebenarnya yang menyusun nama ini, dan apa yang membuatnya mengeja?

Setiap baris di bawah dijalankan oleh halaman ini saat dimuat dan kembali dijalankan oleh tombol Uji mandiri, dan halaman harus melaporkan persis apa yang dikatakan baris itu — temuan yang sama, tingkat yang sama, bentuk DNS yang sama, jumlah byte yang sama, tidak lebih dan tidak kurang. Itulah yang membuat jawaban bersih di sini bernilai: jalur kode yang meloloskan nama biasa adalah jalur yang sama yang menangkap trik-trik di bawah.

1. Ambil nama dari apa yang Anda tempel. Nama polos digunakan apa adanya; URL diambil host-nya, sementara skema, port, path, dan query dibuang, dan halaman menyebutkan mana dari keduanya yang dilakukannya, alih-alih diam-diam menganalisis garis miring seolah itu bagian dari nama.
2. Bersihkan seperti klien akan melakukannya. Karakter kontrol, karakter zero width, dan tanda urutan byte dibuang; titik penuh lebar atau ideografis dihitung sebagai titik, dan titik di akhir adalah root, bukan kesalahan. Setiap karakter yang dihapus atau ditafsirkan ulang dengan cara ini dilaporkan, karena spasi zero width yang dibuang diam-diam adalah hal persis yang perlu Anda ketahui.
3. Pisahkan menjadi label dan ukur masing-masing. Label tidak boleh kosong, tidak boleh diawali atau diakhiri tanda hubung, dan tidak boleh memuat dua tanda hubung pada posisi ketiga dan keempat kecuali jika itu label xn--. Setiap label diukur dalam byte UTF-8 terhadap batas 63 byte, dan seluruh nama terhadap 255.
4. Dekode setiap label xn-- kembali ke karakternya. Label yang didekode kemudian dienkode lagi dan dibandingkan dengan apa yang Anda ketik. Label yang tidak lolos putaran bolak-balik itu bukanlah label yang diklaimnya, dan label yang didekode menjadi karakter kontrol atau tidak menjadi apa pun dilaporkan sebagaimana adanya, alih-alih dibuang diam-diam.
5. Tanyakan apa setiap karakter itu. Code point-nya, byte UTF-8-nya, skrip tempat ia termasuk, apakah ia berada dalam kelompok karakter yang digambar serupa, dan apa anggota lain dari kelompok itu. Di sinilah huruf a Sirilik berhenti menjadi "sebuah huruf" dan menjadi "huruf yang berbentuk seperti huruf Latin".
6. Lipat nama ke bentuk yang ditirunya. Setiap karakter yang mirip diganti dengan karakter yang menyerupainya, sehingga аpple.com menjadi apple.com. Pembacaan yang dilipat itu adalah baris paling berguna di halaman ini, karena apple.com dapat Anda tindak lanjuti, sedangkan "huruf a Sirilik" tidak.
7. Kumpulkan temuan dan laporkan yang terburuk. Setiap temuan dilaporkan sekali, dengan label tempat ia muncul. Nama yang hanya tampak tidak biasa menghasilkan catatan, bukan temuan: mencampur Han dan Kana, atau diakhiri titik root, adalah tulisan biasa, bukan alasan untuk khawatir.

none tidak ada yang perlu disebutkan di sini — low nama yang sama ditulis dengan cara kedua — medium karakter yang tidak dapat dibawa DNS, atau yang terlipat ke huruf biasa — high nama yang dibuat untuk dibaca sebagai nama lain, atau yang sama sekali tidak dapat dikirim.

Tingkat adalah makna terburuk dari temuan, bukan probabilitas dan bukan penilaian terhadap situs. Nama yang sepenuhnya jujur dapat berada di tingkat sedang karena memuat satu karakter di luar abjad nama host, dan nama yang bermusuhan dapat berada di tingkat tinggi hanya dengan satu huruf Sirilik di dalamnya. Daftar di bawah tingkat menjelaskan alasannya, satu baris per temuan, dan daftar itulah bagian yang layak dibaca.

Tabel di bawah dibangun dari daftar yang sama dengan yang dilaporkan halaman, sehingga baris di sini dan temuan dalam hasil tidak akan berselisih. Pemeriksaan yang tidak menemukan apa pun dicantumkan sebagai tidak: intinya adalah Anda dapat melihat bahwa pertanyaan itu diajukan dan dijawab, alih-alih bertanya-tanya apakah pertanyaan itu diajukan sama sekali.

Daftar yang sama menggerakkan catatan, yang tidak membawa tingkat sama sekali: satu label tanpa titik, titik root di akhir, nama domain tingkat atas yang bukan ASCII, pemisah selain titik, nama huruf besar, karakter yang dihapus saat pembersihan, dan URL yang dipangkas menjadi host-nya.

Sebuah nama adalah daftar label, dan setiap label dihitung dalam byte, bukan dalam karakter. Perbedaan itulah alasan seluruh punycode ada: 中文 adalah dua karakter dan enam byte, dan bentuk xn---nya adalah lima belas karakter, sehingga ejaan terenkodelah yang harus muat. Halaman ini menerapkan kedua batas dan melaporkan batas mana yang terlampaui.

Anda mungkin pernah memperhatikan bahwa nama yang ditulis dalam aksara Tionghoa, atau Sirilik, kadang muncul di bilah alamat sebagai teks xn-- yang tidak bermakna, alih-alih karakter yang Anda harapkan. Itu adalah browser yang menolak menampilkan bentuk yang bagus, bukan situs yang gagal mendaftarkannya. Browser menerapkan aturannya sendiri pada nama yang belum pernah dilihatnya sebelumnya, dan aturan itu ada karena alasan yang menjadi dasar seluruh halaman ini: menampilkan аpple.com sebagai аpple.com justru yang diinginkan penyerang, sehingga nama skrip campuran yang tidak familiar ditampilkan dalam ejaan terenkodenya sampai cukup sering terlihat untuk dipercaya.

Punycode adalah RFC 3492, dan uji mandiri di halaman ini menjalankan sebelas label contoh yang dicetak dalam dokumen itu sebagai pemeriksaan pertamanya, sehingga pengodenya di sini diuji dengan contoh-contoh dalam standar, bukan dengan dirinya sendiri. Aturan pemrosesan yang dilalui IDN adalah RFC 5891 dengan tabel karakter dari RFC 5892, dan lapisan kompatibilitas yang sebenarnya diterapkan browser adalah UTS #46 dengan bendera non-transitional; halaman ini menjelaskan apa yang dilakukan aturan-aturan itu alih-alih berpura-pura mengimplementasikannya, dan pelipatan yang diterapkannya — NFC lalu huruf kecil, lalu RFC 3492 — adalah urutan singkat yang sama yang dilakukan klien sebelum nama dikirim. Grup bentuk, rentang skrip, dan tabel karakter tak terlihat dalam keluarga halaman ini ditulis secara manual untuk keluarga ini: standarnya disebut agar Anda dapat membacanya sendiri, dan tidak ada teks dari standar itu yang direproduksi di sini.

Apakah nama skrip campuran selalu merupakan serangan?

Tidak, dan memperlakukannya seperti itu akan keliru dengan cara yang penting. Bahasa Jepang menulis karakter Han dan Kana dalam satu kata yang sama, dan bahasa Korea menulis karakter Han di dalam Hangul. Yang tidak memiliki penjelasan biasa adalah Latin yang dicampur dengan Sirilik atau Yunani dalam satu label, karena skrip-skrip itu tidak digunakan bersama dalam bahasa mana pun, dan halaman ini menarik garis di sana alih-alih menandai setiap campuran. Itulah sebabnya baris Jepang dan Korea pada tabel kasus di atas kembali bersih.

Lalu mengapa nama sendiri dikembalikan sebagai sedang?

Kemungkinan besar karena ia memuat satu karakter yang tidak termasuk dalam abjad nama host — garis bawah, spasi, atau aksen yang ditulis sebagai karakter kompatibilitas — dan itu adalah tingkat sedang karena nama tersebut tidak dapat dikirim apa adanya. Sedang berarti "ini perlu diperiksa", bukan "ini pemalsuan". Temuan di bawah tingkat menyebut karakter persis dan posisinya.

Apakah halaman ini memberi tahu apakah sebuah nama berbahaya, terdaftar, atau dapat dijangkau?

Tidak, untuk ketiganya. Halaman tidak pernah menyentuh jaringan dan tidak pernah menyelesaikan apa pun, sehingga tidak dapat mengetahui apakah sebuah nama ada atau siapa pemiliknya, dan dengan sengaja tidak mengatakan apa pun tentang apa yang dilakukan situs. Ia menjawab pertanyaan yang lebih sempit yang dapat Anda periksa sendiri: karakter apa saja yang menyusun nama ini, dan jika karakter yang mirip dilipat ke huruf yang ditirunya, apa ejaannya?

Nama dalam aksara Tionghoa dan halaman menyebut domain tingkat atas bukan ASCII. Apakah ada yang salah?

Tidak ada yang salah. TLD Tionghoa berpindah sebagai label xn-- tersendiri, sehingga label terakhir nama ditulis dalam bentuk terenkodenya dan halaman mencatatnya. Catatan tidak membawa tingkat karena menggambarkan fakta, bukan masalah.

Mengapa baris dibaca sebagai kadang menampilkan nama yang sama dengan yang diketik?

Karena halaman hanya menampilkan pembacaan yang dilipat ketika pelipatan benar-benar mengubah sesuatu. Jika setiap karakter dalam nama sudah berbentuk seperti yang ditirunya, pembacaan yang dilipat dan nama itu adalah string yang sama, dan tidak ada yang perlu diberitahukan.

Apa itu A-label dan U-label?

A-label adalah ejaan ASCII yang berpindah tangan: xn--fiq228c. U-label adalah label yang sama yang ditulis dalam skrip apa pun yang menjadi miliknya: 中文. Keduanya adalah dua ejaan dari satu label, dan halaman ini menampilkan keduanya untuk setiap label yang didekodenya agar Anda dapat melihat apa yang disembunyikan label terenkode.