Todo mundo sabe que o PHP tem problemas com o Unicode. A versão 6 é efetivamente abandonada, devido a dificuldades de implementação do Unicode. Mas me pergunto se alguém sabe quais são as razões exatas . Problemas de arquitetura / design, problemas de desempenho, problemas da comunidade (aposto que não), alguma outra coisa?
Respostas:
Definitivamente, o PHP como linguagem pode tê-lo, mas acho que o problema está na compatibilidade com os programas existentes. O suporte a Unicode pode quebrá-los de maneiras sutis, que é o tipo de bug mais irritante de se ter.
Atualmente, a maioria das funções de processamento de strings no PHP são "seguras em binários", o que significa que você pode usá-las para processar qualquer arquivo em qualquer codificação, bem como em formatos binários como dados de imagem, etc.
Com a adição de cadeias Unicode, você deve ter muito cuidado para não misturar cadeias Unicode com cadeias binárias (bastante difícil quando suas cadeias vêm de fontes diferentes e você nunca teve que se preocupar com isso antes). E você não podia mais ignorar as codificações (e muitos scripts ignoram isso!)
Outro problema difícil, mas solucionável, é o acesso aleatório em cadeias de caracteres Unicode. Implementação de $string[$offset]alterações de trivial para muito lento ou pouco lento e muito complexo.
Também acho que foi um erro escolher UTF-16 como codificação interna para PHP. Tem os mesmos problemas que o UTF-8 (largura variável por causa dos pares substitutos) e a ineficiência do UCS-2. Talvez eles devessem descartar isso e começar de novo com UTF-8?
</speculation>
TLDR: muitas bibliotecas PHP são apenas uma camada fina sobre as bibliotecas C nativas que não suportam unicode, ou suportam de maneiras incompatíveis entre si. A retificação dessa situação provavelmente introduzirá mudanças incompatíveis com versões anteriores.
AVISO LEGAL: como mudei do PHP para o Python (para nunca olhar para trás) há alguns anos, minha opinião é claramente tendenciosa.
Eu acho que o PHP é um truque legal e inteligente. Como um hack, começou despretensioso e cresceu um pouco caoticamente a partir de um monte de bibliotecas esparsas - sem um design bem pensado e unificado (da perspectiva da teoria da linguagem de computador).
Como disse Maquiavel, "aquele que ainda não lançou suas fundações poderá, com grande habilidade, lançá-las depois, mas elas terão problemas para o arquiteto e perigo para o edifício".
Para uma linguagem de programação, quanto mais popular, mais difícil é mudar. É por isso que idiomas como C mudam a cada 10 anos. Por exemplo, o Python 3 fez muitas alterações incompatíveis com versões anteriores, e não foi bonito. O suporte a unicode nas encarnações anteriores do Python já era considerado superior ao estado atual do PHP, mas adivinhe: as mudanças mais polêmicas no Python 3 estão relacionadas ao manuseio do unicode. Este discurso de Armin Ronacher resume a frustração de uma grande parte da comunidade Python.
O PHP sendo "a" plataforma onipresente da Web faz com que seja vítima de seu próprio sucesso. Trazer suporte unificado para unicode em PHP é inevitável, mas exigirá muito sangue, suor e lágrimas.
Um dos principais motivos pelos quais o antigo trabalho do PHP 6 foi interrompido foi devido à complexidade interna que trouxe e à quantidade de trabalho a ser realizado, que quase ninguém entendeu completamente.
Um pouco de história: a implementação de Unicode do PHP 6 foi projetada pela necessidade de um usuário maior de PHP e tentou fazer o Unicode "certo". Após alguma avaliação, o criador principal do suporte a ser Unicode do PHP optou por adicionar um novo tipo de string que internamente é o Utf-16 e permitir que diferentes codificações sejam usadas em locais diferentes. Portanto, o código pode ser escrito em uma codificação, a saída pode usar uma codificação diferente e "operações runtme" em outra codificação. A razão para escolher o UTF-16 foi que o trabalho deveria se basear no livrário da UTI que usa o UTF-16 e verificou-se que essa codificação faz operações comuns de cadeias de maneira rápida, enquanto a conversão entre utf e utf-16 é relativamente barata. . Por enquanto, tudo bem.
Agora, a consequência de fazer isso é principalmente a introdução de um novo tipo de string. O sistema de tipos internos do PHP até então tinha alguns tipos (NULL, bool, int / long, float / double, string, array, recurso, objeto) e muitos códigos tinham algumas suposições quanto a esse caso. Além de tais suposições, todas as funções que operam em strings, e há muitas, precisam ser avaliadas individualmente e precisa ser decidido como lidar com codificações. Eles devem trabalhar em cadeias binárias ou unicode? Se for necessária uma conversão, qual codificação deve ser usada etc. e isso é muito trabalhoso e, em alguns casos, bastante complicado de se fazer o certo. Além disso, as APIs internas tornaram-se bastante complicadas, pois a maioria das principais APIs do PHP obteve versões para cadeias binárias (a antiga) e, em seguida, frequentemente uma versão para cadeias "codificadas em tempo de execução",
Ao longo do processo, muitos desenvolvedores se depararam com a coplexidade, ficaram aborrecidos com o utf-16 e não gostaram do fato de que isso iria mais do que duplicar o uso de memória e gastar muito tempo convertendo strings e quebrando a maioria dos aplicativos existentes. Portanto, sendo o PHP conduzido por voluntários, cada vez menos desenvolvedores estavam trabalhando nele e outras coisas se acumulavam e os colaboradores ficaram infelizes e, no final, tiveram que ser abandonados.
Agora, o que o futuro pode trazer? - Há uma lenta evolução acontecendo, que mais e mais coisas no PHP são construídas em torno do utf-8. Não de uma maneira forte, com um tipo personalizado e forçando tudo, e atualmente os desenvolvedores não estão motivados a tocar esse ferro quente. Pode-se esperar que alguém tenha uma boa proposta para que funcione bem, mas atualmente "todo mundo" foge se ouvir apenas a palavra. :)
Eu acho que o motivo real é que a equipe de desenvolvimento do PHP não possui um roteiro claro para o desenvolvimento do PHP (vamos apenas mencionar uma discussão bastante acalorada quando alguém no php-internals decidiu iniciar o ramo do PHP 5.4 sem concordar previamente com os recursos que o 5.4 deveria conter). Eu gosto muito dessa linguagem, mas o modo como ela está sendo desenvolvida me deixa um pouco preocupado.