Судьба PHP6
Поговорил с одним из разработчиков PHP по поводу судьбы PHP6, самое ожидаемое изменение которого — переход на юникодные строки. Так вот Антон Довгаль рассказал, что проект, по сути, заброшен. Те несколько человек, которые занимались проектом, либо уволились, либо потеряли к нему интерес и сейчас считается, что поддержка юникодных строк в языке не так уж и нужна.
На примере своего опыта разработки и перевода проектов на PHP на UTF-8, скажу это не так. В Пайтоне, где таких проблем нет, работать гораздо проще и приятнее.
То, что в PHP приходится для поддержки Юникода работать с UTF-8, а не с UTF-32 сильно снижает производительность всех строковых операций. И добро бы, если бы для всех функций были юникодные аналоги, так это ведь не так.
Работать в PHP с UTF-32 нельзя, если вы собираетесь использовать регулярные выражения: библиотека PCRE, предназначенная для работы с регулярными выражениями, понимает только две кодировки: latin-1 (по всей видимости) и UTF-8. Кроме того, функции, использующие локаль или ICU так же работают только с UTF-8.
Если бы этот язык нативно поддерживал UTF-32… Мечты-мечты.
Ну, я не совсем то говорил.
Я хотел сказать вот что — раньше был явно интерес к PHP6 со стороны нескольких компаний. Одна из них — Yahoo и Андрей Змиевский над ним плотно работал.
Потом Андрей сменил работу и (естественно) перестал тратить большую часть своего рабочего времени на PHP6.
Но это частный случай. Общая ситуация (на мой субъективный взгляд такова) — разработка PHP6 затормозилась в первую очередь потому, что в PHP уже есть mbstring, который при всех свой недостатках, решает 90% задач со строками в Unicode/и др. А остальные 10% задач требуют существенной переделки ВСЕГО кода.
При этом для работы со строками в PHP6 (кстати, не факт, что номер версии будет именно такой) используется ICU, которая тоже есть универсальное решение сферической задачи в вакууме, а оттого не блещет скоростью. Т. е. PHP6 за счет работы с юникодом потеряет еще N% производительности (а кому это надо?).
Комментарий для tony2001:
Тем не менее, переход на массивы-классы выполняется (ArrayObject), а со строками такого движения не видно, хотя это был бы выход. Создать UnicodeString и тянуть в него методы для работы с Unicode, а кроме того, научить PCRE работать с такими строками. Уже было бы большое дело.
PHP6 заброшен или поддержка юникода в нём?
Комментарий для wiktar.com:
PHP6 == PHP + Unicode
«мы говорим PHP6, а подразумеваем Unicode» (c)
Комментарий для tony2001:
Есть библиотека, которая с космической скоростью перекодирует из UTF-8 в UTF-16 с огромной скоростью: http://u8u16.costar.sfu.ca/
Сделать на её базе перекодировку из UTF-32 в UTF-8 и засунуть в класс UnicodeString, чтобы отдавать наружу UTF-8 по запросу.
опять же, напрашивается отдельный экстеншен, т. к. это решение не универсальное =/
А почему UTF-32, а не UTF-16?
Комментарий для exh.myopenid.com:
С UTF-16 неудобно работать.
Вкратце: UTF-16 — это 16 бит на символ с некоторыми исключениями (об этом дальше). В 16 бит помещается 65535 символов, а в Unicode их намного больше, как же кодировать остальные. Они кодируются так называемыми «суррогатными парами», часть кодов в UTF-16 имеют специальное значение, если они встречаются в строке, значит за ними идёт ещё символ.
Таким образом, длина символа в строке не всегда два байта. Это значит, что длину строки UTF-16 нельзя получить делением её байтовой длины пополам, нельзя адресоваться к символу, умножив смещение на 2 и так далее.
Комментарий для exh.myopenid.com:
Немного ошибся, значений в 16 битах 65536.
я крайне сильно жду что в пхп6 приведут названия функций и порядок аргументов к одному виду. но это, похоже, без вариантов.
Комментарий для hshhhhh.name:
Варианты есть и туда PHP активно движется. Например, уже сейчас есть класс ArrayObject с нормальными методами, все названия camel case.
а не проще начать подымать новый апи для таких мегастрочек параллельно с тем что уже есть не трогая старое г-но.
пусть будет и то и то. пусть будет класс типа string как в java с регекспами внутри + системные классы для обработки?
кому надо полностью переползут на этот новый пи. старье будет какоето время на старом API жить.
Просто ИМХО глупо и дорого получается заставлять текущий апи работать по новому, да так чтобы выглядело в коде «по старому» и не было геммороя :)
Комментарий для анонимус:
Ровно это сейчас и делается. Я же написал.
Спасибо за информацию. Скорее я мигрирую на Python/Ruby, чем нормальный юникод появится в php
Комментарий для den-rad.ya.ru:
Я уже больше пишу на Python и Powershell, чем на PHP.