Как переписать PHP движок с Windows-1251 на UTF-8?

Question

[ua30]

Добрый день!

Есть немаленький, старый движок. Чистый код весит около 3 Мб. Около полугода назад успешно перенес его с PHP 5.3 на версию 7.1 - документации по этому делу много. Изучил рекомендации 4-5 хороших статей. И то была пара моментов, которые не были там описаны. В принципе, все прошло достаточно гладко.

Теперь стоит другая задача. Движок настолько старый, что работает с кодировкой Windows-1251. Нужно переделать все под UTF-8. Сколько не искал - ничего толкового из советов не нашел. Большинство хорошей инфы идет из-за бугра, а для них Win-1251 не актуальна. :)

По сути единственное, что опишут - это заменить все функции работы со строками на их "mb_" аналоги. Я так понимаю, речь идет об этом списке аналогов: php.net/manual/ru/ref.mbstring.php ?

Насколько я понимаю, по части PHP нужно будет еще как минимум задать нужную кодировку в конфиге. Перекодировать сами PHP файлы в UTF-8. БД - то уже отдельные пляски. Еще из нюансов - на сайте есть AJAX, с перекодировкой результатов (т.к. такие запросы, если не ошибаюсь, отправляются только в UTF-8).

Все, этого достаточно? Что еще может быть, у кого есть опыт в подобном деле? И самое главное - нельзя ли просто в настройках PHP указать что "работаем с UTF-8" и точка. Чтобы не менять все функции?

Да и по самим функциям непоняточки. Например, есть preg_replace, но нет mb_preg_replace. Хотя в то же время есть и ereg_replace, и в то же время mb_ereg_replace. Хоть ereg_replace уже устаревшая / удаленная (в зависимости от версии PHP) функция. Как это понимать?

Запутался в конец.

2019.03.07 обновляю: узнал за эти дни много нового и интересного. :) думаю, многие очень поверхностно относятся к пониманию кодировок. Не знаю, актуальна ли тема на 2019 год. Но если что, в принципе, после всего этого могу сделать большой чек-лист что и как надо делать. Третий день переделываю движок под UTF-8. Реально исправлять код действительно не во многих местах надо. Но точек проверок очень много.

А теперь маленький вопрос-уточнение к знающим людям. Везде про preg_* функции пишут в стиле "используйте модификатор u чтобы работать с юникодом". А когда он реально необходим? По моим наблюдениям, функциям все равно со строками в каких кодировках работать. В PHP отношение ко строкам как к набору байт, а не символов. И походу модификатор u необходимо использовать только когда само регулярное выражение содержит символы за пределами US-ASCII. В противном случае любые UTF-8 строки корректно обрабатываются без модификатора u. Что скажите?

Comments

[neol]

Например, есть preg_replace, но нет mb_preg_replace.

Для preg_replace есть модификатор u (PCRE_UTF8)
php.net/manual/ru/reference.pcre.pattern.modifiers.php

[ua30]

neol, спасибо! Жесть, и вот как узнать все эти подводные камни? Неужели нет никакого чек-листа по подобному делу? Ведь раньше Win-1251 была очень распространенной кодировкой для русскоязычных сайтов.

[Дмитрий]

Проблем по сути не много должно случится, сами файлы пересохранить думаю не проблема. Загоните все под git и ковыряйте. Проблемы в основном с выводом. Базу тоже переделать. Ну а там уже по мере поступления проблем чинить
Если используется шаблонизатор, то беды меньше

[ua30]

Дмитрий, там не используется шаблонизатор, там используются разнообразные дикие костыли. :)

[sim3x]

Движ должен иметь ценность для вложения в него времени

там не используется шаблонизатор

выкинте его и перепишите на любом нормальном и современном движке

[ua30]

sim3x, к сожалению, это практически невозможно. Долго и жутко дорого.

[sim3x]

ua30, дешевле чем без тестов рефакторить УГ

Answer 1

[Северное Сияние]

Я так понимаю, речь идет об этом списке аналогов: php.net/manual/ru/ref.mbstring.php ?

