UTS #39 Unicode: Deteksi Karakter Confusable versi 18.0.0

Unicode Technical Standard #39 versi 18.0.0, revisi 34, bertanggal 27 Agustus 2026, adalah spesifikasi resmi Unicode Consortium untuk mendeteksi karakter yang bisa disalahgunakan sebagai identitas. Dokumen ini menjelaskan mekanisme untuk menemukan karakter yang salah pakai dapat membuka celah keamanan pada program dan sistem, mulai dari nama pengguna sampai nama domain.

TL;DR

• UTS #39 adalah standar teknis Unicode untuk keamanan identitas, versi 18.0.0 revisi 34, terbit 27 Agustus 2026.
• Masalah intinya karakter: Unicode memuat sangat banyak karakter yang bentuknya bisa tertukar saat dibaca manusia.
• Spesifikasi ini membagi karakter lewat Identifier_Status dan Identifier_Type, bukan sekadar daftar hitam.
• Deteksi confusable dibedakan antara kasus satu aksara dan kasus campuran beberapa aksara.
• Tersedia profil terpisah untuk identitas umum, nama domain internasional, dan alamat email.

Apa itu UTS #39 dan masalah apa yang diselesaikannya?

UTS #39 adalah singkatan dari Unicode Technical Standard nomor 39 dengan judul Unicode Security Mechanisms, disunting oleh Josh Hadley dan Roozbeh Pournader. Masalah yang diselesaikannya sederhana untuk dijelaskan, tetapi sulit ditutup: karena Unicode memuat begitu banyak karakter dari berbagai sistem tulisan, pemakaian yang salah bisa membuat sebuah nama atau pengenal tampak sama padahal isinya berbeda.

Contoh kasusnya sering dipakai di dunia keamanan. Sebuah nama pengguna yang terlihat identik di layar bisa disusun dari kode karakter yang berbeda, sehingga sistem yang membandingkan teks mentah menganggapnya dua entitas terpisah. Akibatnya bermacam-macam: pendaftaran akun ganda, penipuan nama, sampai pembacaan log yang menyesatkan.

Yang membuat dokumen ini berguna adalah posisinya. Ia bukan catatan blog atau usulan sepihak, melainkan sebuah Unicode Technical Standard yang sudah disetujui untuk publikasi oleh Unicode Consortium dan dinyatakan sebagai dokumen stabil yang boleh dipakai sebagai rujukan normatif oleh spesifikasi lain.

Karakter mana yang dianggap berisiko sebagai identitas?

UTS #39 tidak memakai daftar hitam sederhana. Spesifikasi ini menjelaskan karakter lewat dua atribut, yaitu Identifier_Status dan Identifier_Type, yang disajikan dalam tabel rujukan tersendiri di bagian 3.1 dokumen. Dengan pendekatan itu, sebuah karakter tidak sekadar diberi label aman atau berbahaya, melainkan diberi status sesuai perannya sebagai bagian dari sebuah pengenal.

Di sekitar atribut itu ada pembahasan yang lebih teknis. Bagian 3.1.1 membahas karakter penggabung, termasuk konteks terbatas yang diizinkan untuknya dan ragam keterbatasannya. Bagian 3.1.2 menjelaskan cara memilih nilai Identifier_Type. Kedua bagian itu penting karena keputusan soal karakter penggabung adalah sumber kesalahan paling umum saat organisasi mencoba menulis aturan validasi nama sendiri.

Alasan atribut lebih baik daripada daftar hitam juga praktis. Unicode terus bertambah. Daftar karakter yang dilarang akan cepat basi begitu blok baru ditambahkan, sementara atribut bisa diperbarui oleh pemilik standarnya, dan kode Anda tinggal mengikuti aturan yang sama dari versi ke versi.

Bagaimana cara kerja deteksi confusable?

Confusable detection dijelaskan di bagian 4 dokumen, dan dibedakan menjadi dua kasus: whole-script confusables di bagian 4.1 serta mixed-script confusables di bagian 4.2. Pembedaan ini penting karena keduanya menghasilkan risiko berbeda. Kasus pertama muncul saat seluruh teks ditulis dalam aksara lain yang karakternya menyerupai aksara asli, sementara kasus kedua muncul saat aksara dicampur dalam satu pengenal.

