понедельник, 1 октября 2012 г.

PHP - 10 лет - одна печаль.

Прошло уже 10 лет с тех пор как я начал пользоваться языком PHP, с тех времен много воды утекло, пишу уже частенько на других языках, но есть и старые проекты.
Понадобилось старый проект перенести на юникод в связи с переносом на linux. Короче начался пипец.

1. База сконвертирована в UTF-8 довольно просто и быстро, единственно отдельно пришлось обрабатывать таблицу с бинарными данными, но это мелочи.
2. Файлы PHP и прочее были быстро переведены в UTF-8 и почищены от \r. iconv и perl тут как бы все сделали.
3. Началось безобразие:
  • при обращении к строке по [] естественно отдавался первый байт маркера юникода. пездец приехали... с чего баня то упала? при том что сам интерпретатор работает прекрасно с UTF8 файлами.
  • ну и прочее... strlen и далее... короче все встало колом.
И если функции strlen и прочие можно завернуть через mbstring.func_overload то остальное, как например ucfirst и далее просто пездец
Благо сайт был более менее по божески написан и я смог все завернуть через родные mb_* функции и все заработало. но было убито полсмены.

Из найденного.

ucwords, strtolower,strtoupper - > mb_convert_case
ucfirst -> самопал, ибо нет стандартного
[*] -> самопал
serialize<->unserialize - тоже костыль, ибо мне непонятно нахера в строке считать байты, если строка юникодовая.для бинарных данных я все понимаю, но если это обычная строка???.
preg_* - модификатор u + \w (только английские)  [а-я] - русские ну или класс \p{L} - для тупо буквы.(если нужны цифры то \d)

Короче 10 лет, и никакого сдвига в лучшую сторону.

Вопрос разработчикам: Если внутренняя кодировка UTF-8 (так как сами файлы UTF-8), что за бред использовать для работы со строками стороннее расширение?

Короче вывод. Если вы собрались писать нормальное юникод приложение, то не связывайтесь с PHP. он застыл на этапе 2002 года, а вернее на версии 4.2 + немного классов из 5.
Мое мнение. Нужно бросать что есть и разрабатывать с ноля чистую адекватную версию, потому что поддерживая старое говно расти дальше некуда.

Microsoft смог вовремя отказаться от 1 фреймворка, просчитал ошибки и выстроил замечательный второй (до сих пор не измененный сильно в основе), который не поддерживал старое говно... Здесь необходим такой же путь. Эволюция ни к чему не приведет. Только к латанию одних и тех же дыр от года к году.