Memahami dan Menghindari Karakter yang Ambigu Secara Visual dalam ID

Memahami karakter yang ambigu secara visual dalam ID

• Karakter yang ambigu secara visual adalah karakter yang sulit dibedakan dalam font tertentu atau tulisan tangan
  • O/0, I/l/1/7, 5/S, 2/Z, 8/B, 6/G, 9/q/g termasuk dalam kategori ini
• Karakter-karakter ini dapat menyebabkan kesalahan dan kebingungan saat input data
  • Pengguna sulit membedakan O dan 0, sehingga memasukkan kode yang salah dan menimbulkan pengalaman pengguna yang buruk
• Hal ini особенно penting dalam situasi ketika ID disampaikan secara lisan atau harus ditulis tangan
  • Dukungan pelanggan, kode diskon, kode pelacakan, ID error, ID produk, dan sebagainya

Menentukan apakah akan membedakan huruf besar dan kecil

• Perlu diputuskan apakah ID akan membedakan huruf besar dan kecil
  • Jika membedakan huruf besar dan kecil, jumlah karakter yang bisa dipilih setelah mengecualikan ambiguitas visual adalah 53
  • Jika tidak membedakan huruf besar dan kecil, jumlah karakter yang bisa dipilih adalah 22
• Jika panjang ID adalah 5 karakter, jumlah ID yang mungkin:
  • Membedakan huruf besar dan kecil: 53^5 = 418,195,493
  • Tidak membedakan huruf besar dan kecil: 22^5 = 5,153,632
• Namun, semakin panjang ID, jumlah ID yang mungkin bertambah secara eksponensial
• Karena itu, perlu dicari titik kompromi antara panjang ID dan kemungkinan ambiguitas visual
• Selain itu, jika menggunakan huruf besar dan kecil sekaligus, masalah tak terduga dapat muncul pada sistem pihak ketiga yang tidak membedakan huruf besar dan kecil

Set karakter yang jelas secara visual

• Jika keterbacaan menjadi prioritas utama, disarankan menggunakan set karakter berikut:
  • [ "a", "b", "c", "d", "e", "f", "h", "i", "j", "k", "m", "n", "o", "p", "r", "s", "t", "w", "x", "y", "3", "4"]

Pertimbangan tambahan

• Kombinasi karakter tertentu bisa terlihat seperti karakter lain (misalnya rn terlihat seperti m, 3 terlihat seperti w)
  • Sebaiknya hindari kombinasi seperti ini pada tahap pembuatan ID
• Karakter dengan pengucapan yang mirip juga sebaiknya dihindari (misalnya b dan p)
  • Ini особенно penting ketika ID disampaikan secara lisan

Contoh kasus yang sudah ada

• Crockford's Base32: mendekode karakter ambigu sebagai nilai yang sama, dan juga mempertimbangkan kemungkinan kata kasar yang tidak sengaja terbentuk
• Open Location Code: menggunakan set karakter 23456789CFGHJMPQRVWX. Bertujuan menghindari ambiguitas visual sekaligus mencegah terbentuknya kata-kata umum dalam bahasa. Namun 6/G, 9/Q tetap disertakan.

Opini GN⁺

• Dalam pembuatan ID, kegunaan dan keterbacaan harus menjadi prioritas utama. Ini menjadi semakin penting jika ID sering disampaikan secara lisan atau harus dicatat dengan tangan.
• Pilih set karakter yang dapat meminimalkan ambiguitas visual, sambil mencari kompromi yang tepat antara panjang ID dan jumlah kombinasi yang tersedia.
• Selain itu, karena masalah tak terduga dapat muncul saat integrasi dengan sistem pihak ketiga, keputusan tentang pembedaan huruf besar dan kecil perlu dibuat dengan hati-hati.
• Logika pembuatan ID juga perlu mempertimbangkan hal-hal tambahan seperti mengecualikan kombinasi karakter tertentu atau menghindari karakter yang pelafalannya mirip.
• Sebaiknya rujuk contoh seperti Crockford's Base32 atau Open Location Code untuk merancang set karakter yang paling sesuai dengan kebutuhan proyek.

[roxie]

Ini juga terlihat bagus: https://stackoverflow.com/a/58098360/8556340

[roxie]

Bahkan pengucapannya pun ikut dipertimbangkan, benar-benar menakjubkan.

[GN⁺]

Komentar Hacker News

• Ada kasus di lapangan nyata di mana nomor seri yang mengandung karakter ambigu digunakan pada jutaan perangkat, sehingga menimbulkan kesulitan besar bagi dukungan pelanggan. Pernah mengalami mimpi buruk harus membuat variasi salah ketik dengan regex lalu mencocokkannya ke DB untuk memperkirakan nomor seri yang sebenarnya.
• Metode encoding perlu dibedakan menurut penggunanya. Base32 cocok karena memiliki himpunan karakter yang jelas, dan saat disampaikan secara lisan lebih baik memakai representasi daftar kata (misalnya "TIDE ITCH SLOW REIN RULE MOT"). Namun, ada jebakan seperti idiom, homofon, dan dialek, jadi jangan membuat daftar kata sendiri.
• Pernah menerima permintaan dukungan yang tak terduga gara-gara modul operasi basis bilangan arbitrer yang diunggah ke CPAN sebagai lelucon (Math::Fleximal). Penyebabnya, seseorang memakai kode demo untuk mengubah heksadesimal menjadi kode alfanumerik di produksi.
• Pada layar input nomor seri DLC Nintendo Switch, tombol untuk karakter yang ambigu dinonaktifkan sehingga UX menjadi lebih baik.
• Karakter yang sulit dibedakan saat ditulis tangan juga sebaiknya dihindari. Terutama '7' dan '1' yang mudah tertukar.
• Jika memakai huruf besar dan kecil sekaligus, Anda bisa terkena masalah belakangan karena sistem atau protokol yang tidak membedakan huruf besar-kecil. Ada juga sistem komersial yang tidak menganggap ini bug demi kenyamanan pengguna.
• Setiap kali menuliskan kode cadangan 2FA di atas kertas, rasa cemas muncul pada karakter tertentu (o/0, v/u, 5/S, dll.). Untuk menghindarinya, kadang karakter diberi hiasan tambahan.
• Memilih kata sehari-hari untuk kata sandi Wi-Fi yang bahkan anak kelas 3 pun bisa mengejanya dengan benar ("vacation").
• KeepassXC sangat meningkatkan keterbacaan dengan memberi warna berbeda untuk tiap jenis karakter (huruf besar, huruf kecil, angka, simbol, dll.).
• Alamat Bitcoin menggunakan encoding Base58 yang dimodifikasi.
• Artikel tersebut salah menulis font Arial menjadi Ariel.