Судьба PHP6

Поговорил с одним из разработчиков PHP по поводу судьбы PHP6, самое ожидаемое изменение которого — переход на юникодные строки. Так вот Антон Довгаль рассказал, что проект, по сути, заброшен. Те несколько человек, которые занимались проектом, либо уволились, либо потеряли к нему интерес и сейчас считается, что поддержка юникодных строк в языке не так уж и нужна.

На примере своего опыта разработки и перевода проектов на PHP на UTF-8, скажу это не так. В Пайтоне, где таких проблем нет, работать гораздо проще и приятнее.

То, что в PHP приходится для поддержки Юникода работать с UTF-8, а не с UTF-32 сильно снижает производительность всех строковых операций. И добро бы, если бы для всех функций были юникодные аналоги, так это ведь не так.

Работать в PHP с UTF-32 нельзя, если вы собираетесь использовать регулярные выражения: библиотека PCRE, предназначенная для работы с регулярными выражениями, понимает только две кодировки: latin-1 (по всей видимости) и UTF-8. Кроме того, функции, использующие локаль или ICU так же работают только с UTF-8.

Если бы этот язык нативно поддерживал UTF-32… Мечты-мечты.

Поделиться
Отправить
 27   2010   php   utf8   программирование
15 комментариев
tony2001 2010

Ну, я не совсем то говорил.
Я хотел сказать вот что — раньше был явно интерес к PHP6 со стороны нескольких компаний. Одна из них — Yahoo и Андрей Змиевский над ним плотно работал.
Потом Андрей сменил работу и (естественно) перестал тратить большую часть своего рабочего времени на PHP6.
Но это частный случай. Общая ситуация (на мой субъективный взгляд такова) — разработка PHP6 затормозилась в первую очередь потому, что в PHP уже есть mbstring, который при всех свой недостатках, решает 90% задач со строками в Unicode/и др. А остальные 10% задач требуют существенной переделки ВСЕГО кода.
При этом для работы со строками в PHP6 (кстати, не факт, что номер версии будет именно такой) используется ICU, которая тоже есть универсальное решение сферической задачи в вакууме, а оттого не блещет скоростью. Т. е. PHP6 за счет работы с юникодом потеряет еще N% производительности (а кому это надо?).

Евгений Степанищев (bolknote.ru) 2010

Комментарий для tony2001:

Тем не менее, переход на массивы-классы выполняется (ArrayObject), а со строками такого движения не видно, хотя это был бы выход. Создать UnicodeString и тянуть в него методы для работы с Unicode, а кроме того, научить PCRE работать с такими строками. Уже было бы большое дело.

Victor Grinchik (wiktar.com) 2010

PHP6 заброшен или поддержка юникода в нём?

tony2001 2010

Комментарий для wiktar.com:

PHP6 == PHP + Unicode
«мы говорим PHP6, а подразумеваем Unicode» (c)

Евгений Степанищев (bolknote.ru) 2010

Комментарий для tony2001:

Есть библиотека, которая с космической скоростью перекодирует из UTF-8 в UTF-16 с огромной скоростью: http://u8u16.costar.sfu.ca/

Сделать на её базе перекодировку из UTF-32 в UTF-8 и засунуть в класс UnicodeString, чтобы отдавать наружу UTF-8 по запросу.

tony2001 2010

опять же, напрашивается отдельный экстеншен, т. к. это решение не универсальное =/

ExH (exh.myopenid.com) 2010

А почему UTF-32, а не UTF-16?

Евгений Степанищев (bolknote.ru) 2010

Комментарий для exh.myopenid.com:

С UTF-16 неудобно работать.

Вкратце: UTF-16 — это 16 бит на символ с некоторыми исключениями (об этом дальше). В 16 бит помещается 65535 символов, а в Unicode их намного больше, как же кодировать остальные. Они кодируются так называемыми «суррогатными парами», часть кодов в UTF-16 имеют специальное значение, если они встречаются в строке, значит за ними идёт ещё символ.

Таким образом, длина символа в строке не всегда два байта. Это значит, что длину строки UTF-16 нельзя получить делением её байтовой длины пополам, нельзя адресоваться к символу, умножив смещение на 2 и так далее.

Евгений Степанищев (bolknote.ru) 2010

Комментарий для exh.myopenid.com:

Немного ошибся, значений в 16 битах 65536.

hshhhhh.name 2010

я крайне сильно жду что в пхп6 приведут названия функций и порядок аргументов к одному виду. но это, похоже, без вариантов.

Евгений Степанищев (bolknote.ru) 2010

Комментарий для hshhhhh.name:

Варианты есть и туда PHP активно движется. Например, уже сейчас есть класс ArrayObject с нормальными методами, все названия camel case.

анонимус 2010

пхп6 приведут названия функций и порядок аргументов к одному виду

а не проще начать подымать новый апи для таких мегастрочек параллельно с тем что уже есть не трогая старое г-но.
пусть будет и то и то. пусть будет класс типа string как в java с регекспами внутри + системные классы для обработки?

кому надо полностью переползут на этот новый пи. старье будет какоето время на старом API жить.

Просто ИМХО глупо и дорого получается заставлять текущий апи работать по новому, да так чтобы выглядело в коде «по старому» и не было геммороя :)

Евгений Степанищев (bolknote.ru) 2010

Комментарий для анонимус:

пусть будет и то и то. пусть будет класс типа string как в java с регекспами внутри + системные классы для обработки?

Ровно это сейчас и делается. Я же написал.

den_rad (den-rad.ya.ru) 2010

Спасибо за информацию. Скорее я мигрирую на Python/Ruby, чем нормальный юникод появится в php

Евгений Степанищев (bolknote.ru) 2010

Комментарий для den-rad.ya.ru:

Я уже больше пишу на Python и Powershell, чем на PHP.

Популярное