
Сразу оговорюсь, что данный пост не претендует на статус официального документа, это должно быть хорошее подспорье по проблеме.
[spoiler]
Подготовка
-  Для работы сайта на битрикс в utf8 абсолютно необходимо наличие модуля mbstring в php (это есть почти на любом хостинге) и установка параметра mbstring.func_overload 2 
 С этим может быть проблема т.к. с версии php 5.2.8 параметр меняется глобально на весь сервер (). Уточните вопрос у хостера, но будьте осторожны если вам предложат CGI (см. ).
 На VPS/выделенном сервере параметр без проблем меняется в php.ini.
-  Обязательно сделайте резервную копию работающего сайта, а лучше именно на копии проводите эксперименты. Если что-то пойдёт не так - вы можете потерять данные!
Этапы перехода
-  Подготовить сервер как показано выше
-  Добавить в /bitrix/php_interface/dbconn.php define("BX_UTF", true); 
-  Установить в /bitrix/.settings.php utf_mode => array('value' => true, 'readonly' => true) 
- Изменить в настройках сайта кодировку с windows-1251 на utf-8
-  Изменить в настройках языка ru кодировку с windows-1251 на utf-8
-  Конвертировать все файлы в utf8
-  Конвертировать БД в utf8
-  Сменить в /bitrix/php_interface/after_connect.php на$DB->Query("SET NAMES 'cp1251'";); и в файле /bitrix/php_interface/after_connect_d7.php$DB->Query("SET NAMES 'utf8'";); $connection->queryExecute("SET NAMES 'utf8'"); 
 $connection->queryExecute('SET collation_connection = "utf8_unicode_ci"');
-  Сбросить весь кеш
-  Выйти и зайти на сайт чтобы обновить данные сессии
Практическая сторона вопроса
После смены кодировки сайта публичная часть принимает вид:
Это нормально, браузер пытается показать данные не в той кодировке. Теперь после всех действий внешний вид восстановится, и мы увидим, что процесс прошёл успешно.
Большое число файлов надо конвертировать по шагам, для этого буду использовать . По большому счёту, тут надо только переделать функцию замены в конвертацию через mb_convert_encoding.
Примечание. Часто при использовании внешних программ для конвертации в файлы добавляется специальная последовательность символов, т.н. . Эти символы должны находиться только вначале файла, а поскольку итоговая html страница является составной из нескольких php файлов, то спецсимволы появляются в теле html страницы. Если делаете вручную - не сохраняйте с BOM!
Для конвертации базы надо сменить кодировку базы, всех таблиц и всех текстовых полей таблиц. Вручную это тоже делать не очень удобно. Решил сделать конвертацию файлов и базы в одном скрипте.
Скрипт выполняет операции:
| - Конвертировать все файлы в utf8 - Конвертировать БД в utf8 | 
Остальное следует делать вручную по списку в том порядке, как написано.
Можно скачать по ссылке:
В итоге получил картинку
Теперь, словно, девушка даже слегка улыбнулась

Обновление от 20.02.2012
- Теперь конвертируются все файлы, не только языки. При этом делается авто определение кодировки файла, а значит можно выполнять конвертацию повторно.
- Для кодировки базы указывается сравнение utf8_unicode_ci (требуется продуктом).
- Исправлены ошибки конвертации базы.
- Шаг конвертации файлов можно пропустить.
Дополнение от 10.09.2018
Если вы использовали интеграцию с почтой, проверьте настройки ящиков, если там установлена кодировка, переключите кодировку сайта.
 
										 
															 
			 
      
можно проще в майконф вписать
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
А вообще, размер этой таблицы можно регулировать параметром настройки модуля магазина: "Сохранять корзину (дней)".
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.
Языковые файлы не кодируются, а так скрипт будет конвертировать только их.
А как же, например, 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 где может быть проблема?
Единственная (надеюсь) проблема - перестал нормально работать поиск. Заглянул в базу данных и обратил внимание, что в таблице не заполняется поле searchable_content, в него попадает только фрагмент заголовка элемента и все
Неработающий поиск для новостного сайта — очень неприятная вещь