Satu cadangan baharu untuk Corrected UTF-8 bertujuan untuk membetulkan apa yang dilihat oleh penciptanya sebagai kecacatan reka bentuk asas dalam standard pengekodan teks UTF-8 yang digunakan secara meluas. Walau bagaimanapun, komuniti teknologi telah bertindak balas dengan skeptisisme yang ketara, menimbulkan kebimbangan serius mengenai keserasian dan pelaksanaan praktikal.
Cadangan tersebut cuba menangani tiga isu utama dengan UTF-8 semasa: menghapuskan pengekodan overlength yang pernah menyebabkan kelemahan keselamatan, mengeluarkan sokongan untuk aksara kawalan tertentu dan kod surrogate, dan mengembangkan ruang aksara melebihi had semasa. Walaupun matlamat ini mungkin kedengaran munasabah di atas kertas, reaksi komuniti menunjukkan ubat mungkin lebih teruk daripada penyakitnya.
Perbezaan Utama daripada UTF-8 Standard
- Pembetulan Pengekodan Overlength: Menambah offset kepada jujukan multi-bait dan bukannya menolak yang tidak sah
- Pengecualian Aksara: Tidak dapat mengekod kawalan C1 (U+0080-U+009F) atau surrogate Unicode (U+D800-U+DFFF)
- Julat Diperluas: Menyokong pengekodan sehingga U+8421 109F (berbanding U+10 FFFF dalam UTF-8 standard)
- Nombor Ajaib: Menggunakan jujukan 8-bait EF B7 9D ED B2 AE 00 0A untuk mengenal pasti teks UTF-8 yang diperbetulkan
- Sekatan Pengakhiran Baris: Melarang pengakhiran baris \r\n ( Windows ) dan memerlukan gaya Unix \n sahaja
Memecahkan Keserasian Mencipta Lebih Banyak Masalah Daripada Menyelesaikannya
Kritikan paling ketara tertumpu pada pendekatan cadangan untuk membetulkan pengekodan overlength. Daripada hanya menolak urutan yang tidak sah seperti yang dilakukan oleh UTF-8 semasa, sistem baharu menambah offset kepada urutan multi-byte. Ini bermakna teks UTF-8 sedia ada akan dinyahkod kepada aksara yang sama sekali berbeza di bawah sistem baharu, manakala teks yang diperbetulkan baharu masih boleh dinyahkod oleh sistem UTF-8 lama - cuma secara tidak betul.
Ahli komuniti menunjukkan ini mencipta situasi berbahaya di mana teks kelihatan berfungsi tetapi menghasilkan keputusan yang salah. Kerumitan mengendalikan offset ini, terutamanya di sekitar jurang dalam ruang aksara, akan menjadikan pengekod dan penyahkod jauh lebih rumit daripada yang ada hari ini.
Julat Urutan Bait UTF-8 yang Diperbetulkan
| Julat Urutan Bait | Ofset | Julat Titik Kod |
|---|---|---|
| 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 |
Mengeluarkan Aksara Sah Mencetuskan Perdebatan
Aspek kontroversi lain melibatkan sengaja menjadikan aksara Unicode tertentu mustahil untuk dikodkan. Cadangan tersebut melangkau aksara kawalan C1 dan surrogate Unicode sepenuhnya, dengan hujah bahawa ia tidak sepatutnya muncul dalam teks biasa. Walau bagaimanapun, keputusan ini telah menarik kritikan tajam daripada pembangun yang perlu mengendalikan data warisan atau bekerja dengan sistem sedia ada.
Ia kelihatan seperti cadangan yang sangat berani untuk sengaja mempunyai codepoint yang tidak boleh dikodkan.
Sekatan tersebut meluas kepada aksara biasa seperti tab mendatar dan carriage return, dengan cadangan itu malah melarang pengakhiran baris gaya Windows . Pengkritik berhujah ini mencipta halangan yang tidak perlu untuk penerimaan dan memaksa pembangun untuk menolak teks yang sah sempurna yang mungkin perlu diproses oleh pengguna.
Magic Number dan Kebimbangan Praktikal
Cadangan tersebut termasuk magic number - urutan byte khas yang mengenal pasti teks Corrected UTF-8 yang diperbetulkan, serupa dengan byte order mark dalam UTF-16 . Walau bagaimanapun, maklum balas komuniti menunjukkan pendekatan ini telah terbukti bermasalah dalam amalan. Penanda ini cenderung menyelinap ke tengah-tengah rentetan teks dan menyebabkan isu yang tidak dijangka dalam aplikasi dunia sebenar.
Komuniti juga mempersoalkan sama ada mengembangkan ruang aksara sebenarnya perlu. Pertumbuhan Unicode semasa terutamanya datang daripada menambah lebih banyak aksara Cina, Jepun, dan Korea, tetapi pengembangan ini tidak akan berterusan selama-lamanya. Pada kadar peruntukan semasa, ruang sedia ada sepatutnya bertahan sekitar 600 tahun.
Penyelesaian Alternatif Sudah Wujud
Beberapa ahli komuniti menunjuk kepada penyelesaian sedia ada yang menangani masalah serupa tanpa memecahkan keserasian. Standard UCSX , yang dibangunkan oleh penyumbang Unicode sebenar, menyediakan pengembangan ruang aksara apabila diperlukan. Sementara itu, standard IETF yang akan datang akan memberikan panduan mengenai aksara Unicode mana yang perlu dielakkan dalam amalan, menangani beberapa kebimbangan yang sama tanpa memerlukan pengekodan baharu.
Cabaran asas yang dihadapi oleh mana-mana pengganti UTF-8 ialah pangkalan terpasang yang besar bagi sistem dan data sedia ada. Kejayaan UTF-8 datang daripada keserasian sepenuhnya dengan ASCII sambil mengendalikan semua aksara Unicode . Mana-mana pengganti yang memecahkan keserasian ini menghadapi perjuangan yang sukar untuk penerimaan, tanpa mengira merit teknikalnya.
Konsensus komuniti kelihatan jelas: walaupun UTF-8 mungkin mempunyai beberapa keanehan sejarah, faedah praktikal pengekodan baharu tidak mengatasi kos memecah-belahkan ekosistem. Buat masa ini, nampaknya dunia teknologi akan terus hidup dengan UTF-8 yang tidak diperbetulkan.
Rujukan: Corrected UTF-8