Несмотря на то, что поддержка UTF8 появилась в продукте давно, остаются много проектов, сделанных на старой версии в cp1251. Теоретически сделать конвертацию не сложно, однако могут возникнуть трудности. Сразу оговорюсь, что данный пост не претендует на статус официального документа, это должно быть хорошее подспорье по проблеме.
[spoiler]
Подготовка
Для работы сайта на битрикс в utf8 абсолютно необходимо наличие модуля mbstring в php (это есть почти на любом хостинге) и установка параметра
mbstring.func_overload 2
С этим может быть проблема т.к. с версии php 5.2.8 параметр меняется глобально на весь сервер (http://bugs.php.net/bug.php?id=47187). Уточните вопрос у хостера, но будьте осторожны если вам предложат CGI (см. "как выбрать хостера").
На VPS/выделенном сервере параметр без проблем меняется в php.ini.
Обязательно сделайте резервную копию работающего сайта, а лучше именно на копии проводите эксперименты. Если что-то пойдёт не так - вы можете потерять данные!
Выйти и зайти на сайт чтобы обновить данные сессии
Практическая сторона вопроса
После смены кодировки сайта публичная часть принимает вид:
Это нормально, браузер пытается показать данные не в той кодировке. Теперь после всех действий внешний вид восстановится, и мы увидим, что процесс прошёл успешно.
Большое число файлов надо конвертировать по шагам, для этого буду использовать наработки для поиска вирусов. По большому счёту, тут надо только переделать функцию замены в конвертацию через mb_convert_encoding.
Примечание. Часто при использовании внешних программ для конвертации в файлы добавляется специальная последовательность символов, т.н. BOM. Эти символы должны находиться только вначале файла, а поскольку итоговая html страница является составной из нескольких php файлов, то спецсимволы появляются в теле html страницы. Если делаете вручную - не сохраняйте с BOM!
Для конвертации базы надо сменить кодировку базы, всех таблиц и всех текстовых полей таблиц. Вручную это тоже делать не очень удобно. Решил сделать конвертацию файлов и базы в одном скрипте.
Скрипт выполняет операции:
- Конвертировать все файлы в utf8 - Конвертировать БД в utf8
Остальное следует делать вручную по списку в том порядке, как написано.
Есть ещё одна потенциальная проблема, с которой автор не столкнулся: кодировка дампа не обязательно будет cp1251. Она будет соответствовать кодировке клиента, которым делали дамп.
Если бы не ваш комментарий, я бы не догадался проверить параметры сервера. Три дня бились с кодировкой после конвертации скриптом, часть данных отображалась в UTF, часть - в 1251. Пока не посмотрели настройки сервака. А там было character_set_server | latin1 character_set_system | utf8 collation_server | latin1_swedish_ci
Единственное, не работает при загруженном словаре нецензурных слов для форума... Ругается на дублирующиеся записи с символами "ё" в таблице b_forum_letter.
После удаления одной из строк с "ё" все прошло успешно.
У меня на 3-м шаге, конвертация БД, вышла такая ошибка: MySQL Query Error: ALTER TABLE `b_search_content` MODIFY `ITEM_ID` varchar(255) CHARACTER SET utf8 [Specified key was too long; max key length is 1000 bytes]
Квест по отделу разработки позволил найти следующую информацию:
Список функций, запрещенных к использованию в продукте по причине полной негодности к использованию в UTF версии (высокий риск). На данный момент эти функции не используются. Если вдруг понадобится, то стоит сначала поискать "обходные" пути. Если таких не будет, тогда обсудим возможность исключения. Все эти функции включены в проверку update_check.php
* str_ireplace * stripos * strripos
Небольшое дополнение. Поведение функций serialize и unserialize немного меняется при работе с UTF-строками. Обратная совместимость поддерживается, поэтому при обычном использовании проблем быть не должно. Проблемы могут появиться если:
* вы по каким-либо причинам собираете сериализованный массив вручную * сериализованный массив пришел из не-UTF источника
Поведение функций serialize и unserialize немного меняется при работе с UTF-строками. Обратная совместимость поддерживается, поэтому при обычном использовании проблем быть не должно. Проблемы могут появиться если:
* вы по каким-либо причинам собираете сериализованный массив вручную * сериализованный массив пришел из не-UTF источника
Второй пункт приводит к проблеме при наличии на исходном сайте значений для свойств инфоблока типа "html/текст". Т.к. serialize делался на win-1251, а unserialize выполняется на utf-8, получается несовпадение, и на сайте значения не отображаются
Ещё из замеченных проблем: Не перевелся в utf8 файл /bitrix/modules/search/tools/ru/stemming.php, что привело к неработоспособности поиска (на любой запрос выдается сообщение о пустой строке запроса). Не перевелись в utf8 шаблоны сайта.
У меня 2 часа простоял на 3 шаге, на таблице b_iblock_element, я закрыл страницу. Теперь у меня подозрение что таблицы идущие за b_iblock_element не с конвертировались, как проверить? Как обойти данную неприятность?
По всей видимости, у вас в БД очень много элементов инфоблоков. Был отправлен запрос на конвертацию данных, но сам скрипт был блокирован по времени. Если вы не рестартовали БД - этот запрос выполнился, соотв. процесс прервался на данной таблице. Попробуйте снова с третьего шага, запустите скрипт с параметром
В общем в таблице около 22тыс. записей и время работы скрипта непозволительно большое, пришлось основной каталог выгружать и конвертировать базу без него..
Скрипт сам не делает конвертацию, последовательно отправляются запросы в базу на конвертацию всех полей таблиц. Вероятно, у вас медленно работает база данных. Если это хостинг - можно перенести сайт на локальную машину и там выполнить конвертацию.
Да нет оценка скорости работы в модуле производительности выше эталонной. Почему так долго для меня загадка, но как я и сказал убрав главный каталог все прошло гладко. Спасибо за участие.
Почему-то у меня при конвертации файлов скриптом, буквально через 5 секунд всё прекращается - белый экран.
И при запуске скрипта (причем только в IE) уже выводится страничка с просьбой авторизоваться. Но даже ввод пароля ничего не решает. Всё-равно через 5 секунд белый экран.
Можно без дополнительных скриптов. Поскольку iconv не умеет конвертировать на месте, скопировать во временную папку, предварительно создав структуру каталогов, затем скопировать назад. Переходим в папку, где надо сделать конвертацию, затем 4 команды:
rm -r /tmp/111 mkdir /tmp/1 # временная папка find -type d -exec mkdir /tmp/111/{} # создание пустой структуры каталогов find -name '*.php' -exec iconv -fcp1251 -tutf8 {} -o /tmp/111/{} \; # конвертация cp -fr /tmp/111/* . # копирование назад
А базу я бы рекомендовал конвертировать средствами базы, как это делает скрипт convert_utf8.php.
Спасибо за рецепт, очень помогло. Но есть один минус. У меня табличка b_sale_basket 181.5 МБ, ну соответственно скрипт не успевает ее обрабатывать и на ней зацикливается.
Скрипт отправляет запрос на конвертацию в базу. Даже если скрипт прервал работу - запрос должен выполниться (кроме случаев когда тяжёлые запросы отстреливаются на хостинге). Если повторно запустить скрипт конвертации с шага конвертации базы - всё должно пройти нормально: convert_utf8.php?step=3
А вообще, размер этой таблицы можно регулировать параметром настройки модуля магазина: "Сохранять корзину (дней)".
А подскажите вот такую вещь. На сайте несколько языков, и стоит испанский язык для панели управления (файлы испанского языка соответственно в сp-1252). Собственно из-за этого и собираемся переходить на utf, поскольку остальная-то страница в cp-1251. Как свести к единому формату всю эту куралесицу?
function Process($file)
{
global $STEP;
$charset = 'cp1251';
if (strpos($file,'/lang/es/') !== false)
$charset = 'cp1252';
if ($STEP == 1)
{
if (!is_writable($file))
Error('Файл не доступен на запись: '.$file);
}
elseif ($STEP == 2)
{
$content = file_get_contents($file);
if ($content === false)
Error('Не удалось прочитать файл: '.$file);
if (file_put_contents($file, mb_convert_encoding($content, 'utf8', $charset)) === false)
Error('Не удалось сохранить файл: '.$file);
}
}
Здесь es надо заменить на идентификатор испанского языка. Добавив условия можно несколько языков привести к utf8.
Денис, я правильно понял, что конвертируются только php файлы? А как же, например, js файлы, в которых есть такие штуки, как Аяксовое окошечко "Загрузка..." и другие сообщения?
Сразу оговорюсь, что с Битриксом знаком два дня. Прерыдущий админ оставил достаточно кривое наследие и я вынужден был доделывать то, что совсем криво висит. На сайте кодировка отображалась совершенно некорректно, видимо кто-то начал конвертить в utf8 но либо безуспешно, либо не до конца. Я попробовал сделать это окончатально, согласно доходчивым инструкциям (за что огромное спасибо ) Но в итоге у меня часть информации отображается крокозябрами, а панель управления на русском вообще нечитабельна. Подскажите куда копать, а то я чет совсем не догоняю....
Это нормально, что скрипт изучает все файлы сайта?? и даже жепеги? такого рода строки
Идёт обработка... Текущий файл: /var/www/planeta/data/www/tvplaneta.ru/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/tvplaneta/www/www/www/forum/uploads/monthly_10_2008/post-2042-1223616188.jpg
явление нормальное??? смущает большое количисество www
Денис а не подскажите у вас не было такой проблемы что после конвертации перестал работать поиск стал выдавать что В поисковой фразе обнаружена ошибка:
Пустой поисковый запрос (запрос не содержит букв или цифр).
Вчера сконвертировали сайт в UTF 8. Все по инструкции. Все получилось. НО! С поиском проблемы, указанные выше. Переустановка модуля не помогла. Денис, может на сегодняшний день уже есть решение?
Выяснил, оказывается, надо было конвертировать файлы из папки /bitrix/modules/search/tools/ru/Исправил ошибку в исходном скрипте, теперь надо восстановить сайт из резервной копии и повторить процедуру снова.
Либо вручную сконвертировать файлы указанной папки.
2. У меня возникла следующая проблема. При перекодировании базы, возникла проблема на табличке b_forum_letter, а именно: MySQL Query Error: ALTER TABLE `b_forum_letter` MODIFY `LETTER` varchar(50) CHARACTER SET utf8 [Duplicate entry '2-Рµ' for key 'LETTER_NEW']
Ключи совпадают у следующих записей: INSERT INTO `b_forum_letter` (`ID`, `DICTIONARY_ID`, `LETTER`, `REPLACEMENT`) VALUES (25, 2, 'ё', 'ЁёЕеEe, [Йй]+[Оо]+'), (24, 2, 'е', 'ЁёЕеEe');
Причина собственно известна: http://bugs.mysql.com/bug.php?id=34096 Кто нибудь сталкивался с этой проблемой, или может быть знает как решить? Удалять без лишней необходимости ключ не хочется. Да и форум станет работать не правильно.
Вообще хотелось бы узнать что об этом думает тех поддержка. Которая в свое время распиналась что мол продукт поддерживает UTF-8! Покупайте!!!
Сделал это для сайта с многосайтовой конфигурацией 2 сайта в конфе были на утф новый сайт поставили нам в 1251 решил перекодировать этим скриптом. Сломал вообще все) базу хорошо не перекодировал, есть какие нибудь мысли как востановить? только полной заменой?
Создали копию сайта тут http://weber.tmweb.ru/rus/ Выполнили все рекомендации но ничего не помогло. Администраторы хостинга только на одной странице помогли исправить командой iconv -f cp1251 -t utf8 index.php > index_1.php А как исправить на всем сайте (панель управления, меню, шаблоны и пр.)?
В админке в визуальном редакторе некоторые кнопочки пишутся кракозябрами, например в правой панели надпись "Компоненты 2" (а также и другие) Как это поправить? Я мог бы поправить вручную но подскажите куда лезть??
После перекодировки ВСЕ русскоязычные надписи в админке отображаются абракадаброй. В чем может быть дело? Т.е. всё, что выводится из базы на сайт, всё, что файлах - нормально. шаблоны - нет (но это ясно - вы про это уже написали) - но вот с админкой что может быть?
Простите, что поднимаю старую тему, но для кого-то может быть полезным После конвертации обязательно необходимо сменить кодировку в настройках языков интерфейса, иначе в админке будет абракадабра
Здравствуйте. При конвертации БД значения по умолчанию для строковых типов полей сбрасываются в NULL, т.е. убиваются значения по умолчанию для полей которые переводятся из cp1251 в utf8. Никто не сталкивался с этим, это моя проблема или так работает скрипт? P.S. MySQL 5.1.56
проверил на другом сервере почти с такой же конфигурацией и версией БД. все же проблема есть. немного переделал запросы в строке 94, у меня получилось:
$q = 'ALTER TABLE `'.$table.'` MODIFY `'.$f0['Field'].'` '.$f0['Type'].' CHARACTER SET utf8 COLLATE utf8_general_ci'.($f0['Null']=='YES' ? ' NULL':' NOT NULL').($f0['Default'] === NULL ? '':' DEFAULT '.'\''.($DB->ForSql($f0['Default']).'\''));
теперь у меня вроде нормально начал работать скрипт на моей версии БД, но не факт что он правильно описывает все возможные комбинации значений Null и Default, буду благодарен если укажите на ошибки в этом варианте запроса.
Полезная тема, попробую . Прошлый опыт переконвертирования сводился к тому, что я скачал программку для перевода файлов в каталоге в UTF8, притом вроде бы без BOM, а то левые символы вылезали, а базу переконвертил с помощью notepad++
Скрипт возвращает ошибку: База данных работает в кодировке, отличной от cp1251 (значение: utf8) Но таблицы в базе данных 100% в cp1251, конвертирую базу после перехода на VM Bitrix где может быть проблема?
Единственная (надеюсь) проблема - перестал нормально работать поиск. Заглянул в базу данных и обратил внимание, что в таблице b_iblock_element не заполняется поле searchable_content, в него попадает только фрагмент заголовка элемента и все , тогда как раньше оно заполнялось по
Не перевел названия обработчиков в настройках платёжных систем.. Магазин -> Настройки магазина -> Платёжные системы, выбираем на редактирование какую-нибудь, и в выпадающем списке поля "Обработчик" видим казяблики(
Денис, после конвертации описанным выше способом ДЕМО-версии продукта из cp1251 в utf-8 (после третьего шага) система пишет, что срок демо-версии истек, хотя установлена она 30 мин. назад. Это нормальное явление?
Денис, а если для сайта в интерфейсе Битрикс можно выбрать кодировку, то получается, что один сайт может быть в utf-8, а другой в windows-1251? Тогда, получается, они должны использовать разные БД?
На одной установке все сайты должны быть либо в utf8, либо в windows-1251. Иначе нельзя. Если требуется для одного из сайтов utf-8 - надо все сайты сконвертировать в utf-8.
А зачем вообще конвертировать сайты в UTF-8? Понятно зачем если сайт многоязычный (один сайт Битрикс может содержать тексты на двух и более языках). Да и экзотика это. Едва ли есть такое на практике (все равно надо определяться с языковой версией компонент, она может быть только одна).
Только Chrome автоматически не определял кодировку, только при указании UTF-8 вручную, сайт отображался правильно. Победил путем добавления в header.php шаблона строки header('Content-Type: text/html; charset=utf-8');
Проблема вылезла позже, в процессе работы.
Решили прикрутить форму авторизации в всплывающем окне. Кастомизировал компонент system.auth.form после переноса в папку шаблона. Всплывающее окно вызывается через fancybox В итоге вижу битую кодировку в попап-форме авторизации. Страница, с которой вызывается попап-форма отображается корректно, а в самой форме кодировка битая. Причем этот глюк виден в Chrome. Проверял в Opera, Firefox - без проблем.
Пока что решения не нашел. Может где-то затаился файл с вин1251-кодировкой. Языковые файлы компонента формы авторизации в utf-8, проверял
Добрый день! Проделал перевод кодировки все шло нормально в конце хотел очистить кеш. Пробую зайти в админ панель мне выдается ошибка типа Fatal error: Unsupported operand types in /home/taukensa/public_html/bitrix/modules/main/classes/general/cache.php on line 822 Подскажите что делать?
Получилось...но почему то когда пытаюсь отредактировать меню сайта и другое все отстальное открывается окошко и там пусто те значения которые есть их не отображает почему то типа пусто совсем
Добрый день! Конвертация прошла нормально. С русским и английским языками все хорошо, а вот символы казахского и турецкого алфавита выводятся ??? (вопросительными знаками). В файлах такой проблемы нет, только из ИБ. Делал запрос "alter database dbname default character set utf8", все равно так же. Что можно, нужно делать?
На Windows-платформе обнаружил проблему: конвертация файлов не идёт дальше первого "захода" (автоматической перезагрузки формы) и рапортует об успехе, когда в реальности сконвертированы не все файлы.
Проблема оказалась в функции dirname, в Windows она использует оба слеша:
dirname('c:/x'); // возвращает 'c:\'
На втором "заходе"
//SKIP_PATH == 'c:/x/folder1/file.php'
//$path == 'c:/x'
//и сразу же срабатывает:
if (0 !== strpos(SKIP_PATH, dirname($path)))
return; //конвертация прекращается и преждевременно считается успешной
Мне помогла замена dirname на аналог:
function winDirname($path) {
return str_replace('\\', '/', dirname($path));
}
Спасибо, Денис! Скрипт реально рабочий И весь алгоритм тоже - 12-ый Битрикс без проблем конвертнулся. Только я бы местами поменял пункты, а то когда кракозябры в админке, тяжко что-то перенастраивать:
``Добавить в /bitrix/php_interface/dbconn.php define("BX_UTF", true);``
и пункты
``Изменить в настройках сайта кодировку с windows-1251 на utf-8`` ``Изменить в настройках языка ru кодировку с windows-1251 на utf-8``
У нас на проекте с БД в 1.5 Гб смена кодировки заняла 24-26 часов. Позже переделали скрипт на работу с php-cli из консоли. В таком режиме работа пошла намного быстрее. Для смены кодировки использовали локальный веб-сервер.
На этапе конвертации БД, вылетело сообщение "Срок работы пробной версии продукта истек. Вы можете купить полнофункциональную версию продукта на сайте www.1c-bitrix.ru. Регистрация." хотя ещё оставалось 17 дней. Всё сайт больше не запускается. =) Сайт сейчас восстановлю, а как со скриптом та быть?
Если кто-нибудь здесь еще есть — подскажите, пожалуйста.
Сделали 3 первых шага подготовки к конвертации: Подготовить сервер как показано выше — Добавить в /bitrix/php_interface/dbconn.php define("BX_UTF", true); — добавили
— Изменить в настройках сайта кодировку с windows-1251 на utf-8 — изменили — Изменить в настройках языка ru кодировку с windows-1251 на utf-8 — изменили
+ остается проблема со свойствами типа html/текст при переносе накидал скрипт на коленке
<?
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");
if($USER->IsAdmin())
{
global $DB;
$r = $DB->Query("SEL ECT ID FR OM b_iblock_property WHERE PROPERTY_TYPE='S'");
while($prop = $r->Fetch())
{
$rV = $DB->Query("SELECT ID,VALUE FR OM b_iblock_element_property WHERE IBLOCK_PROPERTY_ID=".$prop['ID']." AND VALUE IS NOT NULL AND VALUE LIKE 'a:%'");
while($pV = $rV->Fetch())
{
$s_cp1251 = iconv('utf-8','windows-1251',$pV['VALUE']);
$u_cp1251 = unserialize($s_cp1251);
array_walk_recursive($u_cp1251,'c');
$s_utf8 = serialize($u_cp1251);
$updateSql = "UPD ATE b_iblock_element_property SE T VALUE='".$DB->ForSql($s_utf8)."' WH ERE ID=".$pV['ID'];
$DB->Query($updateSql);
}
}
}
function c(&$item, &$key)
{
global $APPLICATION;
$item = $APPLICATION->ConvertCharset($item,'windows-1251','UTF-8');
}
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/footer.php");?>
Подскажите пожалуйста. Ситуация такая. Сделал конвертацию сайта по этому мануалу. Все в принципе заработало. НО! Появилась проблема с выгрузкой из 1с. При попытке выгрузить каталог из 1С в Битрикс сервер отвечает битой кодировкой (не могу прочитать ошибку). Но если загрузить файлы выданные 1С через импорт вручную, то все проходит нормально. В чем может быть проблема? Значения mbstring изменил encoding На UTF-8 и overload На 2.
На основании данного блогпоста Дениса Шаромова, комментариев к нему и личного опыта написал для себя памятку для наиболее быстрого перевода сайта на UTF-8.
1. Сделать резервную копию сайта без сохранения поискового индекса и таблиц статистики.
2. Задать и активизировать значения PHP-параметров:
4. Если был установлен, удалить модуль «Веб-аналитика» без сохранения данных (типы и шаблоны сообщений не удалять).
5. Удалить из «Словаря транслита» (модуль «Форумы») запись 7:
ID
Буква
Аналог
7
ё
ЁёЕеEe, [Йй]+[Оо]+
6. Загрузить в корневую директорию сайта скрипт convert_utf8.php.
7. Изменить в региональных настройках кодировку с windows-1251 на utf-8 (в настройках сайта должна быть выбрана соответствующая региональная настройка, как правило ru).
8. Добавить в /bitrix/php_interface/dbconn.php по sftp:
Здравствуйте! Не могу найти не где в директориях сайта: "12. Установить в /bitrix/.settings.php по sftp:" Как будто такого файла нет... Подскажите пожалуйста, где и как его найти? Заранее спасибо за ответ! И также если не сложно по этому пункту объясните пожалуйста: "2. Задать и активизировать значения PHP-параметров: "
Здравствуйте! Я все перерыл, но нет у меня не где файла .settings.php... Я вручную создал этот файл и положил его в директорию. Скажите имеет ли значение, где прописывать параметры: mbstring.func_overload 2 mbstring.internal_encoding UTF-8 Я прописал их в файле .htaccess расположенного в корне сайта и скрипт перестал на них ругаться. После всех действий из вашей инструкции запустил скрипт convert_utf8.php, он выполнился без ошибок база перешла в utf-8. Но сайт так и остался в квадратах, не сбор кэшей, не разлогин, не помогают. Все проделывал уже в 5 раз и не как ;( Подскажите пожалуйста, в чем моя проблема? Заранее спасибо за ответ!
Денис, огромное Вам спасибо! Много раз видел Вашу статью, но дата публикации смущала. Поэтому делал все руками. После 5 раз неудачных попыток (в целом все конвертировал, но в админке пропадали названия типов инфоблоков и были пустые названия разделов) плюнул и решил попробовать воспользоваться Вашим решением. Каково было мое удивление, когда все переконвертировалось без проблем.
Спасибо! Большое, человеческое спасибо! Впредь буду сразу в utf8 ставить систему
Добрый день. У меня при смене кодировки вылетает окно с тем что истек срок использования продукта. У нас NFR лицензия и там 300+ дней. Как с этим можно разобраться?
Чтобы сменить кодировку для NRF лицензий сделал следующее: 1.Принял соглашение в личном кабинете marketplace - обновление платформы. 2.Далее добавил в /bitrix/php_interface/dbconn.php
define("BX_UTF", true);
3.Изменил в настройках сайта кодировку с windows-1251 на utf-8 4.Далее выполнил скрипт приложенный выше, только выполнял не все действия, выполнил проверку и перекодировал данные сайта. БД не трогал. 5.В новой вкладке зашел в админку для выполнения SQL запроса и выполнил следующее:
SEL ECT CONCAT('ALT ER TABLE `', t.`TABLE_SCHEMA`, '`.`', t.`TABLE_NAME`, '` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;') as
sqlcode
FR OM `information_schema`.`TABLES` t
WHERE 1
AND t.`TABLE_SCHEMA` = 'db_name'
ORDER BY 1
где "db_name" - имя вашей базы данных. Данный запрос выведет строки. Эти строки раскроем, чтобы были на одну страницу, выделим и выполним их как sql запрос. Пример:
ALT ER TABLE `littlebird`.`wp_commentmeta` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALT ER TABLE `littlebird`.`wp_comments` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALT ER TABLE `littlebird`.`wp_links` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALT ER TABLE `littlebird`.`wp_options` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALT ER TABLE `littlebird`.`wp_postmeta` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALT ER TABLE `littlebird`.`wp_posts` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALT ER TABLE `littlebird`.`wp_terms` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALT ER TABLE `littlebird`.`wp_term_relationships` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALT ER TABLE `littlebird`.`wp_term_taxonomy` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALT ER TABLE `littlebird`.`wp_usermeta` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALT ER TABLE `littlebird`.`wp_users` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
После выполнения ваша БД будет в кодировке utf8_general_ci. 6.Сменил в /bitrix/php_interface/after_connect.php
$DB->Query("SET NAMES 'cp1251'");
на
$DB->Query("SET NAMES 'utf8'");
7.Сбросил весь кеш. 8.Вышел и зашел на сайт, чтобы обновить данные сессии.
Добавлю от себя: В настройках Сайта -> Региональные настройки, надо ставить кодировку в правильном написании utf-8 (через дефис), в противном случаи некоторые ваши клиенты (да и сервисы) будут ловить "кракозябыры" - например те кто работает из под internet explorer 9 (IE9 и ниже)
Спасибо за скрипт, он и вправду помогает сберечь время. Но я, признаюсь, несколько ошарашен тем, что никто не столкнулся с проблемой сериализованных массивов в базе. Все сериализованные массивы, хранящиеся в базе и содержащие данные с кириллицей, не смогут быть десериализованы средствами PHP, потому что длины строк, указываемые в виде [ s:XX:"текст" ] для cp1251 и для utf-8 различаются. То есть, что было сериализовано под cp1251 нельзя десериализовать под utf-8.
У меня из-за этого слетели описания 3k+ товаров, хранившиеся в свойствах типа html, а также службы доставки, у которых в конфиге была кириллица (а может ещё что-то, чего я не нашёл). Было бы очень круто, если бы скрипт доработали в части конвертации размеров строк в сериализованных массивах, особенно учитывая, что MySQL'ная функция length возвращает в utf'ной базе именно ту длину, которая нужна.
Однако после успешной конвертации в некоторых инфоблоках перед текстовой информацией появились вот такие строки: a:2:{s:4:"TEXT";s:2202:" и массив текста закрывается этой строкой:
Добрый день. Видимо никто не ответит, опишу ситуацию. Дело в том, что Битрикс хранить данные по крайней мере в дополнительных свойствах, следующим образом:
";s:4:"TYPE";s:4:"html";} <- конце сериализованного массива
В заголовке, а именно во второй букве s где на нашем примере фигурирует цифры 2202 показано точное количество знаков данных в массиве. То есть эта цифра должна с точностью до знака совпадать с цифрой которая указана в значении второй буквы s. Если будут расхождения, то будет выводиться все значение VALUE без конвертации сериализованного массива в результате чего вы и получите такой вывод как вы писали.
Короче говоря у вас слетят все доп. поля и настройки инфоблоков, поскольку скрипт который предлагается для конвертации просто конвертирует кодировку в лоб, без пересчёта символов сериализованных масивов, а без этого из полей будет выводиться весь сериализованный массив, а не только данные
Спасибо за ответ. Я так и понял, что это начало и конец массива. Специально залез в базу после конвертации. В подтверждении Ваших слов, там действительно все данные которые хранились в массиве вида a:2:{...} сами по себе содержаться в массиве вида a:2{...}. И длина там указана с учетом заголовков. Т.е. к примеру, был текст: a:2:{s:4:"TEXT";s:24:"<h1>HTML-ТЕКСТ</h1>";s:4:"TYPE";s:4:"html";} После конвертации стало: a:2:{s:4:"TEXT";s:71:"a:2:{s:4:"TEXT";s:14:"<h1>HTML-ТЕКСТ</h1>";s:4:"TYPE";s:4:"html";}";s:4:"TYPE";s:4:"TEXT";}
Не нашел решения лучше, чем сделать импорт базы в csv, и удалить заголовки и концы массивов с помощью рег.выражений.
Кстати, настройки инфоблоков, почему-то не слетели, как и некоторые доп.поля. Видимо, где-то длина символов осталась верной и, соответственно, правильно указанной в заголовке.
Все хорошо, но похоже что каждую минуту или около того запускается какой-то агент и кодировка слетает вновь. Пересохранение любого инфорблока это исправляет, однако через минуту кодировка слетает по новой. В чем может быть проблема?
Все комментарии не читал, возможно уже писали. Начал делать конвертацию на демо версии битрикса редакции Малый бизнес. После запуска файла convert_utf8.php обрывается обработка ошибкой: Срок работы пробной версии продукта истек. Вы можете купить полнофункциональную версию продукта на сайте www.1c-bitrix.ru. Регистрация.
Это нормально для пробной версии или это ошибка скрипта? Или конвертацию нужно проводить после активации лицензионного ключа?
проблемы с полем html/text после конвертации сайта
в итоге поля такого типа хранятся в бд в формате json, могут находиться либо в общей таблице свойств элементов - b_iblock_element_property, либо в отдельно таблице для данного вида свойства, что-то типа - b_iblock_element_prop_s62, но название может отличаться.
<?
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/header.php");
if($USER->IsAdmin())
{
$custPropTableName = 'b_iblock_element_prop_s62';
global $DB;
$r = $DB->Query("SEL ECT ID FR OM b_iblock_property WHERE USER_TYPE='HTML'");
while($prop = $r->Fetch())
{
$rV = $DB->Query("SELECT ID, VALUE FR OM b_iblock_element_property WHERE IBLOCK_PROPERTY_ID=".$prop['ID']." AND VALUE IS NOT NULL AND VALUE LIKE 'a:%'");
while($pV = $rV->Fetch())
{
$rowPropVal = $pV['VALUE'];
$newJson = getValidJson($rowPropVal);
$elID = $pV['ID'];
if($newJson && $elID){
$updateSql = "UPD ATE b_iblock_element_property SET VALUE='$newJson' WHERE ID=".$elID;
$rs2 = $DB->Query($updateSql);
if($rs2){
echo '-updated '.$elID;
}else{
echo '-error-update '.$elID;
}
}
echo '<br><br>';
}
}
$rs = $DB->Query("SELECT * fr om $custPropTableName;");
while($row = $rs->Fetch())
{
foreach ($row as $rowPropName => $rowPropVal) {
if (strpos($rowPropName, 'PROPERTY_') !== false && strpos($rowPropVal, 'a:') !== false) {
$newJson = getValidJson($rowPropVal);
$elID = $row['IBLOCK_ELEMENT_ID'];
if($newJson && $elID) {
$rs2 = $DB->Query("UPDATE $custPropTableName SE T $rowPropName = '$newJson' WH ERE IBLOCK_ELEMENT_ID = $elID LIM IT 1;");
if($rs2) {
echo '-updated '.$elID;
}else{
echo '-error-update '.$elID;
}
}
echo '<br><br>';
}
}
}
}
function getValidJson($rowPropVal) {
$str = unserialize($rowPropVal);
if($str == false) {
/*ПРОБУЕМ СМЕНИТЬ КОДИРОВКУ*/
$encodingIn = mb_detect_encoding($rowPropVal, 'auto');
$rowPropVal = iconv($encodingIn, 'WINDOWS-1251', $rowPropVal);
/*ДЕКОДИРУЕМ JSON*/
$str = unserialize($rowPropVal);
if($str) {
$str['TEXT'] = str_replace(array("'"),'',$str['TEXT']);
$arUpdate = array(
'TYPE' => $str['TYPE'],
'TEXT' => iconv('WINDOWS-1251','UTF-8',$str['TEXT']),
);
/*КОДИРУЕМ В JSON В НОВОЙ КОДИРОВКЕ*/
$newJson = serialize($arUpdate);
return $newJson;
}
}
return false;
}
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/footer.php");?>
Перевел сайт на php7, все замечательно, теперь нужно на utf-8 перевести, все сделал как написано выше, запустил скрипт конвертации, мне он выдал такой ответ: "База данных работает в кодировке, отличной от cp1251 (значение: utf8)". Что с этим делать? Сайт сейчас в "кракозябах" а инфа из ИБ, то есть из БД, нормально отображается!
Воспользовалась данным скриптом, и, как у многих здесь написавших, получила админку в краказябрах. Второй раз скрипт не срабатывает. Наивно полагая, что у меня всё получится, начала вручную менять кодировку файлов. На третий день этого жуткого занятия поняла, что это бессмысленно и беспощадно. Вылечить сайт помог следующий рецепт. Очень надеюсь, что он поможет и еще кому-то.
Принудительное повторное обновление ядра Bitrix:
Обновить ядро и перезагрузить только файлы PHP Битрикса возможно повторно. Для этого необходимо перейти на страницу обновления и в адресную строку добавить ключ:
/bitrix/admin/update_system.php?BX_SUPPORT_MODE=Y
Появится окно и кнопка, чтобы перезагрузить все модули и ядро PHP Битрикса.
Если что-то пошло не так при обновлении, то нужно воспользоваться инструментом"Настройки" - "Инструменты" - "Проверка сайта". При проверке система выдаст все замечания и оставшиеся ошибки.
Данное лекарство нашла в сети, датировано 2013 годом. Инструмент у меня сработал прекрасно, вся админка вернулась в нормальный вид, ошибок на сайте и в базе обнаружено не было. Надеюсь, что еще кому-то поможет, так как сама настрадалась с конвертацией и понимаю всю боль
спасибо за скрипт, очень помог.. после перекодировки в utf-8 открылась проблема с бизнес процессами: в дизайнере бизнес процессов теперь ромбики, в параметрах тоже http://joxi.ru/p271DwgF0XgY6r
Когда запускается БП, то вместо параметров пустые строки
Долго курил данный топик на предмет конвертации и в результате получил также админку в крокозяблах, ее метод не помог - то ли руки кривые, то ли еще чтото. В админке видно что не перекодируется только то что имеет отношение к javascrpit. Решил следующим образом - поставил заново битрикс в новую базу данных, зная что старая бд у меня корректна и подключился к старой базе данных, при этом сохранил всех пользователей, но вот дополнения пришлось переставить в плане файлов (после переустановки данные по модулям подхватились из админки). Еще раз огромное всем кто принимал участие в данном топике!
После смены кодировки возникает ошибка структуры базы данных. Дела несколько раз, результат одинаковый: Структура базы данных имеет ошибки. Всего 137, автоматически могут быть исправлены: 0
Например: 2019-Jan-23 12:05:20 Структура базы данных (check_mysql_table_structure): Ok 0% done В таблице b_search_content поле URL "`URL` mediumtext NULL DEFAULT NULL" не соответствует описанию на диске "`URL` text NULL DEFAULT NULL" В таблице b_search_content поле TITLE "`TITLE` mediumtext NULL DEFAULT NULL" не соответствует описанию на диске "`TITLE` text NULL DEFAULT NULL" В таблице b_search_content поле TAGS "`TAGS` mediumtext NULL DEFAULT NULL" не соответствует описанию на диске "`TAGS` text NULL DEFAULT NULL" В таблице b_search_content поле PARAM1 "`PARAM1` mediumtext NULL DEFAULT NULL" не соответствует описанию на диске "`PARAM1` text NULL DEFAULT NULL" В таблице b_search_content поле PARAM2 "`PARAM2` mediumtext NULL DEFAULT NULL" не соответствует описанию на диске "`PARAM2` text NULL DEFAULT NULL" В таблице b_search_content_site поле URL "`URL` mediumtext NULL DEFAULT NULL" не соответствует описанию на диске "`URL` text NULL DEFAULT NULL" В таблице b_search_custom_rank поле PARAM1 "`PARAM1` mediumtext NULL DEFAULT NULL" не соответствует описанию на диске "`PARAM1` text NULL DEFAULT NULL" В таблице b_search_custom_rank поле PARAM2 "`PARAM2` mediumtext NULL DEFAULT NULL" не соответствует описанию на диске "`PARAM2` text NULL DEFAULT NULL"
Вот официальный ответ который дала мне техподдержка по этой проблеме:
"Добрый день, В данном случае, если была конвертация через инструкцию мы не поддерживаем такие изменения потому-что проходят со стороны сервера. Ситуация по обновлению по стандартному методу мы можем рассматривать, но в данном случае ситуация уже со стороны сервера. Рекомендую откатить, и сделать стандартное обновления, и после мы можем рассматривать что именно не так там происходит. Но в данном случае обновления должно быть сделано по стандартному функционалу."
Как вы понимаете, поморщи ждать не стоит... (((
И готовьтесь к тому, что у вас могут возникнуть проблемы с "падающей" БД.
Спасибо автору за полезный инструмент. Все сделал норм.
Столкнулся с затруднением. База частично была в UTF-8 или выглядела так, хрен знает почему, история умалчивает. В общем, при запуске, скрипт писал, что база уже в UTF и работать не хотел. Пришлось просто отключить эту ошибку. В итоге все законвертилось как надо.
Особенность, если сайт установлена на веб окружение битрикс.
Проверяем, что хостинг имеет mbstring.func_overload 2 Проверка через настройку php в административной части Битрикс Master и Local должны иметь значение 2. Если local равен 0, то значит при установке сайта в папке /etc/httpd/bx/conf/ в конфигурационном файле bx_ext_каталог_сайта.conf прописалась кодировка windows-1251 php_admin_value mbstring.func_overload 0 php_admin_value default_charset latin Эти две строки нужно закомментировать.
Добрый день. Попробовали провести конвертацию с помощью этого скрипта нашего сайта , работающего на последней версии продукта, установлен стандартный интернет магазин битрикс. Версия Битрикс 20.0.700. Редакция Бизнес. В результате сконвертировались не все файлы. Некоторые языковые файлы подправили специалисты хостинга (отображались знаки вопроса). Внешне вроде сайт работает и все отображается нормально, но при попытке открыть на просмотр некоторые файлы, например, файлы других установленных языковых версий /ua через панель хостинга, они открываются только в старой кодировке 1251. Т.е. явно не все перекодировалось. Работает ли скрипт корректно на текущей версии Битрикс? Возможно ли как-то проверить все ли файлы перекодировались и найти неперекодированные и сделать это повторно? Как лучше поступить? Спасибо.
Приветствую! Огромное спасибо за вашу работу! В моём случае не всё сработало. Опишу что не получилось (всё я пока не проверил, описываю только то, что сразу заметно): При переводе файлов не были переведены некоторые файлы включаемых областей, например /local/templates/2019/include_areas/main/disc1_1.php. В том же каталоге (возможно проблема в названиях): disc9.php, head1.php, key1.php, key1.php Так же не были конвертированы несколько полей таблиц (обе таблицы были пусты) 2020-Jun-22 09:33:55 Кодировки таблиц в БД (check_mysql_table_charset): FailКодировка поля "INDEXED" таблицы "b_translate_file" (cp1251) отличается от кодировки базы (utf8) Кодировка поля "IS_LANG" таблицы "b_translate_path" (cp1251) отличается от кодировки базы (utf8) Кодировка поля "IS_DIR" таблицы "b_translate_path" (cp1251) отличается от кодировки базы (utf8) Кодировка поля "INDEXED" таблицы "b_translate_path" (cp1251) отличается от кодировки базы (utf8)
Повторный запуск скрипта не исправил ситуацию. Остатки я добью вручную, это просто фидбек, если у вас будет желание доработать скрипт ))
И ещё мне мешала инструкция $res = $DB->Query('SHOW VARIABLES LIKE "character_set_results"'); $f = $res->Fetch(); if (strtolower($f['Value']) != 'cp1251') Error('База данных работает в кодировке, отличной от cp1251 (значение: '.$f['Value'].')');
У меня сайт на хостинге, в phpMyAdmin я переключил всё, что можно на cp1251 - это не помогло. команды SET character_set_results = 'cp1251' и SET NAMES cp1251, так же не помогли. Пришлось закомментировать проверку в скрипте.
Иванов Александр 25.10.2010 02:04:33 при запуске сразу горорит: База данных работает в кодировке, отличной от cp1251 (значение: utf8). Ответить Ссылка 0Мне нравится Вуколов Роман 08.01.2011 04:09:22 такая же фигня Ответить Родитель Ссылка 0Мне нравится Базаров Михаил 20.03.2013 23:34:19 В 32 ой строчке конвертера замените на if (strtolower($f['Value']) != 'utf8') помогло.
Ну или вообще эту проверку убить можно. Еще вариант запустить базу в 1251
Всем доброго времени. На третьем шаге при попытке конвертации БД сразу вылетает ошибка "MySQL Query Error!". На самом серваке логи ничего внятного не фиксируют
Штатный мастер миграции на utf-8 вышел в обновлении модуля производительности perfmon 23.200.0. Обновите модуль производительности, после этого в списке мастеров административного раздела (Рабочий стол - Настройки - Настройки продукта - Список мастеров) запустите мастер "Конвертация в utf8". Об этом сказано во втором абзаце урока, на который вы приводите ссылку:
Сменить кодировку поможет Мастер конвертации сайта в UTF-8
Ручной вариант с шагами:
Всё понятно до пункта 9 Общий порядок действий: Перекодируйте все файлы сайта в UTF-8.
является устаревшим и может быть использован только опытными администраторами хостинга.
можно проще в майконф вписать
default-character-set = cp1251
character-set-server = cp1251
collation-server = cp1251_general_ci
init-connect = "SET NAMES cp1251"
и не будет квадратиков с вопросиками )
а перегонять быстрее так _http://www.pilot34.com/2008/01/mysql-cp1251-utf8.html
iconv иногда криво это делает.
Например попробуйте с таблицей b_bp_workflow_template.
Она будет соответствовать кодировке клиента, которым делали дамп.
по этому для всех табличек нужно сделать
ALTER TABLE b_agent CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE b_agent DEFAULT CHARACTER SET utf8;
по этому для всех табличек нужно сделать
ALTER TABLE b_agent CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
ALTER TABLE b_agent DEFAULT CHARACTER SET utf8;
Ну это есессно.
Но я про blob поля.
default-character-set = cp1251
character-set-server = cp1251
collation-server = cp1251_general_ci
init-connect = "SET NAMES cp1251"
и не будет квадратиков с вопросиками )
Пока не посмотрели настройки сервака.
А там было
character_set_server | latin1
character_set_system | utf8
collation_server | latin1_swedish_ci
поменяли всё на utf8 и взлетело!
можно так
сливать заливать базу -
конвертировать Notepad++
для маленьких баз )
# Изменить в настройках языка ru кодировку с windows-1251 на utf8
utf8utf-8Единственное, не работает при загруженном словаре нецензурных слов для форума...
Ругается на дублирующиеся записи с символами "ё" в таблице b_forum_letter.
После удаления одной из строк с "ё" все прошло успешно.
Подскажите пожалуйста, как с ней побороться?
В старых дистрибутивах без поддержки utf это поле было больше.
Вот его бы тоже обнародовать
* str_ireplace
* stripos
* strripos
Небольшое дополнение. Поведение функций serialize и unserialize немного меняется при работе с UTF-строками. Обратная совместимость поддерживается, поэтому при обычном использовании проблем быть не должно. Проблемы могут появиться если:
* вы по каким-либо причинам собираете сериализованный массив вручную
* сериализованный массив пришел из не-UTF источника
* вы по каким-либо причинам собираете сериализованный массив вручную
* сериализованный массив пришел из не-UTF источника
Т.к. serialize делался на win-1251, а unserialize выполняется на utf-8, получается несовпадение, и на сайте значения не отображаются
Ещё из замеченных проблем:
Не перевелся в utf8 файл /bitrix/modules/search/tools/ru/stemming.php, что привело к неработоспособности поиска (на любой запрос выдается сообщение о пустой строке запроса).
Не перевелись в utf8 шаблоны сайта.
Был отправлен запрос на конвертацию данных, но сам скрипт был блокирован по времени. Если вы не рестартовали БД - этот запрос выполнился, соотв. процесс прервался на данной таблице.
Попробуйте снова с третьего шага, запустите скрипт с параметром
Вероятно, у вас медленно работает база данных. Если это хостинг - можно перенести сайт на локальную машину и там выполнить конвертацию.
И при запуске скрипта (причем только в IE) уже выводится страничка с просьбой авторизоваться. Но даже ввод пароля ничего не решает. Всё-равно через 5 секунд белый экран.
Видимо какая-то проблема с доступом.
recode_all
cvtunit
Ну и напоследок, после проверки, остается с помощью того же find|xargs удалить все файлы типа .cp1251
Для тех случаев, когда хостер дает SSH, это оптимальное по скорости решение.
mkdir /tmp/1 # временная папка
find -type d -exec mkdir /tmp/111/{} # создание пустой структуры каталогов
find -name '*.php' -exec iconv -fcp1251 -tutf8 {} -o /tmp/111/{} \; # конвертация
cp -fr /tmp/111/* . # копирование назад
А базу я бы рекомендовал конвертировать средствами базы, как это делает скрипт convert_utf8.php.
Переходим в нужную папку и выполняем:
Но есть один минус.
У меня табличка b_sale_basket 181.5 МБ, ну соответственно скрипт не успевает ее обрабатывать и на ней зацикливается.
Если повторно запустить скрипт конвертации с шага конвертации базы - всё должно пройти нормально: convert_utf8.php?step=3
А вообще, размер этой таблицы можно регулировать параметром настройки модуля магазина: "Сохранять корзину (дней)".
Здесь es надо заменить на идентификатор испанского языка.
Добавив условия можно несколько языков привести к utf8.
Языковые файлы не кодируются, а так скрипт будет конвертировать только их.
А как же, например, js файлы, в которых есть такие штуки, как Аяксовое окошечко "Загрузка..." и другие сообщения?
на
Внёс соответствующие изменения в исходный скрипт.
На сайте кодировка отображалась совершенно некорректно, видимо кто-то начал конвертить в utf8 но либо безуспешно, либо не до конца. Я попробовал сделать это окончатально, согласно доходчивым инструкциям (за что огромное спасибо ) Но в итоге у меня часть информации отображается крокозябрами, а панель управления на русском вообще нечитабельна.
Подскажите куда копать, а то я чет совсем не догоняю....
Тестовая площадка с сайтом
Заранее спасибо.
такого рода строки
Идёт обработка...
Текущий файл: /var/www/planeta/data/www/tvplaneta.ru/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/www/w
явление нормальное??? смущает большое количисество www
Сайтов 2. Причём, сам битрикс находится в /var/www, а сайты в /var/www/site1 и /var/www/site2 соответственно.
Есть проблема какая-то с ней?
Не конвертируется только текст, который попадается в шаблонах.
В поисковой фразе обнаружена ошибка:
Пустой поисковый запрос (запрос не содержит букв или цифр).
Исправьте поисковую фразу и повторите поиск.
К слову, удалить поиск без таблиц можно до начала конвертации, а установить уже после.
Либо вручную сконвертировать файлы указанной папки.
База данных работает в кодировке, отличной от cp1251 (значение: utf8).
if (strtolower($f['Value']) != 'utf8')
помогло.
Ну или вообще эту проверку убить можно. Еще вариант запустить базу в 1251
В папке /bitrix/templates/ все вложенные файлы остались в кодировке windows-1251.
2. У меня возникла следующая проблема. При перекодировании базы, возникла проблема на табличке b_forum_letter, а именно:
MySQL Query Error: ALTER TABLE `b_forum_letter` MODIFY `LETTER` varchar(50) CHARACTER SET utf8 [Duplicate entry '2-Рµ' for key 'LETTER_NEW']
Ключи совпадают у следующих записей:
INSERT INTO `b_forum_letter` (`ID`, `DICTIONARY_ID`, `LETTER`, `REPLACEMENT`) VALUES
(25, 2, 'ё', 'ЁёЕеEe, [Йй]+[Оо]+'),
(24, 2, 'е', 'ЁёЕеEe');
Причина собственно известна:
Кто нибудь сталкивался с этой проблемой, или может быть знает как решить? Удалять без лишней необходимости ключ не хочется. Да и форум станет работать не правильно.
Вообще хотелось бы узнать что об этом думает тех поддержка. Которая в свое время распиналась что мол продукт поддерживает UTF-8! Покупайте!!!
Выполнили все рекомендации но ничего не помогло.
Администраторы хостинга только на одной странице помогли исправить командой iconv -f cp1251 -t utf8 index.php > index_1.php
А как исправить на всем сайте (панель управления, меню, шаблоны и пр.)?
Как это поправить? Я мог бы поправить вручную но подскажите куда лезть??
что делать
При конвертации БД значения по умолчанию для строковых типов полей сбрасываются в NULL, т.е. убиваются значения по умолчанию для полей которые переводятся из cp1251 в utf8. Никто не сталкивался с этим, это моя проблема или так работает скрипт?
P.S. MySQL 5.1.56
вот могу привести пример другой таблицы:
SHOW FIELDS FROM b_form_status
Field Type Null Key Default Extra
все же проблема есть. немного переделал запросы в строке 94, у меня получилось:
Но таблицы в базе данных 100% в cp1251, конвертирую базу после перехода на VM Bitrix где может быть проблема?
Единственная (надеюсь) проблема - перестал нормально работать поиск. Заглянул в базу данных и обратил внимание, что в таблице
Неработающий поиск для новостного сайта — очень неприятная вещь