Для полноценной работы с UTF-8 там не хватает в начале файла объявления
global $db_character_set;
Это к сведению. Может привести к неверной кодировке при выдаче.
Версия smf и кусок кода где чего не хватает
Версия 1.1.6.
// We're going to want a few globals... these are all set later.
global $time_start, $maintenance, $msubject, $mmessage, $mbname, $language;
global $boardurl, $boarddir, $sourcedir, $webmaster_email, $cookiename;
global $db_server, $db_name, $db_user, $db_prefix, $db_persist, $db_error_send, $db_last_error, $db_character_set;
global $db_connection, $modSettings, $context, $sc, $user_info, $topic, $board, $txt;
$db_character_set добавлен мной. На UTF-8 я перешел только с этой версии и не могу сказать - были ли подобные проблемы в ранних версиях.
Думаю, что этот баг вылезает при require_once('..../SSI.php') не из глобального контекста, а из функции. И, конечно, важны настройки MySQL. У меня по дефолту кодировка клиента - latin1.
mysql> show variables like 'character_set%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | utf8 |
| character_set_filesystem | utf8 |
| character_set_results | latin1 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
Может конечно не прав но данная переменная нигде в SSI.php не употребляется для того чтобы ее в глобале объявлять так что тоже как и разработчики смысла особого не вижу в том чтобы ее в глобал поставить.
См. след.:
Если SSI.php вызывается из функции, то та вызывает Settings.php, который в свою очередь выполняется не в глобальном контексте.
Лучше объясню на примере.
file1.php
function my_func()
{
require_once('file2.php');
}
my_func();
config.php
$var1 = 1;
$var2 = 2;
file2.php
global $var1;
// global $var2; // а это объявить забываем
require_once('config.php');
function smf_func()
{
global $var1, $var2;
// $var1 == 1
// $var2 == null но никак не 2
}
Зато все было бы ОК, если бы в конфиге было либо объявление global для всех переменных конфига, либо использовался $GLOBALS.
config.php
$GLOBALS['var1'] = 1;
$GLOBALS['var2'] = 2;
$db_character_set используется в функции reloadSettings() из модуля Load.php - SSI.php вызывает его и именно там есть настройка кодировки подключения к базе.
угу в принципе нужно об этом просто сообщить разработчикам чтобы поправили.
на днях кинем в их раздел
во, тоже столкнулся с этой проблемой, при выводе в вордпресс (утф8) из базы форума (утф8) в вордпрессе показывались "??????"
Добавление "lobal $db_character_set; " решило проблему.
Кстати, сегодняшний апдейт до 1.1.7 не исправляет эту проблему. Также игнорирована проблема с не-ascii именами вложений: http://www.simplemachines.org/community/index.php?topic=136952.msg1717374#msg1717374
Уважаемый MavN, вы не забыли сообщить об этих багах разработчикам?
Бага всё ещё актуальна для всех версий, включая последнюю SMF 2.0.1.
Я уже давно забил на это и патчу код форума самостоятельно. Очень помогает в этом контроль версий и багтрекер. А выходящие патчи приходится накладывать руками, но учитывая, что они стали очень редки и малы, то затруднений это не вызывает. Зато все найденные пользователями баги патчатся без ожидания разработчиков.
У меня вообще сложилось мнение, что развитие SMF остановилось. В 2.0.x не наблюдаю качественного скачка (на который намекает major version), т.к. архитектура осталась той же, что и в 1.1.x, со всеми присущими ей недостатками.
Quote from: Mongoose on October 13, 2011, 07:13:13 AM
Бага всё ещё актуальна для всех версий, включая последнюю SMF 2.0.1.
вы правы, позавчера подключался к базе через SSI.php и столкнулся с знаками вопросов вместо русских букв :-\
исправилось при помощи:
$smcFunc['db_query']('', '
SET NAMES UTF8',
array(
)
);
Я невероятно благодарен тебе, чувак!!!