Sebuah proposal baru untuk Corrected UTF-8 bertujuan memperbaiki apa yang dilihat penciptanya sebagai cacat desain fundamental dalam standar encoding teks UTF-8 yang banyak digunakan. Namun, komunitas teknologi telah merespons dengan skeptisisme yang signifikan, menimbulkan kekhawatiran serius tentang kompatibilitas dan implementasi praktis.
Proposal tersebut berusaha mengatasi tiga masalah utama dengan UTF-8 saat ini: menghilangkan encoding overlength yang pernah menyebabkan kerentanan keamanan, menghapus dukungan untuk karakter kontrol tertentu dan kode surrogate, serta memperluas ruang karakter melampaui batas saat ini. Meskipun tujuan-tujuan ini mungkin terdengar masuk akal di atas kertas, reaksi komunitas menunjukkan bahwa obatnya mungkin lebih buruk daripada penyakitnya.
Perbedaan Utama dari UTF-8 Standar
- Perbaikan Encoding Overlength: Menambahkan offset pada sekuens multi-byte alih-alih menolak yang tidak valid
- Pengecualian Karakter: Tidak dapat meng-encode kontrol C1 (U+0080-U+009F) atau surrogate Unicode (U+D800-U+DFFF)
- Rentang yang Diperluas: Mendukung encoding hingga U+8421 109F (vs U+10 FFFF pada UTF-8 standar)
- Magic Number: Menggunakan sekuens 8-byte EF B7 9D ED B2 AE 00 0A untuk mengidentifikasi teks UTF-8 yang telah diperbaiki
- Pembatasan Line Ending: Melarang line ending \r\n ( Windows ) dan hanya mengharuskan gaya Unix \n
Merusak Kompatibilitas Menciptakan Lebih Banyak Masalah Daripada Solusi
Kritik paling signifikan berpusat pada pendekatan proposal untuk memperbaiki encoding overlength. Alih-alih hanya menolak urutan yang tidak valid seperti yang dilakukan UTF-8 saat ini, sistem baru menambahkan offset ke urutan multi-byte. Ini berarti teks UTF-8 yang ada akan didekode menjadi karakter yang benar-benar berbeda di bawah sistem baru, sementara teks terkoreksi baru masih dapat didekode oleh sistem UTF-8 lama - hanya saja secara tidak benar.
Anggota komunitas menunjukkan bahwa ini menciptakan situasi berbahaya di mana teks tampak berfungsi tetapi menghasilkan hasil yang salah. Kompleksitas menangani offset ini, terutama di sekitar celah dalam ruang karakter, akan membuat encoder dan decoder jauh lebih rumit daripada saat ini.
Rentang Urutan Byte UTF-8 yang Diperbaiki
| Rentang Urutan Byte | Offset | Rentang Codepoint |
|---|---|---|
| 00...7F | 0 | 0000 0000...0000 007F |
| C0 80...DF BF | 160 | 0000 00A0...0000 089F |
| E0 80 80...EC BD 9F | 2,208 | 0000 08A0...0000 D7FF |
| EC BD A0...EF BF BF | 4,256 | 0000 E000...0001 109F |
| F0 80 80 80...F7 BF BF BF | 69,792 | 0001 10A0...0021 109F |
| F8 80 80 80 80...FB BF BF BF BF | 2,166,944 | 0021 10A0...0421 109F |
| FC 80 80 80 80 80...FD BF BF BF BF BF | 69,275,808 | 0421 10A0...8421 109F |
Menghapus Karakter Valid Memicu Perdebatan
Aspek kontroversial lainnya melibatkan sengaja membuat karakter Unicode tertentu tidak mungkin dienkode. Proposal tersebut melewatkan karakter kontrol C1 dan surrogate Unicode sepenuhnya, dengan alasan bahwa mereka tidak seharusnya muncul dalam teks normal. Namun, keputusan ini telah menarik kritik tajam dari pengembang yang perlu menangani data lama atau bekerja dengan sistem yang ada.
Tampaknya seperti proposal yang sangat berani untuk sengaja memiliki codepoint yang tidak dapat dienkode.
Pembatasan meluas ke karakter umum seperti tab horizontal dan carriage return, dengan proposal bahkan melarang line ending gaya Windows. Kritikus berpendapat bahwa ini menciptakan hambatan yang tidak perlu untuk adopsi dan memaksa pengembang untuk menolak teks yang sangat valid yang mungkin perlu diproses pengguna.
Magic Number dan Kekhawatiran Praktis
Proposal tersebut mencakup magic number - urutan byte khusus yang mengidentifikasi teks Corrected UTF-8, mirip dengan byte order mark dalam UTF-16. Namun, umpan balik komunitas menunjukkan bahwa pendekatan ini telah terbukti bermasalah dalam praktik. Penanda ini cenderung menyelinap ke tengah string teks dan menyebabkan masalah tak terduga dalam aplikasi dunia nyata.
Komunitas juga mempertanyakan apakah memperluas ruang karakter benar-benar diperlukan. Pertumbuhan Unicode saat ini terutama berasal dari penambahan lebih banyak karakter Cina, Jepang, dan Korea, tetapi ekspansi ini tidak akan berlanjut tanpa batas. Pada tingkat alokasi saat ini, ruang yang ada seharusnya bertahan sekitar 600 tahun.
Solusi Alternatif Sudah Ada
Beberapa anggota komunitas menunjuk pada solusi yang ada yang mengatasi masalah serupa tanpa merusak kompatibilitas. Standar UCSX, yang dikembangkan oleh kontributor Unicode sebenarnya, menyediakan ekspansi ruang karakter ketika diperlukan. Sementara itu, standar IETF yang akan datang akan memberikan panduan tentang karakter Unicode mana yang harus dihindari dalam praktik, mengatasi beberapa kekhawatiran yang sama tanpa memerlukan encoding baru.
Tantangan fundamental yang dihadapi pengganti UTF-8 mana pun adalah basis terinstal yang besar dari sistem dan data yang ada. Kesuksesan UTF-8 datang dari kompatibilitas penuh dengan ASCII sambil menangani semua karakter Unicode. Setiap pengganti yang merusak kompatibilitas ini menghadapi perjuangan menanjak untuk adopsi, terlepas dari manfaat teknisnya.
Konsensus komunitas tampak jelas: meskipun UTF-8 mungkin memiliki beberapa keanehan historis, manfaat praktis dari encoding baru tidak lebih besar daripada biaya fragmentasi ekosistem. Untuk saat ini, tampaknya dunia teknologi akan terus hidup dengan UTF-8 yang tidak terkoreksi.
Referensi: Corrected UTF-8