Відповіді:
PHP як мова, безумовно, може мати її, але я думаю, що проблема полягає у сумісності з існуючими програмами. Підтримка Unicode може зламати їх тонкими способами, що є найприємнішим видом помилок.
В даний час більшість функцій обробки рядків у PHP є "бінарними", а це означає, що ви можете використовувати їх для обробки будь-якого файлу в будь-якому кодуванні, а також бінарних форматів, таких як дані зображення тощо.
Додаючи рядки Unicode, вам доведеться бути дуже обережними, щоб не змішувати рядки Unicode з бінарними рядками (досить важко, коли ваші рядки надходять з різних джерел, і вам ніколи раніше про це не доводилося хвилюватися). І ви вже не можете бути неосвіченими щодо кодування (і багато сценаріїв про це не знають!)
Ще одна важка, але вирішена проблема - випадковий доступ у рядках Unicode. Реалізація $string[$offset]змін від тривіальних до дуже повільних або мало повільних і дуже складних.
Також я думаю, що було помилкою вибрати UTF-16 як внутрішнє кодування для PHP. Він має ті ж проблеми, що і UTF-8 (змінна ширина через сурогатних пар) та неефективність UCS-2. Можливо, їм слід це заблокувати і почати знову з UTF-8?
</speculation>
TLDR: багато бібліотек PHP є лише тонким шаром над нативними бібліотеками C, які не підтримують unicode або підтримують його способами, несумісними між собою. Виправлення цієї ситуації, ймовірно, внесе зміни, несумісні з відсталими.
ВІДМОВА: коли я перейшов з PHP на Python (щоб ніколи не озирнувся назад) кілька років тому, моя думка явно упереджена.
Я думаю, що PHP - це хороший і розумний хакер. Як хак, він почався невибагливо і зростав дещо хаотично з купою рідких бібліотек - не вистачало продуманого та уніфікованого дизайну (з точки зору теорії комп'ютерної мови).
За словами Макіавеллі, "той, хто не вперше заклав свої фундаменти, може після цього закласти великі можливості, але вони будуть закладені неприємностями для архітектора та небезпекою для будівлі".
Для мови програмування, чим популярніша, тим складніше змінити. Ось чому такі мови, як C, змінюються раз на 10 років. Наприклад, Python 3 зробив багато несумісних змін, і це було не дуже. Підтримка unicode в попередніх втіленнях Python вже вважалася вищою за сучасний стан справ у PHP, але здогадайтесь що: найбільш полемічні зміни в Python 3 пов'язані з обробкою unicode. Ця тирада від Armin Ronacher резюмує розчарування від величезної частини суспільства Python.
PHP, будучи "всюдисущою" веб-платформою, робить її жертвою власного успіху. Забезпечити єдину підтримку unicode в PHP неминуче, але знадобиться багато крові, поту і сліз.
Однією з головних причин, коли стара робота PHP 6 була припинена, була пов'язана з внутрішньою складністю, яку вона принесла, та об’ємом роботи, яку ледве ніхто повністю не зрозумів.
Трохи історії: імплементація Unicode PHP 6 була розроблена потребою більшого користувача PHP і намагалася зробити Unicode «правильно». Після деякої оцінки первинний дизайнер підтримки PHP, який повинен бути Unicode, вирішив додати новий тип рядка, який внутрішньо є Utf-16, і дозволити використовувати різні кодування в різних місцях. Таким чином, код може бути записаний в одному кодуванні, вихід може використовувати інше кодування та "виконувати операції виконання" деякого іншого кодування. Причиною вибору UTF-16 було те, що робота повинна базуватися на ліврарі ICU, який використовує UTF-16, і було встановлено, що це кодування робить швидкі звичайні операції струну, в той час як конверсія між utf- і utf-16 є відносно дешевою . Все йде нормально.
Тепер наслідком цього є передусім введення нового типу рядка. Система внутрішнього типу PHP до цього мала декілька типів (NULL, bool, int / long, float / double, string, масив, ресурс, об’єкт), і багато коду мали деякі припущення щодо цього. Окрім таких припущень, усі функції, що працюють на рядках, і таких дуже багато, повинні оцінюватися індивідуально, і слід вирішити, як поводитися з кодуваннями. Чи повинні вони працювати над бінарними рядками або рядками Unicode? Якщо потрібне перетворення, яке кодування слід використовувати і т. Д., І це велика робота, а в деяких випадках досить складно зробити правильно. Крім того, внутрішні API стали досить складними, оскільки більшість ключових API в PHP отримали версії для двійкових рядків (старий), а потім часто і версії для рядків, кодованих під час виконання,
Під час цього багато розробників натрапили на складність, роздратували utf-16 і не сподобалося, що це більше ніж подвоїть використання пам'яті та витратить багато часу на перетворення рядків, порушуючи більшість існуючих додатків. Так, PHP, керований волонтерами, все менше розробників працював над цим, і інші речі нагромаджувались, і вкладники ставали нещасними, і врешті-решт від нього довелося відмовитися.
Тепер що може принести майбутнє? - Відбувається повільна еволюція, що все більше і більше речей у PHP ae будується навколо utf-8. Не дуже сильно з користувацьким типом і змушуючи все, і зараз розробники не вмотивовані торкатися цього гарячого праска. Можна сподіватися, що у когось є гарна пропозиція, щоб змусити його добре працювати, але наразі "всі" втечуть, якщо вони почують лише слово. :)
Я думаю, що справжньою причиною є те, що команді, що розробляє PHP, не вистачає чіткої дорожньої карти розвитку PHP (згадаймо досить гарячу дискусію, коли хтось із PHP-інтерналів вирішив запустити гілку PHP 5.4, попередньо не погодившись, які функції 5.4 повинні містити). Мені ця мова дуже подобається, але спосіб її розробки мене трохи хвилює.