Internet Engineering Task Force ( IETF ) telah menerbitkan RFC 9839 , satu piawaian baharu yang menangani aksara Unicode bermasalah yang boleh merosakkan sistem perisian dan protokol rangkaian. Walaupun Unicode diterima secara meluas sebagai piawaian pengekodan teks utama, tidak semua aksaranya sesuai untuk setiap aplikasi.
RFC tersebut, yang dikarang oleh Tim Bray dan Paul Hoffman , mengenal pasti aksara Unicode tertentu yang menyebabkan masalah dalam sistem dunia sebenar dan menawarkan tiga subset ringkas yang boleh digunakan oleh pembangun sebagai ganti rangka kerja PRECIS yang lebih kompleks dari tahun 2017.
Masalah dengan Aksara Unicode Bermasalah
Isu teras terletak pada aksara Unicode tertentu yang, walaupun secara teknikal sah, mencipta masalah serius apabila digunakan dalam medan teks. Ini termasuk bait null yang mengganggu bahasa pengaturcaraan, surrogate tidak berpasangan dari pengekodan UTF-16 yang tidak sepatutnya wujud dalam UTF-8, dan bukan aksara yang secara jelas dilarang oleh Unicode untuk pertukaran data.
Contoh yang amat bermasalah melibatkan kod kawalan warisan seperti CHARACTER TABULATION WITH JUSTIFICATION - arahan pemformatan yang tidak jelas diwarisi dari piawaian 1990-an yang tidak mempunyai kegunaan praktikal dalam aplikasi moden tetapi boleh menyebabkan tingkah laku yang tidak dapat diramal merentasi sistem yang berbeza.
Perbincangan komuniti mendedahkan perdebatan berterusan tentang di mana sekatan ini patut dikuatkuasakan. Sesetengah pembangun berhujah bahawa protokol peringkat rendah seperti JSON patut kekal permisif, meninggalkan penapisan aksara kepada lapisan pengesahan khusus aplikasi. Yang lain berpendapat bahawa kegagalan yang selamat di peringkat protokol menghalang isu hiliran.
Jenis Aksara Unicode Bermasalah:
- Surrogates: Artifak pengekodan UTF-16 yang tidak berpasangan (contohnya, U+DEAD)
- Legacy Controls: Arahan pemformatan usang daripada piawaian 1990-an (contohnya, U+0089)
- Noncharacters: Titik kod yang secara eksplisit dilarang untuk pertukaran data (contohnya, U+7FFFF)
- Null Bytes: Aksara U+0000 yang mengganggu bahasa pengaturcaraan
Cabaran Pelaksanaan dan Kebimbangan Keselamatan
Implikasi keselamatan melangkaui ralat penghuraian yang mudah. Aksara override arah boleh menjadikan nama pengguna kelihatan dibaca dari kanan ke kiri, berpotensi menjadikan antara muka pentadbir tidak dapat dibaca. Lebih serius lagi, aksara ini membolehkan serangan sumber Trojan di mana kod yang dipaparkan tidak sepadan dengan bait sebenar yang sedang dilaksanakan.
Format data yang berbeza mengendalikan aksara bermasalah secara tidak konsisten. JSON membenarkan semua jenis bermasalah, manakala XML dan YAML menyediakan perlindungan separa. Ketidakkonsistenan ini mencipta masalah kebolehoperasian apabila sistem bertukar data antara format.
Saya lebih suka tidak membenarkan apa sahaja emoji terkini yang muncul dari nama pengguna daripada berpotensi membenarkannya merosakkan setiap halaman yang memaparkan nama pengguna.
RFC tersebut menawarkan tiga subset yang semakin ketat: Scalars (mengecualikan hanya surrogate), XML (sepadan dengan sekatan XML ), dan Assignables (mengecualikan semua jenis bermasalah). Pendekatan berperingkat ini membolehkan pembangun memilih sekatan yang sesuai berdasarkan keperluan khusus mereka.
Subset Cadangan RFC 9839:
Nama Subset | Mengecualikan Surrogates | Mengecualikan Legacy Controls | Mengecualikan Noncharacters |
---|---|---|---|
Scalars | Ya | Tidak | Tidak |
XML | Ya | Separa | Separa |
Assignables | Ya | Ya | Ya |
Sambutan Komuniti dan Penggunaan Praktikal
Reaksi pembangun bercampur-campur tetapi secara amnya positif. Ramai menghargai mempunyai rujukan piawai untuk sekatan aksara daripada setiap projek mencipta peraturan sendiri. Walau bagaimanapun, sesetengah bimbang tentang sekatan yang terlalu luas yang mungkin menyekat kes penggunaan yang sah, seperti aksara kawalan dalam aplikasi terminal atau kandungan fail yang benar-benar memerlukan urutan Unicode yang luar biasa.
Masanya kelihatan tepat untuk penggunaan. Tidak seperti rangka kerja PRECIS yang komprehensif tetapi kompleks, RFC 9839 menawarkan pendekatan yang lebih mudah yang tidak mengikat pelaksanaan kepada versi Unicode tertentu. Fleksibiliti ini menarik minat pembangun yang ingin menyokong emoji dan aksara terkini tanpa penyelarasan versi yang meluas antara sistem.
RFC tersebut mewakili kompromi pragmatik antara kesejagatan bercita-cita tinggi Unicode dan keperluan praktikal sistem perisian yang teguh. Apabila lebih ramai pembangun melaksanakan garis panduan ini, kita sepatutnya melihat lebih sedikit pepijat pengendalian teks yang misteri dan tingkah laku yang lebih dapat diramal merentasi platform dan aplikasi yang berbeza.
Rujukan: RFC 9839 and Bad Unicode