Mengapa sebenarnya PHP tidak dapat memiliki dukungan unicode penuh?


18

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?

Jawaban:


16

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>


2
setuju sepenuhnya dengan beralih ke utf8.
GrandmasterB

Anda berpikir bahwa UTF-16, terlepas dari ukuran data chunk, lebih buruk daripada UTF-8?
ts01

3
@Dean Harding: Saya tidak mengatakan bahwa tidak mungkin untuk bekerja dengan UTF-16 sama sekali, hanya saja akses acak (di O (1) ) tidak mungkin. UTF-16 tidak menjamin bahwa codepoint ke-100 akan dimulai pada byte ke-200, jadi untuk mengakses codepoint ke-100 Anda harus memindai semua yang sebelumnya secara linear (dan implementasi yang baik tentu saja akan menyimpan hasil cache). Dalam hal ini mirip dengan UTF-8 (yaitu akses ke karakter ke-n / codepoint adalah O (n) , bukan O (1) ).
Kornel

1
@Dean: Hal-hal seperti collation atau konversi antara UTF-16 dan UTF-8 pasti tidak bekerja sama untuk pengganti seperti yang mereka lakukan untuk menggabungkan karakter.
dan04

3
Ringkasan yang bagus tentang alasan memilih UTF-8 daripada UTF-16 (atau penyandian lainnya) dapat ditemukan di utf8everywhere.org .
Joachim Sauer

11

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.


well, semua orang setuju di sini, saya kira. Tetapi saya menanyakan detailnya;)
ts01

3
Masalahnya adalah bahwa banyak pustaka yang mendasari tidak menangani unicode dengan baik, dan itu sangat sulit untuk menyelesaikan masalah tanpa memulai dari awal.
Paulo Scardine

(fyi, "sejak beberapa tahun yang lalu", PHP menjadi lebih baik dan Python semakin buruk)
ZJR

1
@ZJE: Senang tahu, terima kasih. Apakah Anda cukup baik untuk menunjukkan beberapa bahan referensi tentang perubahan ini?
Paulo Scardine

6

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. :)


1

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.


2
Saya meninggalkan PHP untuk Python pada tahun 2006 setelah menggunakannya selama 5 tahun yang solid - Python memiliki proses pengembangan yang luar biasa dan kepemimpinan yang baik - ditambah bahasanya jauh lebih singkat, kuat, dan konsisten daripada PHP. Tantangan utama adalah menemukan kerangka kerja web yang tepat. Kami menggulung sendiri - AppStruct.
gahooa

1
Yah kami memiliki peta jalan untuk PHP 6. Tidak membantu;) Salah satu masalah peta jalan adalah bahwa PHP didorong oleh sukarelawan yang muncul (dan jika mereka memiliki "ide bagus" kami ingin menyimpannya dan menambahkan fitur mereka segera) dan tiba-tiba menghilang (menikah, berganti pekerjaan, ...)
johannes

Untungnya PHP 7 sukses.
hazard89

5 tahun kemudian dan masih tanpa 'dukungan unicode penuh' :)
Mchl
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.