проверьте следующее сайт использует точно туже базу что и PMA через который Вы выгружаете данные, посмотрите конфиги сайта, бывает что база рально расположена на другом хосте а PMA конектится к localhost на котором лежит битая база

Сайт использует точно ту же базу, вариантов быть не может - сайт является внутренним корпоративным порталом, и web и база хостятся на одном принадлежащем конторе сервере. Поэтому и PMA наш.

В браузере автовыбором установлена кодировка Юникод.

Ммм... А как это можно узнать? Прошу сильно не бить, я с PMA да и вообще с MySQL работал очень мало. А делать надо...

"Как нам пришлось помучиться
CP1252 ? CP1251".

Как я понимаю, CP1252 - это то же, что и latin1.
Поле "Сравнение" во вкладке "Операции" имеет значение "latin1_swedish_ci".

Запрос SHOW VARIABLES LIKE 'character%' возвращает:

character_set_client utf8 
character_set_connection latin1 
character_set_database latin1 
character_set_filesystem binary 
character_set_results utf8 
character_set_server latin1 
character_set_system utf8 
character_sets_dir C:\Program Files\MySQL\MySQL Server 5.1\share\char...

Windows XP SP3, PMA 3.2.4., MySQL 5.1.4, PHP 5.3.1.

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

Однако, у меня все равно не получается записать в таблицу в поле логин слово "Александр". Додумался до функции mysql_error(), и вот что Mysql выдает в браузере

Incorrect string value: '\xC0\xEB\xE5\xEA\xF1\xE0...' for column 'login' at row 1

что это значит пока не разобрался. Подскажите, если знаете, пожалуйста.

Еще раз отмечу, что open slaed ставится нормально, и там все буквы русские. Пытался разобраться в скриптах инсталляции, но ничего полезного так и не нашел; там mysql запрос INSERT помещен в отделный файл и подключен через file_get_contents и explode, потом запрос сводится к отделной текстовой переменной, которая вставляется в query. Знаю, что это глупо, но я применил этот прием, чтобы убедиться, что он не работает. ;-))) ...может я что и пропустил в скриптах установки...

Если значения глобальны, то проблем со скриптами в utf-8 не будет, надо только иметь в виду, что нельзя подключать скрипты через пользователя MySQL root, обязательно следует создавать отдельного пользователя наделенного только необходимыми привилегиями (нельзя выставлять привилегии из раздела "Администрирование").

В любом случае, всегда будет работать установка кодировки соединения прямо в скрипте. Сразу после функции mysql_connect следует добавить строку:
mysql_query('SET NAMES 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     C:\Program Files\MySQL\MySQL Server 5.1\share\char...

проблема в том, что я хочу использовать на своем локальном сервере utf8, но при данных настройках не проходят элементарные записи в таблицы mysql, то есть тупо хочу добавить русское слово (с английскими словами проблем нет) в таблицу базы данных (настройки и базы и столбцов в таблице и самой таблицы utf8), при этом php-скрипт ошибок не выдает - все на первый взгляд выполняется идеально, но в таблице (работаю с mysql 5.1.14 через phpmyadmin 3.2.4) никаких данных нет. Если все настройки с utf8 сменить на cp1251 - все нормально работает. И еще такой странный факт в директории character_sets_dir     C:\Program Files\MySQL\MySQL Server 5.1\share\char... нет файла utf8.xml. Подскажите, пожалуйста, в чем проблема.

Хочу еще добавить на мой взгляд важную особенность. При установки CSM Open Slaed на локальный сервер, а он использует кодировку utf8, проблем нет - базы данных создаются и буквы там русские - все как и положено.

Prutkov
В вашем случае выходит, что кодировка соединения с MySQL при работе Perl устнавливается в latin1. Не могу сказать по какой причине это происходит, но необходимо найти функцию соединения с MySQL и сразу после нее прописать запрос устанавливающий корректную кодировку соединения с помощью запроса SET NAMES utf8.

спасибо!

дамп есть конечно, и конвертнуть не проблема, спасибо!

все таки перловка виновата...

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

видимо надо искать изначальную причину в работе Perl и MySQL, и это при том, что в поделке нет ни строчки с latin1 и вообще с любой кодировкой, как впрочем и у MySQLMan.

пока прописал строку
init-connect="SET NAMES UTF8"
в my.cnf

помогло, но(!) опасаюсь, что некорректно поведут себя php скрипты работающие с другими базами, где данные хранятся в кодировке cp1251
на первый взгляд вроде пока все в норме.

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

Если подключение идет через DBI, то ищем что-то вроде:
$connect = DBI->connect($dsn, $user, $pw);
И со следующей строки пишем:
$query = "SET NAMES utf8";
$query_handle = $connect->prepare($query);
$query_handle->execute();

Либо ищем что-то вроде:
$connect = Mysql->connect($host, $database, $user, $pw);
И добавляем со следующей строки:
$execute = $connect->query('SET NAMES utf8');

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

PHP скрипт по перекодировке можете найти здесь - http://forum.php-myadmin.ru/viewtopic.p … 8664#p8664
Процесс трудоемкий, так как потребуется перекодировать каждое поле, которое содержит крякозябы, но пока другое решение мне не известно.

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

Выполните запрос и посмотрите вывод.
Надо, чтобы кириллица была видна полностью. Иногда бывает, что некоторые символы пропадают заменяясь на знаки вопроса, в этом случае их тоже не восстановить (во всяком случае, я не знаю как это сделать). Посмотрите как данные выглядят именно на исходном сервере, с которого сделан дамп.

SET NAMES latin1;
SELECT * FROM `users`;

Здравствуйте.
Чудом нашел этот топик, хоть какая-то ниточка :)

Суть проблемы:
кракозябры в phpmyadmin'е (только в нем!)

но только в одной базе, с которой работает перловая "поделка" :)
при этом вывод данных работает корректно, т.е. русский текст отдается как и должен.
Вобщем работает все нормально, но если надо подправить данные с помощью phpmyadmin'а - это не представляется возможным.

Во всех других базах русский язык phpmyadmin отображает корректно (с остальными базами работает php)

параметры:
perl 5.8.8
MySQL 5.1.30

и SHOW VARIABLES LIKE 'character%'
и SHOW GLOBAL VARIABLES LIKE 'char%'
дают:
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

доступ к my.cnf есть

Собсно почему обращаюсь к Вам, потому как этот запрос

SET NAMES latin1;
SELECT * FROM `users`;

дает отображение УЖЕ НОРМАЛЬНОГО русского текста в этой базе, так в чем же может быть причина?
может можно что-нить подправить в пхпмайадмине?

с перловой поделкой расстаться не могу, так как на нем висит важный и древний(собсно как и сама поделка) проект, и... когда-нить я перепишу все на пхп, когда у меня будет пару-тройку месяцев свободных, ибо там 15Mb перлового кода.

По коду не нашел ни чего похожего ни на latin1, ни на utf8, а что-то другое править рука не поднимается :)

Кстати, когда еще была третья версия мускуля, таких проблем не было, и phpmyadmin отображал все корректно, правда тогда все было на cp1251.
И еще одно, в поделке есть встроенный MySQLMan(перловый Web-интерфейс к базе данных Mysql) - вот он зараза, отображает все корректно, но работать в нем, это как ложкой окопы копать.

Помогите, пожалуйста, понять, куда сунуть руки :)

спасибо