|
Пользователь 76561 Посетитель Сообщений: 69 |
Продукт — «Портал государственной организации» Кодировка таблицы b_perf_cluster (cp1251) отличается от кодировки базы (utf8) Еще есть 7 строк вида: Сравнение (Collation) для таблицы «b_perf_cluster» (cp1251_general_ci) отличается от значения для базы (utf8_general_ci) и 266 строк вида: Сравнение (Collation) для таблицы «b_adv_banner» (utf8_unicode_ci) отличается от значения для базы (utf8_general_ci) Всего таблиц 275 b_iblock_offers_tmp когда возникли ошибки не известно Вопросы Заранее спасибо |
|
Пользователь 76561 Посетитель Сообщений: 69 |
|
|
Администратор Сообщений: 137 |
обратитесь к хостерам, пусть выполнят необходимые запросы и перекодируют все таблиц в нужную кодировку. Руководитель службы технической поддержки |
|
Пользователь 76561 Посетитель Сообщений: 69 |
Сервер у меня свой, перекодировать таблицы я могу сам. Хотелось бы понять что вызывает смену кодировки во ВСЕХ таблицах. Устанавливался продукт под кодировкой UTF-8. |
|
Пользователь 76561 Посетитель Сообщений: 69 |
Продукт недавно развернули, сейчас идет настройка. Не поздно переустановить. Но есть ли смысл? |
|
Пользователь 12014 Эксперт Сообщений: 1000 |
Достаточно перекодироват таблицы Не жмись, кликай «Мне нравится» на сообщении |
|
Пользователь 76561 Посетитель Сообщений: 69 |
Перекодировать таблицы достаточно, а что необходимо сделать или чего нельзя делать, чтобы кодировка произвольно не изменялась |
|
Пользователь 90944 Посетитель Сообщений: 79 |
Мужики подскажите как перекодировать базу,у меня такая же ерунда вышла.Переносил сайт с веб окружения на виртуалку и вот тебе на Сравнение (Collation) для таблицы «b_adv_banner» (utf8_unicode_ci) отличается от значения для базы (utf8_general_ci) и так далее……. |
|
Администратор Сообщений: 1193 |
ALTER DATABASE XXX DEFAULT COLLATE utf8_unicode_ci; |
|
Пользователь 34561 Постоянный посетитель Сообщений: 287 |
#10 5 29.07.2011 10:45:40 Было то же самое. Вот ответы техподдержки: Посмотреть параметры кодировки БД можно следующим запросом (Настройки — Инструменты — SQL запрос): Все параметры, кроме параметра character_set_filesystem необходимо установить в соответствие с кодировкой сайта. Это можно сделать в файле after_connect.php (bitrixphp_interfaceafter_connect.php), например: Затем проверить кодировку в проверке сайта в «Тестировании конфигурации» (Настройки — Инструменты — Проверка сайта). Для смены кодировки таблиц выполните, пожалуйста, запрос для каждой таблицы: Проблема решается добавлением: Если к таблицам «b_search_phrase» и «b_search_suggest» будут ошибки, которые нельзя будет исправить (например восстановить таблицы), тогда мы рекомендуем Вам удалить модуль Поиск (Настройки — Настройки продукта — Модули) без сохранения данных в таблицах базы данных. Затем заново установите модуль Поиск, проведя переиндексацию сайта. После выполнения всех процедур все выровнялось. Рекомендую. |
|
Пользователь 90944 Посетитель Сообщений: 79 |
#11 0 29.07.2011 13:24:24
Большое спасибо,Помогло. |
||
|
Пользователь 90944 Посетитель Сообщений: 79 |
#12 0 29.07.2011 13:35:03
У меня еще одна проблема возникла,я думаю что данного характера,перенес сайт веб окружения на вертуалку,сначала были ошибки с кодировкой(это исправил)теперь обнаружил что часть портала а именно Интранет встал коряво,шаблон не тот что был,да и информация которая была отображается всего лишь на 30 процентов…было в базе забито около 100 сотрудников а после переноса стало человек 10 и т.п. |
||
|
Пользователь 871 Посетитель Сообщений: 70 |
#13 3 16.09.2011 15:17:58 QODA, спасибо
помогло ) |
||
|
Пользователь 49702 Заглянувший Сообщений: 10 |
#14 0 19.09.2011 10:46:50
Огромное спасибо! Решение помогло! |
||
|
Пользователь 109077 Заглянувший Сообщений: 1 |
#15 0 30.11.2011 15:49:58 При проверке сайта после восстановления из бэкапа вылезли следующие ошибки: Кодировка соединения (check_mysql_connection_charset): Fail Дописывание $DB->Query(‘SET collation_connection = «utf8_unicode_ci»‘); в after_connect приводит к тому, что нельзя зайти даже на морду сайта. Где ещё можно копать? |
|
Пользователь 85035 Заглянувший Сообщений: 32 |
#16 0 14.12.2011 03:00:16 попробуй еще добавить в начало Вот мой файл after_connect.php
4, повторяем Тестирование конфигурации. Все ок! Удачи:) |
||||||
|
Пользователь 99542 Заглянувший Сообщений: 7 |
#17 0 15.12.2011 17:35:57 Скачал виртуальную машину. Сравнение соединения с базой данных должно быть utf8_unicode_ci, текущее значение: utf8_general_ci. Раньше такого не было. |
|
Пользователь 63180 Эксперт Сообщений: 618 |
#18 3 02.08.2012 17:04:10 а можно сменить кодировку всем таблицам сразу ) SELECT CONCAT(‘ALT ER TABLE `’, t.`TABLE_SCHEMA`, ‘`.`’, t.`TABLE_NAME`, ‘` CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;’) as sqlcode FROM `information_schema`.`TABLES` t (вместо db_name) имя вашей базы в результате запроса вы увидете пару сотен строк )) типа
затем ответ копируете и все эти строки бахаете как новый запрос ) вот и всё) для утф посдатвляете utf8 COLLATE utf8_general_ci; |
||
|
Пользователь 576649 Заглянувший Сообщений: 1 |
#19 0 29.01.2017 22:58:19 Кодировки таблиц имеют ошибки 2017-Jan-29 22:51:26 Кодировки таблиц в БД (check_mysql_table_charset): Fail помогите разобраться |
|
Пользователь 34550 Эксперт Сообщений: 1579 |
#20 0 30.01.2017 10:09:39 вам же все написано. |
|
Пользователь 307442 Заглянувший Сообщений: 10 |
#21 0 12.02.2019 11:46:47 А у меня тоже проблем но на команду ALT ER DATABASE XXX DEFAULT COLLATE utf8_unicode_ci; приходит ответ [1044] Access denied for user ‘логин-базы_bitrix’@’localhost’ to database ‘XXX’! доступ запрещен как мне быть |
Проблемы с кодировкой на сайте часто встречаются после миграции с устаревшего серверного ПО (например, версии PHP) на новое.
Например, кодировка 1251 неактуальна для PHP старше версии 5.6. В связи с чем требуется изменение кодировки на UTF-8, которая является стандартом для последних версий PHP.
Если ваш сайт до миграции на наш хостинг работал в кодировке 1251, то при проверке системы вы можете видеть замечание: «Сайт работает в однобайтовой кодировке». Для исправления ситуации потребуется конвертировать сайт в UTF-8 или сделать изменения PHP-обработчика под кодировку 1251.
Следуйте шагам:
Исправьте настройки базы данных из панели 1С Битрикс в случае, если на странице /bitrix/admin/site_checker.php выводится ошибка: Ошибка! Кодировка базы (utf8) отличается от кодировки соединения (cp1251). [ Исправить ]
Если операция завершилась неуспешно, то повторно повторите исправление.
В редких случаях требуется ручное исправление из phpMyAdmin:
В панели хостинга в разделе «базы данных» перейдите в базу данных вашего сайта. После редиректа в phpMyAdmin войдите в раздел «операции» и в блоке «сравнение» выберите «utf-8_general_ci». Нажмите кнопку «вперед».
Редактирование php.ini для выбранной версии режиме PHP вашего сайта:
Убедитесь, что в настройках php.ini для выбранной версии PHP вашего сайта установлены значения:
Для варианта конвертации в utf-8:
mbstring.func_overload = 2
mbstring.internal_encoding = utf-8
default_charset = «utf-8»
Для варианта без конвертации (остается кодировка 1251):
mbstring.func_overload = 0
mbstring.internal_encoding = cp1251
default_charset = «cp1251»
Для однобайтовой кодировки (1251) также потребутеся отключить кодировку UTF-8 в панели хостинга в разделе «WWW-домены»:
Далее необходимо привести настройки согласно требуемой кодировке в файлах системы 1С Битрикс:
Для варианта корвертации в utf-8:
В /bitrix/php_interface/dbconn.php должно быть значение: define(‘BX_UTF’, true);
В /bitrix/.settings.php должно быть значение: ‘utf_mode’ => array (‘value’ => true, ‘readonly’ => true,),
Для варианта без конвертации (остается кодировка 1251):
В /bitrix/php_interface/dbconn.php полностью удалить значение: define(‘BX_UTF’, true);
В /bitrix/.settings.php должно быть значение: ‘utf_mode’ => array (‘value’ => false, ‘readonly’ => true,),
09.11.2021
После установки Битрикса на новый сервер возникла проблема, при «самопроверке» CMS, сообщение:
Ошибка! Кодировка соединения с базой данных должна быть utf8, текущее значение: utf8mb3
Сам Битрикс рекомендовал:
но в конфигурационных файлах все был прописано верно.
Проверка Битрикса выполняется через Настройки — Инструменты — Проверка системы (/bitrix/admin/site_checker.php)
.
В итоге пришлось решать вопрос исправлением файла bitrix/modules/main/classes/general/site_checker.php, в блоке ниже, заменил
utf8 на utf8mb3 и
utf8_unicode_ci на utf8mb3_unicode_ci
if (defined('BX_UTF') && BX_UTF === true)
{
if ($character_set_connection != 'utf8mb3')
$strError = GetMessage("SC_CONNECTION_CHARSET_WRONG", array('#VAL#' => 'utf8', '#VAL1#' => $character_set_connection));
elseif ($collation_connection != 'utf8mb3_unicode_ci')
$strError = GetMessage("SC_CONNECTION_COLLATION_WRONG_UTF", array('#VAL#' => $collation_connection));
}
Ошибка! Сравнение для базы (utf8_general_ci) отличается от сравнения для соединения (utf8_unicode_ci)
Mysql поддерживает много кодировок и это нередко является головной болью для программистов. Самая частая проблема — кракозяблы вместо русского текста. Это происходит из за того, что текст либо лежит на сервере, либо отдается клиенту в неверной кодировке. Последнее(а иногда и первое) решается проще всего. Устанавливаем кодировку соединения (в utf8 в примере) сразу после установления соединения
|
mysql_set_charset(‘utf8’); // или mysql_query(‘SET NAMES «utf8″‘); |
Хуже, когда скрипт отдает в базу, данные в верной кодировке, а в ответ получаем кракозяблы или вопросики. Или когда часть таблиц в верной кодировке, часть нет.. В таких случаях придется разбираться детально.
|
mysql_query(«SHOW VARIABLES LIKE ‘char%’» ); /* character_set_client: latin1 character_set_connection: latin1 character_set_database: utf8 character_set_filesystem: binary character_set_results: latin1 character_set_server: cp1251 character_set_system: utf8 character_sets_dir: usrlocalmysql-5.1sharecharsets */ |
Этот запрос обязательно проверять в самом скрипте, а не в phpmyadmin, где могут быть установлены другие параметры
character_set_client— кодировка, в которой данные будут поступать от клиентаcharacter_set_connection— по умолчанию для всего, что в рамках соединения не имеет кодировкиcharacter_set_database— кодировка по умолчанию для базcharacter_set_filesystem— кодировка для работы с файловой системой (LOAD DATA INFILE, SELECT … INTO OUTFILE, и т.д.)character_set_results— кодировка, в которой будет выбран результатcharacter_set_server— кодировка, в которой работает серверcharacter_set_system— идентификаторы MySQL, всегда UTF8character_sets_dir— папка с кодировками
По умолчанию после установки mysql сервер, который устанавливается ленивым хостеромадмином имеет кодировку latin1. Соответственно указанные выше глобальные переменные будут в latin1. Базы соответственно по умолчанию и таблицы так же. И именно на это стоит обратить в самом начале обратить внимание, чтобы проблемы не всплывали позднее.
В идеальном варианте, нам следуетпривести все отмеченные цветом кодировки к единому значению. Тогда мы просто будем избавлены от мелких ошибок с кодировкой. Фактически, если мы работаем с хостингом, то на (3) и (6) мы повлиять не сможем. Но и это не страшно если настроены остальные три параметра. Mysql умет перекодировать на лету если правильно настроена кодировка соединения.
Ну и наконец, основной вопрос, что делать если одна из mysql таблиц(или несколько) в неверной кодировке и на сайте видны кракозяблывопросики?
1. Выяснить кодировку таблицы.
|
mysql > SHOW CREATE TABLE `files` ————————————————————————— CREATE TABLE `files` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `iNode` int(10) unsigned NOT NULL, `pid` int(10) unsigned NOT NULL, `sName` varchar(128) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL, `sTitle` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL, PRIMARY KEY (`id`), KEY `iNode` (`iNode`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 |
В этой таблице поле sName в кодировке latin1, если у нас соединение в другой кодировке, то мы увидим кракозябры.
2. Поэтому дальше проверим кодировку соединения, sql запросом SHOW VARIABLES LIKE ‘character_set_client’. Замечу, что php функция mysqli_client_encoding(), нам не подойдет, так как она отображает кодировку только на момент соединения.
3. Если кодировка соединения не совпала с кодировкой одного из полей таблицы, то 2 очевидных варианта.
Если у нас все таблицы в одной кодировке, то проще поменять кодировку соединения .
А как исправить неверную кодировку поля таблицы?
Для этого выполним 2 запроса
|
ALTER TABLE files CHANGE sName sName BLOB; ALTER TABLE files CHANGE sName sName VARCHAR(128) CHARACTER SET utf8; |
Нельзя обойтись только вторым запросом. Важно выполнить оба. Первый преобразовывает данные в двоичные, второй запрос, преобразовывает данные в строковые сменив кодировку.. Т.е. по сути мы не измениили двоичные данные, мы изменили правило формирования символов. Если бы мы попробовали обойтись только вторым запросом, то получили бы ошибочный набор.
Исправляем ошибки кодировки таблиц
21.10.2021
1068
В результате проверки системы, Битрикс указал, что есть ошибки в Базе данных, но иногда автоматически он не может всё исправить, и тут приходится исправлять своими ручками.
Нажимая на знак вопроса мы видим подсказку от Битрикса где сообщает, что кодировка текущих наших таблиц, должна совпадать с кодировкой базы данных.
Если перейдем по ссылке на «журнал проверки системы», то увидим список тех таблиц, где не совпали кодировки, вот нам они и нужны, на скриншоте пометил стрелочками.
SQL запрос:
ALTER TABLE b_iblock_property_feature CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;Где b_iblock_property_feature — это название таблицы, у Вас могут быть другие.
Таким образом я выписал и составил список sql запросов для всех своих таблиц из журнала.
ALTER TABLE b_iblock_property_feature CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing_block CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing_demo CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing_domain CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing_file CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing_hook_data CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing_manifest CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing_placement CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing_repo CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing_site CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing_syspage CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing_template CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_landing_template_ref CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_main_mail_blacklist CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_main_mail_sender CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_messageservice_message CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_messageservice_rest_app CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_messageservice_rest_app_lang CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_mobileapp_app CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_mobileapp_config CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_numerator CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_numerator_sequence CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_rating_voting_reaction CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_rest_ap CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_rest_ap_permission CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_rest_app CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_rest_app_lang CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_rest_app_log CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_rest_event CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_rest_event_offline CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_rest_log CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_rest_placement CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_rest_stat CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_rest_stat_method CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_seo_service_subscription CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_user_profile_history CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_user_profile_record CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_utm_iblock_6_section CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_utm_iblock_8_section CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_uts_iblock_6_section CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE b_uts_iblock_8_section CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;После того как Вы собрали список SQL запросов, заходим в админку сайта битрикс (Настройки — Инструменты — SQL-запрос) или по пути, вставляете после адреса сайта /bitrix/admin/sql.php
Возврат к списку
Проблемы с кодировкой в базе данных
Не так давно я делал один сайт, и мне необходимо было сделать кодировку в базе данных UTF-8. Так я и сделал. Далее я поставил кодировку на сайте UTF-8. Всё казалось бы нормально, но при выборке данных из базы, они шли не в UTF-8, а в windows-1251. Разумеется, всё было в иероглифах. Я подумал, что решение этой проблемы с кодировкой в базе данных, необходимо Вам знать. И как раз об этом чуть ниже.
Если Вы используется UTF-8, то сразу после подключения необходимо выполнить всего лишь один запрос, но который исправит эту ошибку на корню. Вот он:
SET NAMES "utf8"
Он необходим, поскольку по умолчанию данные идут в кодировке windows-1251. И если Вам нужна windows-1251, то можете ничего не писать. Но если Вы используете UTF-8 (а я рекомендую использовать всё-таки эту кодировку), то обязательно после подключения выполните этот несложный запрос. Тогда проблемы с кодировкой при выборке из базы данных отпадут.
-
Создано 13.07.2011 14:41:36
-
Михаил Русаков
Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!
Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
- Кнопка:
Она выглядит вот так:
- Текстовая ссылка:
Она выглядит вот так: Как создать свой сайт
- BB-код ссылки для форумов (например, можете поставить её в подписи):
Проблемы с кодировкой на сайте часто встречаются после миграции с устаревшего серверного ПО (например, версии PHP) на новое.
Например, кодировка 1251 неактуальна для PHP старше версии 5.6. В связи с чем требуется изменение кодировки на UTF-8, которая является стандартом для последних версий PHP.
Если ваш сайт до миграции на наш хостинг работал в кодировке 1251, то при проверке системы вы можете видеть замечание: «Сайт работает в однобайтовой кодировке». Для исправления ситуации потребуется конвертировать сайт в UTF-8 или сделать изменения PHP-обработчика под кодировку 1251.
Следуйте шагам:
Исправьте настройки базы данных из панели 1С Битрикс в случае, если на странице /bitrix/admin/site_checker.php выводится ошибка: Ошибка! Кодировка базы (utf8) отличается от кодировки соединения (cp1251). [ Исправить ]
Если операция завершилась неуспешно, то повторно повторите исправление.
В редких случаях требуется ручное исправление из phpMyAdmin:
В панели хостинга в разделе «базы данных» перейдите в базу данных вашего сайта. После редиректа в phpMyAdmin войдите в раздел «операции» и в блоке «сравнение» выберите «utf-8_general_ci». Нажмите кнопку «вперед».
Редактирование php.ini для выбранной версии режиме PHP вашего сайта:
Убедитесь, что в настройках php.ini для выбранной версии PHP вашего сайта установлены значения:
Для варианта конвертации в utf-8:
mbstring.func_overload = 2
mbstring.internal_encoding = utf-8
default_charset = «utf-8»
Для варианта без конвертации (остается кодировка 1251):
mbstring.func_overload = 0
mbstring.internal_encoding = cp1251
default_charset = «cp1251»
Для однобайтовой кодировки (1251) также потребутеся отключить кодировку UTF-8 в панели хостинга в разделе «WWW-домены»:
Далее необходимо привести настройки согласно требуемой кодировке в файлах системы 1С Битрикс:
Для варианта корвертации в utf-8:
В /bitrix/php_interface/dbconn.php должно быть значение: define(‘BX_UTF’, true);
В /bitrix/.settings.php должно быть значение: ‘utf_mode’ => array (‘value’ => true, ‘readonly’ => true,),
Для варианта без конвертации (остается кодировка 1251):
В /bitrix/php_interface/dbconn.php полностью удалить значение: define(‘BX_UTF’, true);
В /bitrix/.settings.php должно быть значение: ‘utf_mode’ => array (‘value’ => false, ‘readonly’ => true,),
Решение, как исправить ошибку при штатной проверке системы в «1С-Битрикс», примерный текст ошибки «Сравнение для базы отличается от сравнения для соединения»
UTF-8
SELECT CONCAT('ALTER TABLE `', t.`TABLE_SCHEMA`, '`.`', t.`TABLE_NAME`, '` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;') as sqlcode
FROM `information_schema`.`TABLES` t
WHERE 1
AND t.`TABLE_SCHEMA` = 'db_name'
ORDER BY 1
Windows-1251
SELECT CONCAT('ALTER TABLE `', t.`TABLE_SCHEMA`, '`.`', t.`TABLE_NAME`, '` CONVERT TO CHARACTER SET cp1251 COLLATE cp1251_general_ci;') as sqlcode
FROM `information_schema`.`TABLES` t
WHERE 1
AND t.`TABLE_SCHEMA` = 'db_name'
ORDER BY 1
09.11.2021
После установки Битрикса на новый сервер возникла проблема, при «самопроверке» CMS, сообщение:
Ошибка! Кодировка соединения с базой данных должна быть utf8, текущее значение: utf8mb3
Сам Битрикс рекомендовал:
но в конфигурационных файлах все был прописано верно.
Проверка Битрикса выполняется через Настройки — Инструменты — Проверка системы (/bitrix/admin/site_checker.php)
.
В итоге пришлось решать вопрос исправлением файла bitrix/modules/main/classes/general/site_checker.php, в блоке ниже, заменил
utf8 на utf8mb3 и
utf8_unicode_ci на utf8mb3_unicode_ci
if (defined('BX_UTF') && BX_UTF === true)
{
if ($character_set_connection != 'utf8mb3')
$strError = GetMessage("SC_CONNECTION_CHARSET_WRONG", array('#VAL#' => 'utf8', '#VAL1#' => $character_set_connection));
elseif ($collation_connection != 'utf8mb3_unicode_ci')
$strError = GetMessage("SC_CONNECTION_COLLATION_WRONG_UTF", array('#VAL#' => $collation_connection));
}
Ошибка! Сравнение для базы (utf8_general_ci) отличается от сравнения для соединения (utf8_unicode_ci)
Время на прочтение
3 мин
Количество просмотров 22K
В связи с тем, что довольно много людей обращается с просьбой помочь исправить проблему с кодировками MySQL, решил написать статью с описанием, как «лечить» наиболее часто встречающиеся случаи.
В статье описывается не то, как первоначально правильно настроить кодировки MySQL (об этом уже довольно много написано), а о случаях, когда есть довольно большие таблицы с неправильными кодировками и нужно всё исправить.
Самое плохое в неправильно настроенных кодировках — то, что зачастую проблему сложно обнаружить, и с первого взгляда может казаться, что сайт работает правильно, и никаких проблем нет.
Небольшое отступление. Sypex Viewer
В какой-то момент надоело отправлять людей в громоздкий phpMyAdmin, и была написана крошечная утилитка Sypex Viewer. Она представляет собой один PHP-файл, использует современные Web 2.0 технологии AJAX, JSON и другие. Основные задачи, которые ставилась при создании — минимальный вес, и максимальное удобство и скорость работы. В дальнейшем в примерах будут скриншоты из неё, но все те же действия можно сделать и в phpMyAdmin.
Данные в cp1251 таблицы в latin1
Наверное, самая популярная проблема. Когда данные в кодировке cp1251 (Windows-1251), а у таблиц указана кодировка по умолчанию latin1. Такие ситуации возникают в следующих случаях:
- при неграмотном обновлении с версии MySQL меньше 4.1 на более новые;
- очень часто возникает в «буржуйских» скриптах, которых вполне устраивает кодировка по умолчанию, и они «забывают», что неплохо бы указывать кодировку, как таблиц, так и соединения;
- также бывают случаи, когда переезжают с одного сервера (у которого установлена дефолтная кодировка cp1251, в частности, так сделано в Денвере) на другой (у которого стоит стандартная кодировка latin1).
В результате на сайте вроде как всё нормально, но если посмотреть в Sypex Viewer, то русские символы будут выглядеть как «кракозябры» (как их обычно называют пользователи).
В статье я рассмотрю один из вариантов преобразование кодировок с помощью бесплатного php-скрипта Sypex Dumper, в качестве готового решения.
- На вкладке «Экспорт» выбираем нужные таблицы.
- Кодировка должна быть auto (остальные параметры неважны, можно комментарий добавить, например, «Дамп перед исправлением кодировки»).
- Нажимаем «Выполнить». Теперь у нас есть бэкап (его в любом случае желательно делать при любых преобразованиях базы данных).
- Переходим на вкладку «Импорт»
- Выбираем только что сделанный файл бэкапа.
- Выбираем кодировку cp1251 и помечаем опцию «Коррекция кодировки».
- Нажимаем «Выполнить».
- Вот и всё заходим в Sypex Viewer, чтобы убедиться, что русские символы выводятся корректно.
Данные и таблицы в utf8, но кодировка соединения latin1
Теперь рассмотрим более запущенный случай. Набирающая популярность в последнее время проблема, в связи с повальным увлечением UTF-8. Создатели софта стали переводить свои детища на UTF-8, но и тут не всё так гладко, как хотелось бы.
Возникает проблема в основном в случае, когда у таблиц указана кодировка UTF-8, данные в UTF-8, но кодировка соединения установлена по умолчанию latin1 (типичный пример, vBulletin 4, хоть там и есть в конфигах настройка кодировки соединения, но она закомментирована по умолчанию).
В результате в MySQL присылаются данные в UTF-8, но поскольку указана кодировка соединения latin1, то MySQL пытается преобразовать данные из latin1 в UTF-8. В итоге русские символы выглядят так:
Ситуация более запущенная, но исправляется проблема почти также, как в первом случае, только в пункте 2 нужно выбрать кодировку latin1, а в пункте 6 нужно выбрать utf8 кодировку.
Изменение кодировки
Также часто встречающаяся проблема преобразования кодировки из cp1251 в UTF-8. До выполнения этого шага обязательно убедитесь, что русские символы у вас правильно показываются в Sypex Viewer или phpMyAdmin, если это не так, то предварительно исправьте кодировку.
Итак, опять заходим в Sypex Dumper.
- Во вкладке «Экспорт» выбираем нужные таблицы.
- Устанавливаем кодировку, в которую хотите преобразовать таблицы, в данном случае utf8.
- Нажимаем «Выполнить».
- После чего заходим в «Импорт» и выбираем нужный файл.
- Выставляем кодировку utf8 и опцию «Коррекция кодировки».
- Нажимаем «Выполнить».
- Вот и всё таблицы в UTF-8. Не забываем, что нужно еще установить кодировку соединения, сконвертировать ваши скрипты и шаблоны в UTF-8, выставить правильную кодировку в заголовках.
Кодировка соединения
Не забываем, что после исправлений кодировки, нужно убедиться, что ваши скрипты используют правильную кодировку соединения (в принципе, это будет сразу видно, они будут неправильно показывать русские символы без нужной кодировки соединения). У некоторых она выставляется в настройках, в некоторых придется добавить самостоятельно.
Для чего достаточно пройтись поиском по файлам, и найти где вызывается функция mysql_connect (или mysqli_connect). После этой строки нужно добавить строку которая укажет кодировку соединения.
mysql_query("SET NAMES 'cp1251'");Где вместо cp1251, указать нужную кодировку соединения.
Не забывайте перед преобразованиями кодировок делать бэкап, тут как с презервативами, лучше пусть он будет и не понадобится, чем когда понадобится — его не будет.
P.S. Спасибо Шортикам за веселый контент для примеров.