Menggunakan Normalisasi Unicode untuk Mewakili String
Aplikasi dapat menggunakan Unicode untuk mewakili string dalam beberapa formulir. Ketika penerimaan Unicode telah berkembang, terutama melalui Internet, kebutuhan telah muncul untuk menghilangkan perbedaan yang tidak penting dalam string Unicode. Beberapa representasi untuk kombinasi karakter yang mempersulit perangkat lunak, misalnya, ketika server Web merespons permintaan halaman atau linker mencari pengidentifikasi tertentu di pustaka.
Perhatian
String Unicode yang berbeda dapat tampak identik secara visual, meningkatkan masalah keamanan. Untuk informasi selengkapnya, lihat Pertimbangan Keamanan: Fitur Internasional.
Menanggapi persyaratan ini, Unicode Consortium telah mendefinisikan proses yang disebut "normalisasi," yang menghasilkan satu representasi biner untuk salah satu representasi biner yang setara dari karakter. Setelah dinormalisasi, dua string setara jika dan hanya jika mereka memiliki representasi biner yang identik. Normalisasi menghilangkan beberapa perbedaan tetapi mempertahankan kasus.
Untuk menggunakan normalisasi Unicode, aplikasi dapat memanggil fungsi NormalizeString dan IsNormalizedString untuk mengatur ulang string yang diakumulasikan ke Unicode 4.0 TR#15. Normalisasi dapat membantu meningkatkan keamanan dengan mengurangi representasi string alternatif yang memiliki arti linguistik yang sama. Ingat, bagaimanapun, normalisasi itu tidak dapat menghilangkan representasi alternatif sepenuhnya.
Untuk deskripsi terperinci tentang standar Unicode untuk normalisasi, lihat Unicode Standard Annex #15: Unicode Normalization Forms (UAX #15).
Perhatian
Karena normalisasi dapat mengubah bentuk string, mekanisme keamanan, atau algoritma validasi karakter biasanya harus diimplementasikan setelah normalisasi. Untuk informasi selengkapnya, lihat Pertimbangan Keamanan: Fitur Internasional.
Berikan Beberapa Representasi dari String yang Sama
Dalam banyak kasus, Unicode memungkinkan beberapa representasi dari apa itu, linguistik, string yang sama. Contohnya:
- Modal A dengan dieresis (umlaut) dapat diwakili baik sebagai titik kode Unicode tunggal "Ä" (U+00C4) atau kombinasi Modal A dan karakter Dieresis yang menggabungkan ("A" + " ̈", yaitu U+0041 U+0308). Pertimbangan serupa berlaku untuk banyak karakter lain dengan tanda diakritik.
- Kapital A sendiri dapat diwakili baik dengan cara yang biasa (Huruf Latin Kapital A, U+0041) atau dengan Fullwidth Latin Capital Letter A (U+FF21). Pertimbangan serupa berlaku untuk huruf Latin sederhana lainnya (huruf besar dan huruf kecil) dan untuk karakter katakana yang digunakan dalam menulis bahasa Jepang.
- String "fi" dapat diwakili baik oleh karakter "f" dan "i" (U+0066 U+0069) atau oleh ligatur "fi" (U+FB01). Pertimbangan serupa berlaku untuk banyak kombinasi karakter lain di mana Unicode mendefinisikan ligatur.
Menggunakan Empat Formulir Normalisasi yang Ditentukan
Aplikasi Anda dapat melakukan normalisasi Unicode menggunakan beberapa algoritma, yang disebut "formulir normalisasi", yang mematuhi aturan yang berbeda. Unicode Consortium telah mendefinisikan empat bentuk normalisasi: NFC (formulir C), NFD (formulir D), NFKC (formulir KC), dan NFKD (formulir KD). Setiap formulir menghilangkan beberapa perbedaan tetapi mempertahankan kasus. Win32 dan .NET Framework mendukung keempat bentuk normalisasi.
Jenis enumerasi NLS NORM_FORM mendukung empat bentuk normalisasi Unicode standar. Formulir C dan D menyediakan formulir kanonis untuk string. KC dan KD bentuk non-kanonis memberikan kompatibilitas lebih lanjut, dan dapat mengungkapkan kesetaraan semantik tertentu yang tidak jelas dalam formulir C dan D. Namun, mereka melakukannya dengan mengorbankan kehilangan informasi tertentu, dan umumnya tidak boleh digunakan sebagai cara kanonis untuk menyimpan string.
Dari dua bentuk kanonis, formulir C adalah formulir "disusun" dan formulir D adalah bentuk "terurai". Misalnya, formulir C menggunakan titik kode Unicode tunggal "Ä" (U+00C4), sedangkan formulir D menggunakan ("A" + " ̈", yaitu U+0041 U+0308). Render ini identik, karena " ̈" (U+0308) adalah karakter yang menggabungkan. Formulir D dapat menggunakan sejumlah titik kode untuk mewakili satu titik kode yang digunakan oleh formulir C.
Jika dua string identik dalam bentuk C atau formulir D, string tersebut identik dalam bentuk lain. Selain itu, ketika dirender dengan benar, mereka menampilkan indistinguishably satu sama lain dan dari string asli yang tidak dinormalisasi.
Setelah dinormalisasi, string tidak dapat dikembalikan secara konsisten ke representasi aslinya. Misalnya, jika string dengan campuran representasi karakter yang dikomposisi dan diurai dikonversi ke bentuk yang dinormalisasi, tidak ada cara untuk membatalkan normalisasinya ke string campuran asli. Oleh karena itu, jika aplikasi memerlukan representasi asli string, aplikasi harus menyimpan representasi tersebut secara eksplisit. Namun, mengonversi antara dua bentuk kanonis dapat dibalik. String dalam formulir C dapat dikonversi ke formulir D lalu kembali ke formulir C, dan hasilnya identik dengan string C formulir asli.
Formulir KC dan KD masing-masing mirip dengan formulir C dan D, tetapi "formulir kompatibilitas" ini memiliki pemetaan tambahan karakter yang kompatibel ke bentuk dasar setiap karakter. Pemetaan tersebut dapat menyebabkan variasi karakter kecil hilang. Mereka menggabungkan karakter tertentu yang secara visual berbeda. Misalnya, mereka menggabungkan karakter lebar penuh dan lebar setengah dengan arti semantik yang sama, atau bentuk yang berbeda dari huruf Arab yang sama, atau ligatur "fi" (U+FB01) dan pasangan karakter "fi" (U+0066 U+0069). Mereka juga menggabungkan beberapa karakter yang terkadang memiliki arti semantik yang berbeda, seperti digit yang ditulis sebagai superskrip, sebagai subskrip, atau diapit dalam lingkaran. Karena kehilangan informasi ini, bentuk KC dan KD umumnya tidak boleh digunakan sebagai bentuk string kanonis, tetapi berguna untuk aplikasi tertentu.
Form KC adalah bentuk yang disusam dan bentuk KD adalah bentuk yang diurai. Aplikasi dapat bolak-balik antara bentuk KC dan KD, tetapi tidak ada cara yang konsisten untuk beralih dari formulir KC atau KD kembali ke string asli, bahkan jika string asli dalam bentuk C atau D.
Aplikasi Windows, Microsoft, dan .NET Framework umumnya menghasilkan karakter dalam formulir C menggunakan metode input normal. Untuk sebagian besar tujuan pada Windows, formulir C adalah bentuk yang disukai. Misalnya, karakter dalam formulir C diproduksi oleh input keyboard Windows. Namun, karakter yang diimpor dari Web dan platform lain dapat memperkenalkan formulir normalisasi lainnya ke dalam aliran data.
Contoh berikut diambil dari UAX #15, dan menggambarkan perbedaan di antara empat bentuk normalisasi.
| Asli | Formulir D | Formulir C | Catatan |
|---|---|---|---|
| "Äffin" | "A\u0308ffin" | "Äffin" | ffi_ligature (U+FB03) tidak diurai, karena memiliki pemetaan kompatibilitas, bukan pemetaan kanonis.${REMOVE}$ |
| "Ä\uFB03n" | "A\u0308\uFB03n" | "Ä\uFB03n" | |
| "Henry IV" | "Henry IV" | "Henry IV" | ROMAN NUMERAL IV (U+2163) tidak terurai.${REMOVE}$ |
| "Henry \u2163" | "Henry \u2163" | "Henry \u2163" | |
| ga | ka +ten | ga | Kompatibilitas yang berbeda yang setara dengan satu karakter Jepang tidak menghasilkan string yang sama dalam bentuk C.${REMOVE}$ |
| ka +ten | ka +ten | ga | |
| hw_ka +hw_ten | hw_ka +hw_ten | hw_ka +hw_ten | |
| ka +hw_ten | ka +hw_ten | ka +hw_ten | |
| hw_ka +sepuluh | hw_ka +sepuluh | hw_ka +sepuluh | |
| kaks | k i + a m + ks f | kaks | Suku kata Hangul dipertahankan di bawah normalisasi. |
| Asli | Formulir KD | Formulir KC | Catatan |
|---|---|---|---|
| "Äffin" | "A\u0308ffin" | "Äffin" | ffi_ligature (U+FB03) diurai dalam formulir KC, tetapi tidak dalam bentuk C.${REMOVE}$ |
| "Ä\uFB03n" | "A\u0308ffin" | "Äffin" | |
| "Henry IV" | "Henry IV" | "Henry IV" | String yang dihasilkan di sini identik dalam bentuk KC.${REMOVE}$ |
| "Henry \u2163" | "Henry IV" | "Henry IV" | |
| ga | ka +ten | ga | Kompatibilitas yang berbeda setara dengan satu karakter Jepang menghasilkan string yang sama dalam bentuk KC.${REMOVE}$ |
| ka +ten | ka +ten | ga | |
| hw_ka +hw_ten | ka +ten | ga | |
| ka +hw_ten | ka +ten | ga | |
| hw_ka +sepuluh | ka +ten | ga | |
| kaks | k i + a m + ks f | kaks | Suku kata Hangul dipertahankan di bawah normalisasi. Dalam versi Unicode sebelumnya, karakter jamo seperti ks f memiliki pemetaan kompatibilitas ke k f + s f. Pemetaan ini dihapus di Unicode 2.1.9 untuk memastikan bahwa suku kata Hangul dipertahankan. |
Catatan
Dua tabel di atas memiliki hak cipta Unicode © 1998-2006, Inc. Hak Cipta Dilindungi Undang-Undang.
Gunakan Formulir yang Disusun untuk Glyph Tunggal
Banyak urutan karakter yang sesuai dengan satu glyph tidak memiliki bentuk yang disusun. Bahkan ketika dinormalisasi berdasarkan formulir C, satu glyph visual atau elemen teks logis dapat terdiri dari beberapa titik kode Unicode. Misalnya, beberapa karakter yang digunakan dalam penulisan Lithuania memiliki diakritik ganda, karena hanya memiliki bentuk yang terurai. Contohnya adalah U huruf kecil dengan macron dan tilde ("ū̃", U+016b U+0303, di mana titik kode pertama adalah U huruf kecil dengan macron dan yang kedua adalah menggabungkan aksen akut).
Contoh
Contoh yang relevan dapat ditemukan di NLS: Sampel Normalisasi Unicode.
Topik terkait
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk