Павел, вдруг сразу знаете в чем может быть проблема.

Пытаюсь установить Ваш форум на другой хостинг, которым управляю не я, а сторонний администратор.

Копирую файлы, настраиваю права на папки, настраиваю setup_option.php, запускаю Ваш _install.php, таблицы создаются, вхожу а Admin-ку, в профиле админа заполняю любое текстовое поле по-русски, сохраняю. В профиле все вижу правильно отображается. Смотрю, что произошло в БД через phpMyAdmin. И вижу, что русский текст стал кракозябрами.


Копирую их, прогоняю через онлайн перекодировщик текста, он исправляет текст и пишет: "исходная кодировка: UTF-8, отображается как Win-1252".


Ну и обратная ситуация, если в БД в это текстовое поле я ввожу русский текст, то в профиле админа вижу '????????'

Пишу стороннему админу, в чем может быть проблема, вместе пытаемся разобраться.
Я думал, что phpMyAdmin так отображает, но дело в том, что другие таблицы из CMS системы, установленной там же и работающие с UTF-8, через этот phpMyAdmin отображают русский текст нормально.

Сравниваю настройки таблиц, вашей и одной из CMS, вроде все совпадает.




Делаю запрос на настройки кодировок сервера:
SHOW VARIABLES WHERE variable_name LIKE '%character_set_%'

Вижу, что кодировка сервера не UTF8.
character_set_server = latin1
Сторонний админ говорит, что на хостинге с десяток систем, и ни у кого не было проблем, все системы сами делают при установке правильные настройки своих таблиц.

Смотрю Ваш скрипт создания таблиц. Да, там нет никаких указаний относительно кодировок, наверное, берутся по-умолчанию с сервера. Все просто "Create table". Кстати, я пытался в ваш запрос добавить "ENGINE=MyISAM DEFAULT CHARSET=utf8" - это тоже не помогло.

Убеждаю стороннего админа поменять настройку character_set_server на 'utf8'.
Меняет, проверяю эту настройку. Вижу изменения.

Снова запускаю Ваш _install.php, таблицы создаются, делаю ту же проверку. И получаю те же кракозябры :(

Сторонний админ утверждает, что нужно сменить форум на другой :)
Пишет "Содержимое выглядит так, будто форум перед вставкой обработал это iconv'ом или чем-то подобным"

Я беру весь код, копирую к себе на VDS, устанавливаю у себя. Проверяю тем же "макаром". Все отлично! Никаких кракозябр. Я остаюсь при мнении, что сменить нужно не знакомый мне форму, а незнакомый мне чужой хостинг... Но это тоже целая проблема, т.к. потребуется перенос целой CMS ради форума.

Павел, может будут умные мысли? Может был такой опыт?

MiniBB необязательно может работать с utf8. В новой версии это так, но в предыдущих у нас была кодировка latin, и до сих пор в downloads много переводов для других кодировок. Поэтому в инсталляции этого и нет. Кодировки сервера вы должны сами выставлять, какие нужно. База создается на их основе.

Навскидку я не вспомню команду, можете погуглить по фразе "mysql character set utf8", вам нужно после создания базы вручную заставить работать mysql с нужной кодировкой, и только потом инсталлировать форум.

Спасибо, Павел.
Настраивать сервер у меня нет полномочий.
Выкрутился, модифицировав Ваш код.
База создалась и после теста внесения русских слов в поля, я вижу, что в БД они тоже по-русски!

Добавил одну строку в setup_mysqli.php
......
$mysqlink = mysqli_connect($DBhost, $DBusr, $DBpwd) or die ('<b>Database/configuration error.</b>');
.....

Это не касается настройки сервера. В коммандной строке phpMyAdmin касаемо базы нужно исполнить один query, какой конкретно, сейчас не могу подсказать, но его можно легко нагуглить. После этого character_set_server как на скриншоте выше, должен быть utf8. Если он остается latin, при этом вы записываете utf8, то при бэкапе могут быть проблемы. Вам нужно только добиться того, чтобы эта настройка была utf8, и для этого был какой-то простой запрос. Тогда все должно работать без доп.кодов (я сталкивался с вашим решением и это не самый лучший вариант, хотя визуально вроде бы и все в порядке).

Здравствуйте, Павел.

Дело в том, что на том сервере utf8 уже везде, где только возможно.
Настройку character_set_server в utf8 по моей просьбе сторонний администратор сразу добавил. Но это, к сожалению, не помогло.

Текущие настройки:
Variable_name Value
character_set_client utf8
character_set_connection utf8
character_set_database utf8
character_set_filesystem binary
character_set_results utf8
character_set_server utf8
character_set_system utf8
character_sets_dir /usr/share/mysql/charsets/

Я нашёл команду, которую использовал в своих скриптах:

Т.е. сначала создаёте базу, потом выполняете эту команду, и только потом инсталлируете форум.

Если даже и после этого не будет работать, то трудно сказать, в чём дело. Возможно, криво что-то отображает phpMyAdmin. Прежде всего, всё это имеет значение для бэкапов. Попробуйте сделать бэкап какой-нибудь небольшой таблицы, где есть utf8-символы. И посмотрите его обыкновенным Notepad'ом. Если они будут корректно отображаться в бэкапе, то и всё нормально... в чём смысл проверять что-то в phpMyAdmin? Если на сайте всё работает и в бэкапе всё ок, то не понимаю, что ещё нужно. mysql-клиентов много, в чём смысл каждый из них проверять на работоспособность :)

