Perintah dan konteks
Dua string terlihat identik tetapi menghasilkan perbandingan yang berbeda dalam pemeriksaan keunikan database, pencarian, atau perbandingan nama file. Jelaskan karakter penggabung (combining) dan pra-komposisi (precomposed), empat bentuk normalisasi, batasan input dan penyimpanan, serta mengapa normalisasi tidak menggantikan case folding, aturan bahasa, atau kebijakan keamanan.
Hal yang diuji oleh pewawancara
- Apakah Anda memahami canonical equivalence versus compatibility equivalence.
- Apakah Anda memilih NFC, NFD, NFKC, atau NFKD berdasarkan semantik bisnis.
- Apakah Anda memperhitungkan versi Unicode, collation database, indeks, dan konsistensi lintas layanan.
- Apakah Anda dapat mengidentifikasi risiko kehilangan informasi dari compatibility folding.
Pertanyaan klarifikasi sebelum menjawab
Pastikan apakah bidang tersebut merupakan teks tampilan, pengidentifikasi login, kunci pencarian, nama file, atau pengidentifikasi yang sensitif terhadap keamanan; tanyakan tentang bahasa, kapitalisasi (case), versi Unicode, collation, dan apakah input asli harus dipertahankan. Sistem dapat menyimpan input asli dan menyimpan kunci perbandingan yang telah dinormalisasi.
Kerangka jawaban 30 detik
Unicode memungkinkan satu teks yang terlihat memiliki beberapa urutan titik kode (code point). NFC melakukan canonical decomposition yang diikuti oleh komposisi; NFD melakukan canonical decomposition. NFKC dan NFKD juga memproses compatibility equivalence dan dapat melipat (fold) karakter dengan pemformatan atau ekspektasi semantik yang berbeda. NFC adalah pilihan umum untuk teks generik; compatibility folding memerlukan toleransi eksplisit terhadap hilangnya informasi. Tetapkan versi Unicode dan pisahkan normalisasi dari case folding, kebijakan skrip, dan pemeriksaan keamanan.
Pembahasan mendalam langkah demi langkah
1. Canonical equivalence dan komposisi
Karakter pra-komposisi dan karakter dasar yang digabungkan dengan tanda penggabung dapat terlihat sama dan setara secara kanonik. NFD menguraikannya (decompose) dan NFC menggabungkannya (compose) sesuai dengan standar. Bentuk normalisasi bersifat idempoten: menerapkannya kembali tidak akan terus mengubah string.
2. Konsekuensi dari compatibility equivalence
NFKD melakukan compatibility decomposition dan NFKC melakukan komposisi setelahnya. Beberapa varian font, bentuk full-width, atau karakter dekoratif dapat dipetakan ke representasi dasar. Gunakan ini untuk kebijakan pencarian atau perbandingan yang secara eksplisit luas, bukan secara otomatis untuk kata sandi, teks hukum, atau konten yang tampilannya harus dipertahankan.
3. Batasan penyimpanan dan keamanan
Simpan input asli dan hasilkan kunci perbandingan berversi. Tentukan pemeriksaan keunikan, tokenisasi, case folding, dan script-confusable secara terpisah. Untuk nama login, domain, atau pengidentifikasi izin, ikuti protokol dan profil keamanan yang relevan; NFKC saja bukanlah pertahanan yang lengkap.
Contoh jawaban berkualitas tinggi
Saya memisahkan nilai tampilan dan nilai perbandingan. Unicode memungkinkan karakter pra-komposisi dan urutan penggabung untuk mewakili teks kanonik yang sama, sehingga perbandingan titik kode dapat menghasilkan ketidakcocokan yang salah (false mismatch). NFD menguraikan dan NFC menyusun kembali; NFKD dan NFKC juga menerapkan pemetaan kompatibilitas, yang dapat membuang informasi pemformatan. Biasanya saya akan menggunakan NFC untuk teks umum dan mengunci versi Unicode yang didukung. Kunci pencarian dapat menggunakan NFKC hanya jika hilangnya informasi tersebut memang disengaja, bersamaan dengan case folding dan aturan bahasa. Simpan data asli, ditambah kunci ternormalisasi berversi untuk keunikan database. Untuk kata sandi, tanda tangan, teks audit, dan pengidentifikasi keamanan, saya tidak akan menambahkan compatibility folding di luar protokol; saya akan menerapkan pemeriksaan pengidentifikasi dan confusable yang ditentukan. Pengujian mencakup urutan penggabungan, normalisasi berulang, input multibahasa, peningkatan versi, dan perbedaan collation.
Kesalahan umum
- Mengatakan bahwa NFC dan NFKC setara.
- Menganggap normalisasi sebagai case folding, transliterasi, atau penghapusan aksen.
- Menerapkan NFKC ke setiap bidang dan kehilangan informasi karakter kompatibilitas.
- Hanya melakukan normalisasi di aplikasi sambil mengabaikan indeks database dan versi layanan.
- Menganggap kesamaan visual sebagai kesetaraan keamanan dan melewatkan script confusables.
Pertanyaan lanjutan dan tanggapan
Mengapa tidak hanya menyimpan string yang dinormalisasi?
Konteks tampilan, audit, atau hukum mungkin memerlukan input asli. Menyimpan keduanya menghindari konversi ireversibel yang memengaruhi pengguna sekaligus mendukung pemeriksaan keunikan yang stabil.
Bisakah pembaruan versi Unicode merusak keunikan?
Hal ini dapat memengaruhi titik kode yang belum ditetapkan atau data normalisasi. Catat versi normalisasi, hitung ulang kunci secara offline, periksa tabrakan (collisions), dan migrasikan indeks secara bertahap.
Apakah normalisasi menghentikan serangan homoglif?
Tidak sepenuhnya. Normalisasi mencakup relasi kesetaraan yang telah ditentukan; keamanan juga membutuhkan pembatasan skrip, deteksi confusable, profil pengidentifikasi protokol, dan peninjauan.