Setelah pembedaan itu, bagian 5 merangkum mekanisme deteksinya. Ada deteksi aksara campuran, deteksi tingkat pembatasan, deteksi angka campuran, dan satu kelompok deteksi opsional. Masing-masing menangkap pola berbeda, sehingga implementasi yang baik biasanya memasang lebih dari satu mekanisme, bukan mengandalkan satu pemeriksaan tunggal.

Alasan deteksi aksara campuran ditempatkan lebih dulu juga masuk akal secara praktis. Sebagian besar sistem yang memakai pengenal berbasis Latin tidak punya alasan sah untuk menerima pengenal yang mencampur beberapa sistem tulisan dalam satu kata. Karena itu, pemeriksaan campuran aksara sering jadi lapisan pertama yang dipasang sebelum pemeriksaan yang lebih rumit.

Perbandingan mekanisme deteksi di UTS #39

Tabel berikut merangkum mekanisme deteksi yang disebut di bagian 5 spesifikasi beserta kapan tiap mekanisme lebih relevan dipakai.

Mekanisme	Bagian dokumen	Cocok dipakai untuk
Deteksi aksara campuran	5.1	Menyaring pengenal yang mencampur beberapa sistem tulisan
Deteksi tingkat pembatasan	5.2	Menerapkan tingkat ketat atau longgar sesuai kebijakan layanan
Deteksi angka campuran	5.3	Menangkap angka dari sistem penomoran berbeda dalam satu pengenal
Deteksi opsional	5.4	Pemeriksaan tambahan yang tidak selalu wajib di setiap sistem

Membaca tabel itu, urutan penerapan yang paling sering dipakai adalah menyaring aksara campuran lebih dulu, lalu menyesuaikan ketatnya aturan lewat tingkat pembatasan, dan menambahkan pemeriksaan angka serta pemeriksaan opsional sesuai karakter layanan Anda.

Kapan profil keamanan identitas perlu dipakai?

Profil dipakai saat Anda perlu memutuskan karakter mana yang boleh muncul sebagai pengenal, bukan sekadar ingin tahu karakter mana yang berbahaya. UTS #39 menyediakan profil umum untuk pengenal di bagian 3.1, profil untuk nama domain internasional di bagian 3.2, dan profil untuk alamat email di bagian 3.3.

Perbedaan profil itu bukan formalitas. Nama domain internasional melewati jalur pengodean khusus supaya nama non-ASCII bisa dipindahkan ke bentuk ASCII, dan proses itu punya aturannya sendiri. Rujukan klasiknya adalah RFC 3492, yang mendefinisikan Punycode sebagai pengodean bootstring untuk nama domain internasional, diterbitkan Maret 2003 oleh A. Costello dari University of California, Berkeley sebagai dokumen Standards Track.

Untuk alamat email, pertimbangannya berbeda lagi karena identitas pengguna sering dipakai lintas layanan dan sering kali harus dibaca manusia. Di sinilah konsistensi jadi taruhan: kalau sistem A menerima sebuah pengenal dan sistem B menolaknya dengan alasan karakter yang tidak terlihat berbeda, pengguna akan menganggap salah satu sistem rusak.

Apa bedanya deteksi confusable dan tingkat pembatasan?

Deteksi confusable mencari pengenal yang bisa tertukar dengan pengenal lain karena bentuk karakternya mirip. Tingkat pembatasan bekerja di lapisan berbeda: ia menentukan seberapa ketat campuran aksara dan angka yang masih Anda izinkan. Keduanya saling melengkapi, bukan saling menggantikan.

Dalam praktik, sistem yang hanya memakai satu di antaranya cenderung punya celah. Sekadar memeriksa confusable tanpa batas campuran aksara membuat pengenal yang aneh tapi belum pernah terdaftar tetap lolos. Sebaliknya, hanya membatasi campuran aksara tanpa memeriksa confusable membuat pengenal yang seluruhnya dari satu aksara mirip tetap bisa menipu pembaca.