Я написал небольшой скриптик для проверки charsets и collations в базе данных mysql, попробуйте у себя запустить. Отмечу, что на наших форумах и вовсе стоит вот это:

character_set_client: latin1
character_set_connection: latin1
character_set_database: utf8
character_set_filesystem: binary
character_set_results: latin1
character_set_server: latin1
character_set_system: utf8

Как видите, это не мешает нормальному функционированию utf-8... Также и нормальному восстановлению бэкапа на локальный сервер. Правда, есть нюанс - на локальном сервере mysql у меня так же настроен по умолчанию в latin1. Наверное, всё это не совсем стерильно, но оно так работает годами, а phpMyAdmin у нас нет, поэтому меня несильно парит то, что там могло бы отображаться :)

Еще - а вы уверены, что в исходниках HTML в тэге <meta> стоит UTF-8? Вот такое должно быть:

Если вы установили русский языковый пакет из текущих Downloads, то там по умолчанию стоит:

Именно тогда и будет такой эффект, какой у вас появляется.

(Само собой, никаких iconv в самом движке нет, это всё эффект от входящих данных, кодировка которых не соответствует вашей базе).

Здесь я уверен, все в порядке.

Да, это здорово, на своем хостинге я именно так и поступал. Вначале создавал отдельную БД с нужными настройками для MiniBB, затем запускал установку скрипта. И там и не было вышеописанной проблемы.

Но здесь у меня чужой shared хостинг где я не админ, БД уже какая есть, другой создать не было прав. Поэтому я просто подключался к существующей БД и ее реквизиты указывал в настройках, и Ваш скрипт просто создавал таблицы в этой БД, где также хранятся таблицы CMS, использующейся на сайте. И вот тут пошла нестыковка. CMS тоже работает с UTF8, и в ее таблицах я вижу через тот же самый phpMyAdmin русские буквы нормально. А в только что созданных таблицах MiniBB я видел "кракозябры".

Ну, в общем я для себя решение нашел для данной ситуации.

Первым делом я решил дополнить miniBB Manual для следующей версии, чтобы уложить как-то это, прежде всего, в своей голове :) Не помню, когда я в последний раз занимался UTF-скриптом и базой, но пока вспоминал, откопал ещё одну вещь. В базе данных есть такие параметры, как collation_*. Так вот, выяснилось, что свою-то локальную базу для тестов я просто не обновил командой, которую упоминаю выше. Поэтому для начала я пофорсил это в PHP, как вы и предложили. Но потом я вспомнил про collation_*, обновил скрипт проверки и убедился в том, что база просто не пропатчена этой командой. Я её пропатчил, убрал добавленное в в setup_mysqli.php - и всё, заработало как нужно.

Теперь я на 99.99% уверен, что с конфигурацией вашей базы примерно то же самое, т.е. character_set_* настроены, а вот collation_* - нет. Запустите скрипт у себя БЕЗ комманды, которую вы добавили в setup_mysqli.php. С большой долей вероятности, у вас будет:

А должно быть, как минимум:

И посмотрите, что будет, если в setup_mysqli.php оставить mysqli_set_charset.

Все эти огрехи кроются именно в неверной конфигурации mySQL. Обманка вставки mysqli_set_charset кроется в том, что если вдруг по какой-то причине ваша БД вернётся в "нормальную правильную" конфигурацию, то откатить уже введённые данные будет очень сложно. Так что лучше всего, как я и писал с самого начала, правильно настроить mySQL, а искусственно химичить что-то в PHP - это последнее дело.

Добрый день, Павел.
Свою команду отключил. Результат Вашего скрипта:

user037 : (название БД)

character_set_client: latin1
character_set_connection: latin1
character_set_database: utf8
character_set_filesystem: binary
character_set_results: latin1
character_set_server: utf8
character_set_system: utf8
character_sets_dir: /usr/share/mysql/charsets/
collation_connection: latin1_swedish_ci
collation_database: utf8_general_ci
collation_server: utf8_general_ci

Как бы минимум есть:
collation_database: utf8_general_ci

Но сейчас на форуме текст из БД отображается "вопросиками"

Результат с включенной строкой mysqli_set_charset($mysqlink, "utf8");

user037 :

character_set_client: utf8
character_set_connection: utf8
character_set_database: utf8
character_set_filesystem: binary
character_set_results: utf8
character_set_server: utf8
character_set_system: utf8
character_sets_dir: /usr/share/mysql/charsets/
collation_connection: utf8_general_ci
collation_database: utf8_general_ci
collation_server: utf8_general_ci

Вы же писали:

Оказывается, всё совсем не так. Все соединения клиента к базе по умолчанию у вас latin1. Тогда логично, что в phpMyAdmin, с этим режимом, вы видите не уникод, а другие символы.

И всё верно, если "чистый" уникод, введённый в базе, откатить обратно на соединение latin1, то вы увидите знаки вопроса вместо символов.

Так что вместо mysqli_set_charset очень желательно, конечно же, правильно настроить базу. Чтобы скрипт проверки показывал все возможные значения как utf8. Но если это невозможно сделать, остаётся лишь пользоваться искусственной надстройкой. Как это может повлиять на производительность и корректность работы базы, мне трудно сказать. В своих скриптах я стараюсь этого избегать и никому не рекомендую что-то искусственно подкручивать в php.

Добрый день, Павел.
На текущем хостинге нет прав настроить БД.