UTF-8 в PHP спустя 3 года - помогите разобраться

webikdddorf

Новичок
В моём вопросе пойдёт речь о нативной поддержке UTF-8 в PHP. Ситуация такая - несколько лет подряд я плотно работал с PHP и года 3 назад пришлось податься в мир Java, т.е. я выпал из мира PHP целиком и полностью. Когда я расставался с PHP ситуация в мире была следующей:

- все ждали PHP 6 и наконец-то нативную поддержку UTF-8
- на сайте PHP висела страница со списком всех функций php поддерживающих юникод и процентом общей готовности (если не ошибаюсь то процент готовности составлял 89%)

Позже я внезапно прочел в новостях три вещи:

- PHP 6 не будет, разработчики лоханулись и сделали поддержку UTF-16 вместо UTF-8, пришли к выводу что это лажа и всю разработку начали сначала (http://habrahabr.ru/post/138269/)
- с сайта PHP исчезла та самая страница с процентом готовности PHP работать с юникодом
- некоторые сайты написали о том что UTF-8 в PHP не будет уже никогда, нужно юзать mb_

С тех пор я забыл о PHP и не интересовался новостями, потом примерно 2-3 года работал с Java днём и занимался подработкой по вечерам (вёрсткой в open server). И вот сейчас я снова начинаю работать с PHP и прошу помочь мне влиться в мир пользователей этого прекрасного языка :) Прошу не отвечать односложно да/нет, хотелось бы получить развернутые ответы "как" "что" и "почему".

Мои вопросы сообществу:

1) Изменилось ли за 3 года ситуация с нативной поддержкой utf-8 в php (сейчас смотрю уже версия 5.5)?
2) Если поддержка появилась, то полная ли она, все ли функции поддерживают юникод или есть какие-то подводные камни.
3) Если поддержки нет (про mb_ и так понятно, умею пользоваться), то как обстоят дела с планами разработчиков на будущее? Может кто-то в курсе? Будет ли поддержка или не будет.

В общем хочется узнать как сейчас работают с юникодом в PHP.
 

fixxxer

К.О.
Партнер клуба
нет и не будет. И хорошо, что не будет, лучше всегда иметь char[], чем бардак с двумя "строковыми" типами данных. Единственный же разумный вариант "все строки - строго в utf8, а то, что было строками - новый тип данных ByteArray" исключается по соображениям bc.

mb_*

Java и деривативы, кстати, наверное, единственные популярные языки, где с юникодом разумно by design.

Впрочем, стоит заметить, что абсолютно никаких неудобств с тем, что строки - это char[], нет.
 
Последнее редактирование:
  • Like
Реакции: Gas

riff

Новичок
А у тебе прям очень-очень нужна работа со строками?
А так ситуация (у меня) простая: всё в утф, а что-либо делать со строками нет необходимости.
Поиск в базе, вставки, выборки, и т.п. это само собой и для этого не нужны mb_*, я имею ввиду разбирать строку в скрипте нет необходимости.
(Естественно, всякие там шаблоны посреди текста парсить приходится, но шаблон пишется латинскими буквами, а с ним проблем нет).
Я не помню когда последний раз использовал mb_*. С preg_* тоже нет проблем, для него есть модификатор: ("~[абвгд]~u").
 
Последнее редактирование:

webikdddorf

Новичок
Спасибо за ответы. Да... жаль конечно что так всё печально. Будем ждать поддержку utf-8 в 203x году, а пока mb_*...
 

fixxxer

К.О.
Партнер клуба
Да как будто часто со строками что-то делаешь напрямую. В современных фреймворках тут будет все либо в template engine, либо в валидаторах типа MaxLength.

Кстати, если уж вводить unicode string, то я горячо поддерживаю именно utf-16. Аргумент железный: в случае ошибочного использования не того типа американец с его буковками в utf-16 увидит все свое дерьмо в консоли или браузере, а с utf-8 вообще ничего не заметит.
 
Сверху