Вопросики вместо русских букв

[nemo]

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

[surfman]

Хостинг ispserver, росийский.
Почти год назад игрался с этим магазином. Сделал все на локалке(установка, настройка, и тд). В БД все нормально, русскими буквами, на сайте все нормально. А как перенес на хостинг, то выводит крякозябли.

Все остальные скрипты работают нормально. Если попросить хостера чтото поменять(кстате, какие настройки должны быть?), отобразится ли это на других скриптах?

[nemo]

surfman, я к сожалению некомпетентен в настройках серверов, но возможно вам поможет вот эта тема ,
где человек спрашивал советов по похожей проблеме на этом же хостинге.

[surfman]

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

[Alex]

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

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

[surfman]

Не через перенос точно. Я это делаю Dumper 1.0.8, делал всегда.
Надо добится того, чтобы в БД записывался нормальный русский. Как я говорил, раньше я настроил магазин на локалке, и тогда в БД все было в нормально. Перенес на хостинг. В БД на хостинге Dumper перенес нормально, но на сайте крякозябли.

С того времени несколько раз перестанавливал локалку, так теперь и на локалке коряво в БД записывает.

Этот третий - может ли это настройки my.ini? или это может быть отдельный какойто процесс?

[Alex]

Не через перенос точно. Я это делаю Dumper 1.0.8, делал всегда.
Надо добится того, чтобы в БД записывался нормальный русский. Как я говорил, раньше я настроил магазин на локалке, и тогда в БД все было в нормально. Перенес на хостинг. В БД на хостинге Dumper перенес нормально, но на сайте крякозябли.

С того времени несколько раз перестанавливал локалку, так теперь и на локалке коряво в БД записывает.

Этот третий - может ли это настройки my.ini? или это может быть отдельный какойто процесс?

Посмотрите с каким параметром дампер сохраняет таблицы.... скорее всего latin1... и все дело в нем, проверено на личном опыте!

[surfman]

Да причем тут дампер. Мы его пока не трогаем. Нужно сначала разобраться, почему в БД сохраняются нерусские слова. ТОесть установили магазин, создали категорию, а в БД(через ПХПМайадмин) смотирим, а там не русский.
Вот часть из my.ini

[client]

port=3306
character-sets-dir="\usr\local\mysql5\share\charsets\"

[mysql]

default-character-set=utf8


# SERVER SECTION
# ----------------------------------------------------------------------
#
# The following options will be read by the MySQL Server. Make sure that
# you have installed the server correctly (see above) so it reads this
# file.
#

[mysqld]

# The TCP/IP Port the MySQL Server will listen on
port=3306


#Path to installation directory. All paths are usually resolved relative to this.
basedir="\usr\local\mysql5\"

#Path to the database root
datadir="\usr\local\mysql5\Data\"

init-connect="SET NAMES utf8"
# The default character set that will be used when a new schema or table is
# created and no character set is defined
default-character-set=utf8

# The default storage engine that will be used when create new tables when
default-storage-engine=MYISAM

# Set the SQL mode to strict
# sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_E NGINE_SUBSTITUTION"

[Maestro]

Nemo прав - вопрос в корректности переноса БД, но и не только в нем.
Когда создавали на хосте БД - вы какую кодировку выставили по умолчанию для нее?
Если на хосте по умолчанию создается БД с UTF-8, то, естественно, на сайте будет в кракозябрах, поскольку ViArts работает на СР-1251. У меня именно так и получилось в первый раз. Так что создавать ЧИСТУЮ базу на хосте нужно с кодировкой СР-1251.
Тогда этих проблем ни при переносе, ни при последующих дампах не возникнут.

[nemo]

Александр, surfman сообщал вначале, что устанавливал скрипт в utf--8(заменив перед установкой языковые файлы на аналогичные в utf--8), а не в 1251, как при установке по умолчанию. Поэтому не всё так просто....

[surfman]

параметры я указывал в первом сообщении http://forum.viarts.ru/showpost.php?p=3992&postcount=38

[Maestro]

Прошу прощения, лопухнулся насчет первого поста.

У меня именно такой глюк с кодировкой вылазил на Joomla-единичке, при том почти с такими же вариациями. Сейчас трудно вспомнить точную последовательность действий, что я делал, но начинал точно с БД - слил ее с хоста на локаль и пересохранил для уверенности в utf-8. Потом обнулил на хосте базу, сделал из пересохраненной дамп и залил на хост, предварительно еще раз перепроверив все языковые настройки и файлы конфигурации.
Может, эта информация поможет...

[surfman]

Значит решается двумя вариантами.

1.В конфиг мускула my.ini добавляем skip-character-set-client-handshake
или
2. В файл includes\db_mysql.php после 66 строчки добавляем
mysql_query("SET CHARACTER SET utf8");
mysql_query("SET SESSION collation_connection = 'utf8_general_ci'");
mysql_query("SET NAMES utf8");
ТОест получается

} else {
$this->LinkID = @mysql_connect($server, $this->DBUser, $this->DBPassword, $new_link);
mysql_query("SET CHARACTER SET utf8");
mysql_query("SET SESSION collation_connection = 'utf8_general_ci'");
mysql_query("SET NAMES utf8");
}

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

[phpdude]

2. В файл includes\db_mysql.php после 66 строчки добавляем
mysql_query("SET CHARACTER SET utf8");
mysql_query("SET SESSION collation_connection = 'utf8_general_ci'");
mysql_query("SET NAMES utf8");

достаточно 1 строчки

mysql_query("SET NAMES utf8");

[sys]

А кто мне подскажет, почему регулярыне проблемы возникают именно с распознованием utf-8 ???

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

C windows -1251 я такого как раз не замечал.

[nemo]

А кто мне подскажет, почему регулярыне проблемы возникают именно с распознованием utf-8 ???
Т.е с списьмами или страницами, бывает открываешь страницы,с мотришь билиберда, долго мучаешься, хотя в браузере все на автомате стоит

Уточните, на каких страницах, где билиберда? Если, к примеру, речь о названии некоторых блоков-модулей (заголовков), названия российской валюты, платёжной системы, типа пользователей после установки скрипта, то дело в установочном файле дампа БД. туда, в отличии от оригинальной версии, были внесены некоторые доаолнительные демо данные на кириллице. Вот эти данные и записываются при установке в utf-8 билибердой. Не нравится скрипту при установке в utf-8 кириллица, хотя после установки сохраняет и перезаписывает всё нормально.

[sys]

Пардон, я имел ввиду не конкретно Viart, а проблемы с UTF вообще.
Везде упоминают, что это дает преимущества, но почему то проблемы возникают регулярные, к примеру приходит письмо в кодировке ютф, а майл клиент распознает его как виндовз из-за неправильного заголовка.

Я не понимаю всей этой технической ерунды, но факт фактом, письмо становится вообще не читаемым!

[nemo]

Преимущества есть, но есть и "побочные эффекты", к примеру для хранения одного и того же объёма информации в случае с UTF-8 места в БД потребуется больше, чем для windows -1251.

[nemo]

Просьба к пользователям, которые используют на своих сайтах Viart Shop в кодировке UTF-8!
Проверьте, не возникает ли у вас проблем при отправке скриптом сообщений, уведомлений, точнее, нет ли проблем с кодировкой при прочтении таких полученных сообщений.

[static]

Как не пытался, применял все описанные способы, так всё равно в админке вижу вопросы вместо букв, кодировка utf-8