1

Тема: UTF8 vs preg_match_all для i18n

Суть проблемы:
Для перевода админки сделал sf_admin.ru.xml файлик, туда перевод нужный мне нужных мне сообщений и всё бы хорошо, но на сервере help'ер Симфони, который как раз занимается переводом сбоит..... начал разбираться, оказалось, что внутри этого хелпера (где-то глубоко-глубоко) переведенная строка парсится с использованием preg_match_all и флага PREG_OFFSET_CAPTURE (для получения смещения нужной позиции относительно начала переведенной строки).
Но вот в чём беда: preg_match_all для того шаблона, что используется в строке (без модификатора /u) смещение выдает В БАЙТАХ.... и благополучно падает, т. к. при настройке utf на сервере все остальные функции (substr, strlen) работают именно с символами, а не байтами, т. е. работают правильно.

Собственно вопрос: неужели никто с этим не сталкивался? Просто менять что-то в коде хелпера не хотелось бы, может есть какие-то настройки (сервера/проекта), которые заставят preg_match_all нормально понимать utf-строки, или может sf_admin.ru.xml сделать в 1 байтной кодировке (мне кажется это в корне не правильное решение)?

2

Re: UTF8 vs preg_match_all для i18n

Ты по-моему сам написал ответ на свой вопрос

.... и благополучно падает, т. к. при настройке utf на сервере все остальные функции (substr, strlen) работают именно с символами, а не байтами, т. е. работают правильно.

т.е. данная проблема возникает именно из-за того, что сервер настроен не совсем корректно, так как одни функции работают правильно, а остальные "падают"

сама по себе кодировка UTF потому и используется по дефолту всеми функциями, так как  любые операции с ней выполняются правильно.

3

Re: UTF8 vs preg_match_all для i18n

mb_internal_encoding('UTF-8');
setlocale(LC_ALL, 'ru_RU.UTF-8');
mb_regex_encoding('UTF-8');

в начало index.php default/cool сразу после <?php