Semua orang tahu, bahwa PHP memiliki masalah dengan Unicode. Versi 6 secara efektif ditinggalkan, karena kesulitan implementasi Unicode. Tapi saya ingin tahu apakah ada yang tahu apa alasan sebenarnya ? Masalah arsitektur / desain, masalah kinerja, masalah komunitas (saya yakin tidak), sesuatu yang lain?
PHP sebagai bahasa pasti bisa memilikinya, tapi saya pikir masalahnya adalah kompatibilitas dengan program yang ada. Dukungan Unicode dapat memecahkannya dengan cara yang halus, yang merupakan jenis bug yang paling menjengkelkan.
Saat ini sebagian besar fungsi pemrosesan string dalam PHP adalah "binary-safe", yang berarti Anda dapat menggunakannya untuk memproses file apa pun dalam penyandian apa pun serta format biner seperti data gambar, dll.
Dengan tambahan string Unicode Anda harus sangat berhati-hati untuk tidak mencampur string Unicode dengan string biner (cukup sulit ketika string Anda berasal dari sumber yang berbeda dan Anda tidak pernah perlu khawatir tentang hal itu sebelumnya). Dan Anda tidak bisa lagi tidak tahu tentang penyandian (dan banyak skrip tidak tahu tentang ini!)
Masalah lain yang sulit, tetapi dapat dipecahkan adalah akses acak dalam string Unicode. Implementasi $string[$offset]perubahan dari sepele menjadi sangat lambat atau sedikit lambat dan sangat kompleks.
Juga saya pikir itu adalah kesalahan untuk memilih UTF-16 sebagai pengkodean internal untuk PHP. Ini memiliki masalah yang sama dengan UTF-8 (lebar variabel karena pasangan pengganti) dan inefisiensi UCS-2. Mungkin mereka harus memo itu dan mulai lagi dengan UTF-8?
</speculation>
TLDR: banyak pustaka PHP hanya lapisan tipis di atas pustaka C asli yang tidak mendukung unicode, atau mendukungnya dengan cara yang tidak kompatibel satu sama lain. Memperbaiki situasi ini cenderung memperkenalkan perubahan yang tidak kompatibel ke belakang.
PENOLAKAN: karena saya telah beralih dari PHP ke Python (untuk tidak pernah melihat ke belakang) beberapa tahun yang lalu, pendapat saya jelas bias.
Saya pikir PHP adalah hack yang bagus dan pintar. Sebagai peretasan, itu mulai bersahaja dan tumbuh agak kacau dari sekelompok perpustakaan jarang - kurang memiliki pemikiran yang baik dan desain terpadu (dari perspektif teori bahasa komputer).
Seperti yang dikatakan oleh Machiavelli, "dia yang belum pertama kali meletakkan fondasinya mungkin bisa dengan kemampuan yang besar untuk meletakkannya setelah itu, tetapi mereka akan diletakkan dengan masalah pada arsitek dan bahaya pada bangunan".
Untuk bahasa pemrograman, semakin populer, semakin sulit untuk berubah. Itu sebabnya bahasa seperti C berubah setiap 10 tahun sekali. Sebagai contoh, Python 3 membuat banyak perubahan yang tidak kompatibel ke belakang, dan itu tidak cantik. Dukungan unicode dalam inkarnasi Python sebelumnya sudah dianggap lebih unggul daripada keadaan saat ini di PHP, tetapi coba tebak: perubahan paling polemik di Python 3 terkait dengan penanganan unicode. Kata-kata kasar dari Armin Ronacher ini merangkum frustrasi dari sebagian besar komunitas Python.
PHP menjadi "platform" di mana-mana membuatnya menjadi korban dari keberhasilannya sendiri. Membawa dukungan terpadu untuk unicode dalam PHP tidak bisa dihindari, tetapi akan membutuhkan banyak darah, keringat dan air mata.
sumber
Salah satu alasan utama pekerjaan PHP 6 lama dihentikan adalah karena kompleksitas internal yang dibawanya dan jumlah pekerjaan yang harus dilakukan, yang nyaris tidak ada orang yang sepenuhnya tidak mengerti.
Sedikit sejarah: PHP 6's Unicode imlementation dirancang oleh kebutuhan pengguna PHP yang lebih besar dan mencoba melakukan Unicode "benar". Setelah beberapa evaluasi, perancang utama dari PHP-to-be-Unicode-support telah memilih untuk menambahkan tipe string baru yang secara internal adalah Utf-16 dan untuk memungkinkan lingkup yang berbeda untuk digunakan di tempat yang berbeda. Jadi kodenya mungkin ditulis dalam satu penyandian, keluaran mungkin menggunakan penyandian yang berbeda dan "operasi runtme" beberapa penyandian lainnya. Alasan memilih UTF-16 adalah bahwa pekerjaan harus didasarkan pada ICU livrary yang menggunakan UTF-16 dan ditemukan bahwa pengkodean ini membuat operasi string yang umum dengan cara cepat sementara konversi antara utf- dan utf-16 relatif murah . Sejauh ini baik.
Sekarang konsekuensi dari melakukan ini adalah pengantar jenis string baru. Sistem tipe internal PHP sampai saat itu memiliki beberapa jenis (NULL, bool, int / long, float / double, string, array, resource, objek) dan banyak kode memiliki asumsi mengenai hal ini. Selain asumsi-asumsi seperti itu, semua fungsi yang beroperasi pada string, dan ada banyak di antaranya, harus dievaluasi secara individual dan harus diputuskan bagaimana menangani pengodean. Haruskah mereka bekerja pada string biner atau string unicode? Jika diperlukan konversi, pengkodean mana yang harus digunakan, dll. Dan ini banyak pekerjaan dan dalam beberapa kasus cukup rumit untuk dilakukan dengan benar. Selain itu, API internal menjadi cukup rumit, karena sebagian besar API kunci di PHP mendapatkan versi untuk string biner (yang lama) dan kemudian sering versi untuk string "runtime encoded",
Selama proses melakukan itu banyak pengembang tersandung coplexity, menjadi jengkel oleh utf-16 dan tidak menyukai kenyataan bahwa ini akan lebih dari menggandakan penggunaan memori dan menghabiskan banyak waktu mengonversi string sambil memecah sebagian besar aplikasi yang ada. Jadi, PHP didorong oleh sukarelawan, semakin sedikit pengembang yang mengerjakannya dan hal-hal lain menumpuk dan kontributor menjadi tidak senang dan pada akhirnya harus ditinggalkan.
Sekarang apa yang akan terjadi di masa depan? - Ada evolusi lambat yang terjadi bahwa semakin banyak hal dalam PHP yang dibangun sekitar utf-8. Tidak dengan cara yang kuat dengan tipe kustom dan memaksa segalanya dan saat ini pengembang tidak termotivasi untuk menyentuh setrika panas ini. Seseorang dapat berharap bahwa seseorang memiliki proposal yang bagus untuk membuatnya bekerja dengan baik, tetapi saat ini "semua orang" akan melarikan diri jika mereka hanya mendengar kata itu. :)
sumber
Saya kira alasan sebenarnya adalah bahwa tim pengembang PHP tidak memiliki peta jalan yang jelas untuk pengembangan PHP (mari kita sebutkan diskusi yang cukup panas ketika seseorang di php-internal memutuskan untuk memulai cabang PHP 5.4 tanpa sebelumnya menyetujui fitur apa yang seharusnya berisi 5.4). Saya sangat menyukai bahasa ini, tetapi cara ini sedang dikembangkan membuat saya sedikit khawatir.
sumber