Internet Engineering Task Force ( IETF ) telah menerbitkan RFC 9839 , sebuah standar baru yang menangani karakter Unicode bermasalah yang dapat merusak sistem perangkat lunak dan protokol jaringan. Meskipun Unicode diterima secara luas sebagai standar pengkodean teks utama, tidak semua karakternya cocok untuk setiap aplikasi.
RFC tersebut, yang ditulis oleh Tim Bray dan Paul Hoffman , mengidentifikasi karakter Unicode spesifik yang menyebabkan masalah dalam sistem dunia nyata dan menawarkan tiga subset yang disederhanakan yang dapat digunakan pengembang sebagai pengganti kerangka kerja PRECIS yang lebih kompleks dari tahun 2017.
Masalah dengan Karakter Unicode Buruk
Masalah inti terletak pada karakter Unicode tertentu yang, meskipun secara teknis valid, menciptakan masalah serius ketika digunakan dalam bidang teks. Ini termasuk byte null yang mengganggu bahasa pemrograman, surrogate yang tidak berpasangan dari pengkodean UTF-16 yang seharusnya tidak ada dalam UTF-8, dan noncharacter yang secara eksplisit dilarang oleh Unicode untuk pertukaran data.
Contoh yang sangat bermasalah melibatkan kode kontrol lama seperti CHARACTER TABULATION WITH JUSTIFICATION - sebuah perintah pemformatan yang tidak jelas yang diwarisi dari standar tahun 1990-an yang tidak memiliki kegunaan praktis dalam aplikasi modern tetapi dapat menyebabkan perilaku yang tidak dapat diprediksi di berbagai sistem.
Diskusi komunitas mengungkapkan perdebatan yang sedang berlangsung tentang di mana pembatasan ini harus diberlakukan. Beberapa pengembang berpendapat bahwa protokol tingkat rendah seperti JSON harus tetap permisif, meninggalkan penyaringan karakter ke lapisan validasi khusus aplikasi. Yang lain berpendapat bahwa gagal dengan aman di tingkat protokol mencegah masalah hilir.
Jenis Karakter Unicode Bermasalah:
- Surrogates: Artefak encoding UTF-16 yang tidak berpasangan (contoh: U+DEAD)
- Legacy Controls: Perintah pemformatan usang dari standar tahun 1990-an (contoh: U+0089)
- Noncharacters: Titik kode yang secara eksplisit dilarang untuk pertukaran data (contoh: U+7FFFF)
- Null Bytes: Karakter U+0000 yang mengganggu bahasa pemrograman
Tantangan Implementasi dan Kekhawatiran Keamanan
Implikasi keamanan meluas melampaui kesalahan parsing sederhana. Karakter pengganti arah dapat membuat nama pengguna tampak dibaca dari kanan ke kiri, berpotensi membuat antarmuka admin tidak dapat dibaca. Lebih serius lagi, karakter-karakter ini memungkinkan serangan sumber Trojan di mana kode yang ditampilkan tidak cocok dengan byte sebenarnya yang sedang dieksekusi.
Format data yang berbeda menangani karakter bermasalah secara tidak konsisten. JSON memungkinkan semua jenis bermasalah, sementara XML dan YAML memberikan perlindungan parsial. Inkonsistensi ini menciptakan sakit kepala interoperabilitas ketika sistem bertukar data antara format.
Saya lebih suka melarang emoji terbaru apa pun yang beredar dari nama pengguna daripada berpotensi membiarkannya mengacaukan setiap halaman yang menampilkan nama pengguna.
RFC menawarkan tiga subset yang semakin restriktif: Scalars (hanya mengecualikan surrogate), XML (cocok dengan pembatasan XML ), dan Assignables (mengecualikan semua jenis bermasalah). Pendekatan bertingkat ini memungkinkan pengembang memilih pembatasan yang sesuai berdasarkan kebutuhan spesifik mereka.
Subset yang Diusulkan RFC 9839:
| Nama Subset | Mengecualikan Surrogate | Mengecualikan Kontrol Legacy | Mengecualikan Noncharacter |
|---|---|---|---|
| Scalars | Ya | Tidak | Tidak |
| XML | Ya | Sebagian | Sebagian |
| Assignables | Ya | Ya | Ya |
Penerimaan Komunitas dan Adopsi Praktis
Reaksi pengembang beragam tetapi umumnya positif. Banyak yang menghargai memiliki referensi standar untuk pembatasan karakter daripada setiap proyek membuat aturannya sendiri. Namun, beberapa khawatir tentang pembatasan yang terlalu luas yang mungkin memblokir kasus penggunaan yang sah, seperti karakter kontrol dalam aplikasi terminal atau konten file yang benar-benar membutuhkan urutan Unicode yang tidak biasa.
Waktunya tampaknya tepat untuk adopsi. Tidak seperti kerangka kerja PRECIS yang komprehensif tetapi kompleks, RFC 9839 menawarkan pendekatan yang lebih sederhana yang tidak mengikat implementasi ke versi Unicode tertentu. Fleksibilitas ini menarik bagi pengembang yang ingin mendukung emoji dan karakter terbaru tanpa koordinasi versi yang ekstensif antara sistem.
RFC mewakili kompromi pragmatis antara universalitas ambisius Unicode dan kebutuhan praktis sistem perangkat lunak yang kuat. Seiring lebih banyak pengembang mengimplementasikan pedoman ini, kita seharusnya melihat lebih sedikit bug penanganan teks yang misterius dan perilaku yang lebih dapat diprediksi di berbagai platform dan aplikasi.
Referensi: RFC 9839 and Bad Unicode