Karena alasan itu, spesifikasi ini menyediakan keduanya dalam satu dokumen dan menyusunnya sebagai bagian yang berdampingan: deteksi confusable di bagian 4 dan aneka mekanisme deteksi di bagian 5. Cara membaca yang paling berguna adalah memperlakukannya sebagai satu set lapisan, bukan katalog pilihan.

Bagaimana menerapkan UTS #39 di aplikasi sendiri?

Mulai dari keputusan kebijakan, bukan dari kode. Tentukan lebih dulu jenis pengenal apa yang Anda kelola, lalu pilih profil yang sesuai: profil umum untuk pengenal di bagian 3.1, profil nama domain internasional di bagian 3.2, atau profil email di bagian 3.3. Keputusan ini menentukan kamus karakter yang boleh Anda terima.

Setelah itu, susun lapisan pemeriksaan mengikuti bagian 5. Pasang deteksi aksara campuran sebagai penyaring awal, tentukan tingkat pembatasan yang cocok dengan toleransi layanan Anda, lalu tambahkan deteksi angka campuran bila pengenal Anda memuat angka. Pemeriksaan opsional di bagian 5.4 dipakai paling akhir, karena sifatnya tambahan, bukan syarat minimum.

Untuk karakter penggabung, rujuk bagian 3.1.1 dan 3.1.2 supaya aturan Anda tidak lebih ketat atau lebih longgar daripada standarnya. Ini bagian yang paling sering disalahpahami: banyak sistem melarang semua karakter penggabung, padahal ada konteks terbatas di mana karakter itu sah dan justru dibutuhkan oleh sistem tulisan tertentu.

Terakhir, jangan mematok versi dokumen lalu melupakannya. UTS #39 punya bagian 6 tentang proses pengembangan, yang menunjukkan dokumen ini memang dipelihara dari waktu ke waktu. Karena itu, catat versi yang Anda jadi acuan, misalnya 18.0.0 revisi 34 untuk rilis Agustus 2026, dan jadwalkan peninjauan ulang saat revisi baru terbit.

FAQ

Apa arti kolom identifier_status pada tabel confusables?

Setiap baris pada berkas confusables.txt memuat status pengenal untuk karakter sumbernya. Nilai allowed berarti karakter itu boleh dipakai, restricted berarti hanya boleh dalam konteks terbatas, dan deprecated menandai karakter yang sebaiknya tidak dipakai pada pengenal baru. Kolom inilah yang membuat data yang sama bisa dipakai untuk dua hal sekaligus: mendeteksi kemiripan visual, atau menolak pengenal yang berisiko sejak awal.

Apakah UTS #39 hanya berguna untuk nama domain?

Tidak. Spesifikasi ini memuat profil terpisah untuk pengenal umum, untuk nama domain internasional di bagian 3.2, dan untuk alamat email di bagian 3.3. Jadi pemakaiannya mencakup nama pengguna, nama layanan, sampai alamat surel.

Berapa versi terbaru UTS #39 dan kapan dirilis?

Versi 18.0.0, revisi 34, bertanggal 27 Agustus 2026, dengan Josh Hadley dan Roozbeh Pournader sebagai editor. Teks versi itu tersedia sebagai dokumen revisi 34, sementara halaman utamanya ada di unicode.org.

Apakah dokumen ini sudah final atau masih rancangan?

Sudah disetujui. Halaman resminya menyatakan dokumen ini telah ditinjau oleh anggota Unicode dan pihak berkepentingan lain, lalu disetujui untuk publikasi oleh Unicode Consortium, sehingga boleh dipakai sebagai rujukan normatif oleh spesifikasi lain.

Di mana saya bisa mencoba memeriksa karakter yang mirip?

Unicode menyediakan utilitas berbasis web untuk memeriksa confusable di util.unicode.org. Untuk sisi pengodean nama domain internasional, rujukan klasiknya adalah RFC 3492 tentang Punycode, yang mendefinisikan pengodean bootstring untuk nama domain non-ASCII.

Siapa yang mengelola aturan nama domain di tingkat global?

ICANN adalah organisasi tempat kebijakan nama domain dibahas dan diputuskan, dan situsnya di icann.org memuat catatan pertemuan serta pengumuman resminya. Untuk kebutuhan implementasi, tetap pakai UTS #39 sebagai acuan teknis dan ICANN sebagai acuan kebijakan.