Dlaczego dokładnie PHP nie może mieć pełnej obsługi Unicode?

18

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?

ts01
źródło

Odpowiedzi:

16

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>

Kornel
źródło
2
całkowicie zgadzam się na przejście na utf8.
GrandmasterB,
myślisz, że UTF-16 jest, oprócz wielkości porcji danych, gorszy niż UTF-8?
ts01
3
@Dean Harding: Nie mówię, że w ogóle nie można pracować z UTF-16, tylko że losowy dostęp (w O (1) ) nie jest możliwy. UTF-16 nie gwarantuje, że 100-ty punkt kodowy rozpocznie się od 200-tego bajtu, więc aby uzyskać dostęp do 100-tego punktu kodowego, musisz liniowo przeskanować wszystkie poprzednie (i dobra implementacja oczywiście buforuje wynik). Pod tym względem jest podobny do UTF-8 (tj. Dostęp do n-tego znaku / punktu kodowego to O (n) , a nie O (1) ).
Kornel,
1
@Dean: Rzeczy takie jak sortowanie lub konwersje między UTF-16 i UTF-8 z pewnością nie działają tak samo w przypadku surogatów, jak w przypadku łączenia znaków.
dan04
3
Doskonałe podsumowanie powodów wyboru UTF-8 zamiast UTF-16 (lub dowolnego innego kodowania) można znaleźć na stronie utf8everywhere.org .
Joachim Sauer
11

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.

Paulo Scardine
źródło
no cóż, wszyscy się tutaj zgadzają. Ale pytałem o szczegóły;)
ts01
3
Problem polega na tym, że wiele bazowych bibliotek nie radzi sobie dobrze z Unicode i bardzo trudno jest rozwiązać problem bez rozpoczynania od zera.
Paulo Scardine
(fyi, „odkąd kilka lat temu”, PHP poprawiło się, a Python gorzej)
ZJR
1
@ZJE: Miło wiedzieć, dzięki. Czy byłbyś na tyle uprzejmy, aby wskazać mi materiały referencyjne na temat tej zmiany?
Paulo Scardine
6

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

Johnnes
źródło
1

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.

Mchl
źródło
2
Porzuciłem PHP dla Pythona w 2006 roku po 5 latach użytkowania - Python ma niesamowity proces rozwoju i dobre przywództwo - a język jest o wiele bardziej zwięzły, mocny i spójny niż PHP. Głównym wyzwaniem jest znalezienie odpowiedniego frameworka internetowego. Stworzyliśmy własną - AppStruct.
gahooa
1
Cóż, mieliśmy mapę drogową dla PHP 6. Nie pomogłem;) Jednym z problemów mapy drogowej jest to, że PHP jest napędzane przez pojawiających się ochotników (a jeśli mają „dobre pomysły”, chcemy je zachować i wkrótce dodać ich funkcje) i nagle znikają (ślub, zmiana pracy, ...)
John
Na szczęście PHP 7 jest sukcesem.
niebezpieczeństwo89
5 lat później i nadal bez „pełnej obsługi Unicode” :)
Mchl