BiTel

Запросы, выполняемые через SQL редактор клиента биллинга почему-то выводят текстовые поля в нечитаемом виде.
Очевидно где-то используется неправильная кодировка, это неожиданно, так как те же данные в других местах биллингом выводятся нормально.

Можно как-то повлиять на кодировку в SQL редакторе?

для начала простой запрос..

Криво выводит ?
Потом что у вас в

и в

1.select title from contract
выводит конечно криво. но при прямом запросе в mysql, равно как и при отображении в просмотре или редактировании договора - отображение корректное.


2.show variables like "%char%"

character_set_client utf8
character_set_connection utf8
character_set_database latin1
character_set_filesystem binary
character_set_results
character_set_server latin1
character_set_system utf8
character_sets_dir /usr/share/mysql/charsets/

3. по умолчанию, из скрипта инстралера ->
contract CREATE TABLE `contract` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`gr` bigint(20) NOT NULL DEFAULT '0',
`title` varchar(150) NOT NULL DEFAULT '',
`title_pattern_id` int(11) NOT NULL DEFAULT '0',
`pswd` varchar(32) NOT NULL DEFAULT '',
`date1` date DEFAULT NULL,
`date2` date DEFAULT NULL,
`mode` tinyint(4) NOT NULL DEFAULT '0',
`closesumma` decimal(10,2) NOT NULL,
`pgid` int(11) NOT NULL DEFAULT '0',
`pfid` int(11) NOT NULL DEFAULT '0',
`fc` tinyint(1) NOT NULL DEFAULT '0',
`comment` varchar(100) NOT NULL DEFAULT '',
`del` tinyint(1) NOT NULL DEFAULT '0',
`scid` int(11) NOT NULL DEFAULT '0',
`sub_list` text NOT NULL,
`sub_mode` tinyint(4) NOT NULL DEFAULT '0',
`status` tinyint(4) NOT NULL DEFAULT '0',
`status_date` date DEFAULT NULL,
`last_tariff_change` datetime DEFAULT NULL,
`crm_customer_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
KEY `date1` (`date1`),
KEY `title` (`title`),
KEY `del` (`del`),
KEY `scid` (`scid`),
KEY `crm_customer_id` (`crm_customer_id`)
) ENGINE=InnoDB AUTO_INCREMENT=22975 DEFAULT CHARSET=utf8

Вы запросы из нашего sql-редактора делали ? почему у вас кодировка базы latin1 ? А кодировка таблицы в utf8 ? а помесячные свежие таблицы посмотрите в каких кодировках. Вы специально переходили на utf8? у нас вроде как раньше по умолчанию cp1251 шла.

посмотрите вывод

там большой вывод большая часть таблиц в кодировке utf8_general_ci (могу прислать полный вывод).

web_menu InnoDB 10 Compact 2 8192 16384 0 0 0 4 2015-01-15 17:05:59 utf8_general_ci
----------------------------------------------------------------------------------------------

однако есть странность.
-----------------
inet_session_log_account_1_201501 InnoDB 10 Compact 912 179 163840 0 262144 0 latin1_swedish_ci partitioned
inet_session_log_route_1_201501 InnoDB 10 Compact 0 0 16384 0 16384 0 1 2015-01-15 17:03:19 latin1_swedish_ci
inet_tariff_traffic_max_detail_1_201501 InnoDB 10 Compact 8 16384 131072 0 0 0 latin1_swedish_ci partitioned
--------------------------------------

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

но всё равно, это, так понимаю ещё одна проблема, а таблица contract к примеру ->
contract InnoDB 10 Compact 16682 158 2637824 0 1589248 4194304 22975 2015-01-15 16:58:26 utf8_general_ci

1. да
2. да? а я кодировки cp1251 у себя вообще никогда не видел.. нигде.. только utf8

Прикрепите полный вывод пожалуйста.

Так у вас нет проблемы в contract, у вас все таблицы в utf8, но недавно вы поставили кодировку базы latin1(может обновляли ) и они начали создаваться в latin1. Надо кодировку базы сделать тоже utf8. Это предположение, чтобы сказать точнее нужен полный вывод.

Что касается sql-редактора, то он не не работает в версии 6.0 если кодировка не cp1251. Потому что раньше все работали на cp1251 -рекомендуемая кодировка.
Начиная с 6.1 мы исправили дефолтную кодировку(кто работал на cp1251 на ней же и остался) на utf8 и поправили sql-редактор. По идее можем поправить и sql-редактор а 6.0.

1. Почту скажите, а то сюда *.csv не даёт положить.
2. Да ввести настройку кодировки переменной в конфиге было бы круто...

не факт, лучше через дефолтную кодировку БД ее задавать .

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

sql редактор исправим в ближайшее время и выложим обновление.

Все настройки всех кодировок были выпилены начиная с 6.1 (их было около десятка), почти везде где предполагается какая-либо кодировка - должна быть кодировка UTF-8.
Обновление для 6.0 будет в ближайшее время.

_________________
I'm clever. I've got a computer.

появилось ли обновление?
а то у меня есть проблемы с кодировкой ещё и в журнале ошибок модуля phone, что особенно неприятно...
при том логи других модулей пишутся нормально..

Обновление для sql-редактора выложено.

Журнал ошибок давайте разбираться с таблицей. Вы поменяли latin1 ? что показывает



где yyyyMM - код и месяц, когда наблюдаются проблемы.

у меня нет такой таблицы.
а данные, что выводятся не в той кодировке, как я понимаю тут -> data_log_error_201502;

MariaDB [bgbilling]> show create table data_log_error_201502;
+-----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| data_log_error_201502 | CREATE TABLE `data_log_error_201502` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`dt` date NOT NULL DEFAULT '0000-00-00',
`hh` tinyint(4) NOT NULL DEFAULT '0',
`mid` int(11) NOT NULL DEFAULT '0',
`source_id` int(11) NOT NULL DEFAULT '0',
`msg_title` varchar(100) NOT NULL DEFAULT '',
`msg_data` text NOT NULL,
PRIMARY KEY (`id`),
KEY `mid_dt_hh_source` (`mid`,`dt`,`hh`,`source_id`)
) ENGINE=InnoDB AUTO_INCREMENT=65 DEFAULT CHARSET=latin1 |

при этом ->

MariaDB [bgbilling]> show variables like "%char%";
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
---------------------------------------------------------------------------------------------------------------------------

mysql не стартует, если напрямую в конфиге указывать character_set_database = utf8

Да, возможно ошибся с таблицей.

Так вы до сих по не поменяли character_set_database?? Т.е у вас помесяные таблицы продолжают создаваться не в той кодировке. Она не задается в в конфиге, она меняется как alter database, у каждый базы своя кодировка , ее нельзя задать в конфиге. В конфиге можно указать только кодировку сервера (работает по умолчанию для создания новых баз). Кодировка базы используется по умолчанию для создания новых таблиц(у вас они в latin1 и создаются). Поменяйте кодировку базы наконец, потом проверьте все помесячные таблицы за январь и февраль и поправьте там кодировку alter-ом если нужно . Старые данные уже скорее всего испорчены.

да давно б поменял, но если mysql указать в server.cnf (my.ini)
character_set_database = utf8

она просто не стартует и всё.

еще раз. НЕ НУЖНО ТАМ ЭТО УКАЗЫВАТЬ. И правильно что не стартует, НЕТ ТАКОЙ НАСТРОЙКИ в server.cnf (my.ini) . Там нельзя указать, так как там настойки сервера, а не базы(на одном сервер может быть много баз и bgbilling одна из них ), кодировка базы хранится в самой базе скорее всего . Вам нужно запустить запрос.