Wszyscy wiedzą, że PHP ma problemy z Unicode. Wersja 6 została skutecznie porzucona z powodu trudności z implementacją Unicode. Ale zastanawiam się, czy ktoś wie, jakie są dokładne powody? Problemy z architekturą / projektowaniem, problemy z wydajnością, problemy społeczności (założę się, że nie), coś innego?
Odpowiedzi:
PHP jako język na pewno może go mieć, ale myślę, że problem polega na kompatybilności z istniejącymi programami. Obsługa Unicode może łamać je w subtelny sposób, co jest najbardziej irytującym rodzajem błędu.
Obecnie większość funkcji przetwarzania łańcuchów w PHP jest „binarnie bezpieczna”, co oznacza, że możesz ich używać do przetwarzania dowolnego pliku w dowolnym kodowaniu, a także formatów binarnych, takich jak dane obrazu itp.
Po dodaniu ciągów Unicode trzeba bardzo uważać, aby nie mieszać ciągów Unicode z ciągami binarnymi (dość trudne, gdy ciągi pochodzą z różnych źródeł i nigdy wcześniej nie musiałeś się o to martwić). I nie można już być ignorantem w kwestii kodowania (a wiele skryptów nie zna się na tym!)
Innym trudnym, ale możliwym do rozwiązania problemem jest przypadkowy dostęp do ciągów znaków Unicode. Wdrożenie $string[$offset]zmian z trywialnych na bardzo wolne lub mało wolne i bardzo złożone.
Myślę też, że błędem było wybranie UTF-16 jako wewnętrznego kodowania dla PHP. Ma takie same problemy jak UTF-8 (zmienna szerokość z powodu par zastępczych) i nieefektywność UCS-2. Może powinni to zeskrobać i zacząć od nowa z UTF-8?
</speculation>
TLDR: wiele bibliotek PHP jest tylko cienką warstwą w stosunku do rodzimych bibliotek C, które nie obsługują Unicode lub obsługują go w sposób niezgodny ze sobą. Poprawienie tej sytuacji może wprowadzić wstecz niezgodne zmiany.
ZASTRZEŻENIE: ponieważ kilka lat temu przeszedłem z PHP na Python (nigdy nie oglądam się za siebie), moja opinia jest wyraźnie stronnicza.
Myślę, że PHP to fajny i sprytny hack. Jako hack zaczął się bezpretensjonalnie i wyrósł nieco chaotycznie ze zbioru rzadkich bibliotek - brakuje mu przemyślanego i jednolitego projektu (z perspektywy teorii języka komputerowego).
Jak powiedział Machiavelli, „ten, kto najpierw nie położył fundamentów, może z wielką zdolnością położyć je później, ale zostaną ułożeni z trudem dla architekta i niebezpieczeństwem dla budynku”.
W przypadku języka programowania, im bardziej popularny, tym trudniej go zmienić. Dlatego języki takie jak C zmieniają się co 10 lat. Na przykład Python 3 wprowadził wiele wstecznie niezgodnych zmian i nie był ładny. Obsługa Unicode we wcześniejszych wcieleniach Pythona była już uważana za lepszą od obecnego stanu rzeczy w PHP, ale zgadnij co: najbardziej polemiczne zmiany w Pythonie 3 są związane z obsługą Unicode. Ten rant od Armin Ronacher podsumowuje frustrację z ogromnym udziałem społeczności Pythona.
PHP jako „wszechobecna” platforma internetowa sprawia, że jest ofiarą własnego sukcesu. Zapewnienie ujednoliconego wsparcia dla Unicode w PHP jest nieuniknione, ale będzie wymagało dużo krwi, potu i łez.
Jednym z głównych powodów zatrzymania starej pracy PHP 6 była wewnętrzna złożoność, którą przyniosła i ilość pracy do wykonania, której prawie nikt nie rozumiał.
Trochę historii: implementacja Unicode w PHP 6 została zaprojektowana przez potrzebę większego użytkownika PHP i próbowała zrobić to poprawnie. Po dokonaniu oceny główny projektant PHP, który ma obsługiwać Unicode, zdecydował się dodać nowy typ łańcucha, którym wewnętrznie jest Utf-16 i umożliwić stosowanie różnych kodowań w różnych miejscach. Tak więc kod może być zapisany w jednym kodowaniu, dane wyjściowe mogą wykorzystywać inne kodowanie, a „operacje runtme” inne kodowanie. Powodem wyboru UTF-16 było to, że praca powinna opierać się na jednostce ICU, która używa UTF-16 i stwierdzono, że to kodowanie sprawia, że wspólne operacje na łańcuchach znaków są szybkie, a konwersja między utf- i utf-16 jest stosunkowo tania . Jak na razie dobrze.
Teraz konsekwencją tego jest przede wszystkim wprowadzenie nowego typu łańcucha. Wewnętrzny system typów PHP do tej pory miał kilka typów (NULL, bool, int / long, float / double, string, tablica, zasób, obiekt) i mnóstwo kodu miało pewne założenia, że tak jest. Oprócz takich założeń, wszystkie funkcje działające na ciągach znaków, a jest ich wiele, należy oceniać indywidualnie i należy zdecydować, jak obsługiwać kodowanie. Czy powinny działać na ciągach binarnych lub ciągach Unicode? Jeśli wymagana jest konwersja, które kodowanie należy zastosować itp. I jest to dużo pracy, aw niektórych przypadkach dość skomplikowane, aby zrobić dobrze. Ponadto wewnętrzne interfejsy API stały się dość skomplikowane, ponieważ większość kluczowych interfejsów API w PHP ma wersje dla ciągów binarnych (stary), a następnie często wersję dla ciągów „zakodowanych w środowisku wykonawczym”,
W trakcie tego procesu wielu programistów potknęło się o coplexity, zirytowało się utf-16 i nie podobało mu się to, że spowodowałoby to więcej niż podwojenie użycia pamięci i poświęcenie dużej ilości czasu na konwersję ciągów przy jednoczesnym zerwaniu większości istniejących aplikacji. Tak więc PHP napędzane przez wolontariuszy, coraz mniej programistów pracowało nad tym, a inne rzeczy gromadziły się, a autorzy byli niezadowoleni i ostatecznie trzeba było porzucić.
Co może przynieść przyszłość? - Następuje powolna ewolucja, w której coraz więcej rzeczy w PHP jest zbudowanych wokół utf-8. Nie w mocny sposób z niestandardowym typem i zmuszaniem do wszystkiego, a obecnie programiści nie są zmotywowani do dotknięcia tego gorącego żelaza. Można mieć nadzieję, że ktoś ma dobrą propozycję, aby działał dobrze, ale obecnie „wszyscy” uciekną, jeśli tylko usłyszą to słowo. :)
Myślę, że faktycznym powodem jest to, że zespół programistów PHP nie ma jasnego planu rozwoju PHP (wspomnijmy o dość gorącej dyskusji, gdy ktoś z php-internals postanowił uruchomić gałąź PHP 5.4 bez uprzedniej zgody na to, jakie funkcje 5.4 powinny zawierać). Bardzo lubię ten język, ale sposób, w jaki jest rozwijany, trochę mnie martwi.