Поговорил с одним из разработчиков PHP по поводу судьбы PHP6, самое ожидаемое изменение которого — переход на юникодные строки. Так вот Антон Довгаль рассказал, что проект, по сути, заброшен. Те несколько человек, которые занимались проектом, либо уволились, либо потеряли к нему интерес и сейчас считается, что поддержка юникодных строк в языке не так уж и нужна.
На примере своего опыта разработки и перевода проектов на PHP на UTF-8, скажу это не так. В Пайтоне, где таких проблем нет, работать гораздо проще и приятнее.
То, что в PHP приходится для поддержки Юникода работать с UTF-8, а не с UTF-32 сильно снижает производительность всех строковых операций. И добро бы, если бы для всех функций были юникодные аналоги, так это ведь не так.
Работать в PHP с UTF-32 нельзя, если вы собираетесь использовать регулярные выражения: библиотека PCRE, предназначенная для работы с регулярными выражениями, понимает только две кодировки: latin-1 (по всей видимости) и UTF-8. Кроме того, функции, использующие локаль или ICU так же работают только с UTF-8.
Если бы этот язык нативно поддерживал UTF-32… Мечты-мечты.
Комментарии 15
Я хотел сказать вот что — раньше был явно интерес к PHP6 со стороны нескольких компаний. Одна из них — Yahoo и Андрей Змиевский над ним плотно работал.
Потом Андрей сменил работу и (естественно) перестал тратить большую часть своего рабочего времени на PHP6.
Но это частный случай. Общая ситуация (на мой субъективный взгляд такова) — разработка PHP6 затормозилась в первую очередь потому, что в PHP уже есть mbstring, который при всех свой недостатках, решает 90% задач со строками в Unicode/и др. А остальные 10% задач требуют существенной переделки ВСЕГО кода.
При этом для работы со строками в PHP6 (кстати, не факт, что номер версии будет именно такой) используется ICU, которая тоже есть универсальное решение сферической задачи в вакууме, а оттого не блещет скоростью. Т.е. PHP6 за счет работы с юникодом потеряет еще N% производительности (а кому это надо?).
«мы говорим PHP6, а подразумеваем Unicode» ©
Есть библиотека, которая с космической скоростью перекодирует из
Сделать на её базе перекодировку из
Вкратце:
Таким образом, длина символа в строке не всегда два байта. Это значит, что длину строки
а не проще начать подымать новый апи для таких мегастрочек параллельно с тем что уже есть не трогая староег-но.
пусть будет и то и то. пусть будет класс типа string как в java с регекспами внутри + системные классы для обработки?
кому надо полностью переползут на этот новый пи. старье будет какоето время на старом API жить.
Просто ИМХО глупо и дорого получается заставлять текущий апи работать по новому, да так чтобы выглядело в коде «по старому» и не было геммороя :)
Ровно это сейчас и делается. Я же написал.