Кодировка MySQL
 

Дошли наконец руки до обновления трекера с версии 1 на 2, после вечера танцев с бубном удалось обновится без потери инфы. Но в процессе ковыряния обнаружил что инфа в базе хранится в виде непонятных крякозябров(
посмотрел инфу по кодировке базы и увидел вот такую картину
https://vbtorrents.org/attachment.ph...1&d=1264348557
Я так понимаю что проблема из-за того что в некоторых местах выставлена кодировка latin1. Попробовал кучей разного софта и скриптов дампить базу чтобы конвертануть и залить обратно но все дампы нормально не перекодируются(
Из-за этой проблемы в постах бывает изредка коверкаются 1-2 символа - потому и хочу решить. Может кто-то подскажет как безболезненно слить дамп в кодировку UTF-8 ?

FeNUMe, sypex dumper-ом
но перед заливкой обратно советую проверить дамп на кодировки таблиц (не на данные внутри, они после сайпекса должны быть в одной кодировке, а на свойство самих таблиц -если не те, то просто отредактировать как надо)

пробовал уже разными версиями sypex dumper(и с форсированой перегонкой в ср1251/утф8) - результат один и тотже
вот такое в дампе. если заливаю на старый сервер(откуда дамп) - все нормально отображается. на сервер с другими кодировками - сплошные глюки

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

FeNUMe, при любой перегонке кодировки надо точно понимать из какой в какую кодировку перекодируешь. Главное в дампе получить везде русские читаемые данные (скорее всего будут в utf кодировке). А позже уже заниматься правкой свойств таблиц в дампе и заливкой дампа назад. Иногда приходится заливать дамп по частям, т.к. если уж слишком много кодировок, то сайпекс их на автомате не разгребет, т.е. в одном дампе один кусок в нормальной кодировке, в другом - другой.

советую проверить тип поля peer_id в таблице peers - скорее всего остался старый, соответственно стата не будет считаться.
Насчет раздачи - мне нужен точный конфиг сети, чтобы дать ответ.

у peer_id действительно был неверный тип - сменил, сегодня потестирую статистику.
На счет раздачи разобрался я просто с одним и тем же паскеем пытался на 1 компе раздавать а на втором качать)

И как ни странно практически удалось победетить проблему с кодировками: получил читабельный дамп через сам форум, после заливки его - данные в базе стали читатся как надо(везде кодировка утф8) но при этом форум отказался работать)))

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

поискал в гугле по ошибке мускула и пока нашел 1 решение - править init.php как тут https://vbsupport.ru/forum/showthread.php?t=23843 тогда все работает как надо. пока протестил на vb3.7.4

в vb3.8.4 вместо этого костыля поставил в config.php
теперь абсолютно все у меня в utf8 - надеюсь в будущем теперь проблем не возникнет. да и нагрузка на базу уменьшиться должна за счет уменьшения количества автоперекодировок

по идее это:
$config['Mysqli']['charset'] = 'utf8';
должно и для 3.7.4 работать, т.к. разницы в классах работы с БД нет между 3.7 и 3.8
(может в 3.7 не работало потому что в конфиге булки стояло использовать mysql, а не mysqli ?)

эээ нет Skald, перегоняются только таблицы... данные в них остаются в той кодировки в которой были, для перекодировки самих данных есть спец мод для вБ

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

Сайпекс прекрасно экспортирует и импортирует для любых кодировок, и для перекодировок использует функционал мускуля. Только вот как я говорил надо полностью понимать принцип работы кодировок и принцип хранения данных в мускуле. Например при экспорте данных из latin1 если указать кодировку дампа по умолчанию (обычно utf) конечно получим на выходе совсем не те данные которые хотелось бы.
Но если указать кодировку дампа именно latin1, то внутри данные будут в cp1251 (хотя в свойствах таблиц будет указано latin1, т.е. придется править только свойство таблиц в дампе, а не сами данные), т.е. этот дамп уже можно нормально импортировать для получения нормальных данных в базе в правильной кодировке.

я знаю, я говорю что dumper не конвертирует сами данные

ладно. разговор ни о чем получается - сам дампер через PHP не конвертит, но он конвертит посредством MySQL, как следствие в общем можно упростить и сказать что это он конвертит.
Конвертация кодировок все-таки происходит в результате действий дампера :)))