Да. Плюс, возможно, придется искать еще и самописные аналоги, которых еще нет в самом php. Я когда свой двиг переписывал, то мне понадобилось лишь 3 функции-аналога найти.

Насколько я понимаю, по части PHP нужно будет еще как минимум задать нужную кодировку в конфиге.

У меня в htaccess вот это:

# Кодировки
php_value mbstring.language "Russian"
php_value mbstring.internal_encoding "UTF-8"
php_value default_charset utf-8

AddDefaultCharset utf-8

БД - то уже отдельные пляски

Конвертируем и при подключении к базе задаем mysqli->set_charset('utf8').

Еще из нюансов - на сайте есть AJAX, с перекодировкой результатов

да, убрать перекодировку, оставить лишь заголовок 'application/json; charset=utf-8' и сделать просто json_encode.

Например, есть preg_replace, но нет mb_preg_replace.

там есть модификатор /u

Вот статья - https://webonrails.ru/post/143646653415428599/

Comments

[ua30]

Спасибо большое за ссылку. Самое толковое из того что видел. Хоть и 2012 года.

Настораживает "Не работает доступ к символу в строке: $srt[0]" - это теперь весь код надо перепроверить на квадратные скобки? Неделя рутины из-за такой чепухи. Вот только вообще не пойму, почему автор советует использовать для этого mb_strcut, разве не mb_substr нужно?

[Северное Сияние]

ua30, два совета:

1. Начать все переделывать и решать проблемы по мере их поступления.

Настораживает "Не работает доступ к символу в строке: $srt[0]" - это теперь весь код надо перепроверить на квадратные скобки?

2. Немного подтянуть теорию. На тебе мою тему 4 летней давности, когда я задался этим вопросом. Можно читать с этого места.

Вот только вообще не пойму, почему автор советует использовать для этого mb_strcut, разве не mb_substr нужно?

автор ошибся видимо. Если ходить по строке, то да - mb_substr.

Ты очень как-то боязливо относишься к вопросу перехода на utf. Там нет ничего сложного, просто немного рутины.

[ua30]

php666, да, боязливо. Во-первых, никогда такого не делал. В-нулевых, переносить надо движок работающего интернет-магазина. И времени мало. Конечно, сперва обкатаю все на локалхосте. Но все заранее не протестишь.

Спасибо за советы и ссылки.

[ua30]

Начал проходить по списку функций. На данный момент дошел до explode. Немного застрял на нем. В мануале ничего на unicode нет по нему. Я так понял, он работает с UTF-8? Делал тесты с кириллической строкой, и с кириллическим разделителем - все ок. Конец строки "\r\n" для разбиения заголовков писем UTF-8 вроде так же без проблем проходит.

Есть известные подводные камни с explode при UTF-8?

Answer 2

[metajiji]

Если в рнр файлах есть русские символы - нужно перекодировать из в утф, если есть темплейты, данные в базе, в js файлах и вообще во всех файлах движка - iconv -f 1251 -t utf8 для них. С базой dump/iconv/sed/restore. Дальше больше, настройки веб сервера, чтобы не только meta с кодировкой, которую в шаблонах поправили но ещё и веб сервер(если настроено) отдавал в утф.

Не понимаю причем тут mb_*, тут в другом дело же.

Comments

[metajiji]

Не забываем про Коннект к базе, клиент и сервер могут быть настроены на 1251. Причем клиент может делать прям в коде set names 1251, если там мускл

[ua30]

Перекодировать файлы и базу - самое очевидное и простое. Вопрос больше по коду PHP.

При чем тут mb_* ? Очевидно, что в любом движке будут функции работы со строками. Тот же strlen возвращает не количество символов, а количество байт в строке. Теперь надо не просто заменять strlen на mb_strlen, а вручную просматривать каждый случай его использования, чтобы разобраться что в каждом конкретном случае нам надо: количество символов в строке, или же количество байт (например, для формирования заголовка). И разобраться со всеми другими строковыми функциями. При том, что на некоторые из них нет mb_ аналога.

Я уже молчу про более тонкие нюансы, типа модификатора u для preg_replace или невозможности получить доступ к символу строки через $str[0] или $str{0}.

Именно совокупность всех таких чекпоинтов и интересует.