Perché esattamente PHP non può supportare completamente unicode?

PHP come lingua può sicuramente averlo, ma penso che il problema sia con la compatibilità con i programmi esistenti. Il supporto Unicode può romperli in modi sottili, che è il tipo di bug più fastidioso da avere.

Attualmente la maggior parte delle funzioni di elaborazione delle stringhe in PHP sono "binary-safe", il che significa che puoi usarle per elaborare qualsiasi file in qualsiasi codifica così come i formati binari come i dati di immagine, ecc.

Con l'aggiunta di stringhe Unicode dovresti stare molto attento a non mescolare le stringhe Unicode con le stringhe binarie (piuttosto difficile quando le tue stringhe provengono da fonti diverse e non hai mai dovuto preoccuparti prima). E non puoi più ignorare le codifiche (e molti script sono ignoranti a riguardo!)

Un altro problema difficile, ma risolvibile è l'accesso casuale nelle stringhe Unicode. L'implementazione di $string[$offset] cambia da banale a molto lenta o poco lenta e molto complessa.

Inoltre penso che sia stato un errore scegliere UTF-16 come codifica interna per PHP. Ha gli stessi problemi di UTF-8 (larghezza variabile a causa delle coppie surrogate) e l'inefficienza di UCS-2. Forse dovrebbero eliminarlo e ricominciare con UTF-8?

</speculation>

TLDR: molte librerie PHP sono solo un sottile strato su librerie C native che non supportano l'unicode o che supportano in modo incompatibile l'una con l'altra. È probabile che la rettifica di questa situazione introduca modifiche incompatibili con versioni precedenti.

ESCLUSIONE DI RESPONSABILITÀ: quando sono passato da PHP a Python (per non guardare mai indietro) qualche anno fa, la mia opinione è chiaramente di parte.

Penso che PHP sia un trucco piacevole e intelligente. Come hack, è iniziato senza pretese e è cresciuto in modo un po 'caotico da un mucchio di librerie sparse - prive di un design ben pensato e unificato (dal punto di vista della teoria del linguaggio informatico).

Come diceva Machiavelli, "colui che non ha posto le sue fondamenta può essere capace con molta abilità di deporle in seguito, ma saranno messe in difficoltà all'architetto e pericolo per l'edificio".

Per un linguaggio di programmazione, il più popolare, più difficile da cambiare. Questo è il motivo per cui le lingue come C cambiano ogni 10 anni. Ad esempio, Python 3 ha apportato molte modifiche incompatibili con le versioni precedenti e non è stato bello. Il supporto Unicode nelle precedenti incarnazioni Python era già considerato superiore allo stato attuale delle cose in PHP, ma indovina cosa: le modifiche più polemiche in Python 3 sono legate alla gestione Unicode. Questo rant da Armin Ronacher riassume la frustrazione di una grande parte della comunità Python.

PHP è "la" piattaforma web onnipresente che la rende vittima del proprio successo. Portare il supporto unificato per Unicode in PHP è inevitabile, ma richiederà molto sangue, sudore e lacrime.

Uno dei motivi principali per cui il vecchio lavoro di PHP 6 è stato interrotto era dovuto alla complessità interna che comportava e alla quantità di lavoro da fare, che a malapena chiunque non aveva compreso completamente.

Un po 'di storia: l'implementazione di Unicode di PHP 6 è stata progettata dalla necessità di un utente PHP più grande e ha cercato di fare "giusto" Unicode. Dopo una valutazione, il progettista principale del supporto to-be-Unicode di PHP ha scelto di aggiungere un nuovo tipo di stringa che internamente è Utf-16 e per consentire l'utilizzo di diverse encdings in posizioni diverse. Quindi il codice potrebbe essere scritto in una codifica, l'output potrebbe usare una codifica diversa e "operazioni runtme" qualche altra codifica. La ragione per scegliere UTF-16 era che il lavoro dovrebbe essere basato sulla livrary della ICU che usa UTF-16 e si è scoperto che questa codifica rende operazioni stringhe comuni in modo veloce mentre conversi tra utf- e utf-16 è relativamente economico . Fin qui tutto bene.

Ora la conseguenza di ciò è in primo luogo l'introduzione di un nuovo tipo di stringa. Il sistema di tipi interni di PHP fino ad allora aveva pochi tipi (NULL, bool, int / long, float / double, string, array, resource, object) e un sacco di codice aveva alcune ipotesi su questo caso. Oltre a tali presupposti tutte le funzioni che operano su stringhe, e ce ne sono molte, devono essere valutate individualmente e si deve decidere come gestire le codifiche. Dovrebbero lavorare su stringhe binarie o stringhe Unicode? Se è richiesta una conversione, quale codifica dovrebbe essere usata ecc. E questo è un sacco di lavoro e in alcuni casi abbastanza complicato da fare bene. Inoltre, le API interne sono diventate piuttosto complicate, poiché la maggior parte delle API chiave in PHP ha ottenuto le versioni per le stringhe binarie (quella vecchia) e quindi spesso una versione per le stringhe "runtime encoded", così come le stringhe utf-16, creando un pasticcio. ..

Durante il processo in cui molti sviluppatori hanno inciampato nella coplexity, si sono infastiditi da utf-16 e non hanno gradito il fatto che questo avrebbe più che doppio utilizzo della memoria e passasse molto tempo a convertire stringhe mentre rompevano la maggior parte delle applicazioni esistenti. Quindi, essendo il PHP guidato da volontari, sempre meno sviluppatori stavano lavorando su di esso e altre cose si accumulavano e i contributori diventavano infelici e alla fine dovevano essere abbandonati.

Ora cosa potrebbe portare il futuro? - Sta succedendo una lenta evoluzione che sempre più cose in PHP sono costruite attorno a utf-8. Non in modo strong con un tipo personalizzato e forzando tutto e attualmente gli sviluppatori non sono motivati a toccare questo ferro caldo. Si può sperare che qualcuno abbia una buona proposta per farlo funzionare bene, ma attualmente "tutti" scapperanno se sentiranno solo la parola. :)