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

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

Unix прекрасно работает с cp1251.

Неужели не очевидно, что данные приходящие в cp1251 (windows-1251) и сохраняемые в таблицы с кодировкой latin1 и utf8, просто никак не могут нормально работать?

Поначалу наивно полагал, что клиент отправлял данные в latin1_swedish_ci, а MySQL самостоятельно перекодировал и сохранял в utf8_unicode_ci.

Вот и я о том же. Он наверное не знает, что в моем случае сколько не перебирай кодировки (latin1, latin2, cp1251, utf8) в запросе "SELECT CONVERT( CONVERT( `name` USING binary ) USING кодировка) FROM `mytable`" русских букв не будет.

Как писал выше, указание любой кодировки не показывает русский. Вообще не знаю в какой он хранил данные, mysql_client_encoding возвращал latin1, пробовал в запросе - крягозяблы :shocked: .

Раз на сайте нормально показывает, сварганил за 1-1.5 часа свой дампер и импортировал с помощью phpMyAdmin. Вы были правы, появились русские буквы в phpMyAdmin, значит MySQL хранил в неправильной кодировке. Делаем вывод, что за правильную кодировку отвечает клиент, а MySQL только выделяет место под символ согласно указанной кодировке, и я думал, что с добавлением mysql_set_charset("utf8") проблема будет решена. Но запутался еще больше, теперь на сайте крягозяблы. Помогло только SET NAMES cp1251, при том, что функция mysql_set_charset("cp1251") почему-то не работает.

Тогда бы SET NAMES utf8 или mysql_set_charset("utf8") правильно читали кириллицу на сайте (после моей перекодировки в utf8).

Осталось не понятно, почему на каждой стороне по кодировке и за что отвечает каждая из них? Почему, если указать клиенту cp1251, то в БД пишется кодировка базы (utf8, latin1, cp1251), а если указать клиенту latin1, то непонятно что? Сайты не только на Win-хостинге, но и на Unix, сразу возникает вопрос, чем заменить cp1251 там?

Неужели не очевидно, что данные приходящие в cp1251 (windows-1251) и сохраняемые в таблицы с кодировкой latin1 и utf8, просто никак не могут нормально работать? Да, скрипты сайтов и форумов будут отображать кирилицу, но только потому что игнорируют кодировку таблиц передаваемую сервером, эта кодировка в них вероятно жестко прописана и задается с помощью запроса SET NAMES cp1251.

Для начала, статью писал человек, лучше вас и меня разбирающийся в MySQL и возможных проблемах с ней связанных, иначе она бы не появилась на данном сайте. Попробуйте для перекодировки использовать следующий запрос: SELECT CONVERT( CONVERT( `name` USING binary ) USING cp1251 ) FROM `mytable`;
Если он вернет кирилицу, то это будет означать, что в таблице данные лежат в cp1251.

Настроить сортировку можно только перекодировав все данные в cp1251 (если используется именно она). Нажав пару кнопок этого не сделать, даже у меня не всегда получается восстановить данные при подобных ситуациях. Все зависит от каждого отдельного случая. phpMyAdmin не показывает utf8, потому что в таблицах с данной кодировкой данные лежат в иной кодировке. Исходите из того, что в БД вы всегда имеете то, что в нее передается, а phpMyAdmin это всего-лишь отображает, и отображает верно. Всегда!

Да, упомянутая функция идентична запросу SET NAMES. Теперь уже не имеет смысла ее применять, так как данные лежат в неверной кодировке и никак не могут быть адекватно восприняты. Это надо было делать до установки скриптов. Теперь может помочь, как я уже говорил, только перекодировка.

$cfg[LoginCookieValidity] число [количество секунд]
Определяет как долго может длиться идентификация куки.
http://php-myadmin.ru/doc/config.html

Для проверки проблемы с куками укажите версии всех компонентов веб-сервера (Apache, MySQL, PHP, phpMyAdmin), а также локальный он или удаленный и какая ОСь. Последняя проблема с куками была исправлена в phpMyAdmin 2.11.0. Для начала проверьте на работоспособность последнюю версию.

Есть база с uft8_unicode_ci кодировкой. Сайты и форумы работают нормально, русский приходит русским, но не работает сортировка по строковому полю на сервере... кроме одного единственного phpMyAdmin, который русский в кодировке latin1_swedish_ci показывает нормально, а в uft8_unicode_ci крягозяблы.

Захожу на вашу страницу http://php-myadmin.ru/learning/mysql-cir.html, по симптомам похож на случай "MySQL ИСПОЛЬЗУЕТ НЕВЕРНУЮ КОДИРОВКУ". Выполняю запрос в phpMyAdmin: SELECT CONVERT( CONVERT( `name` USING binary ) USING utf8 ) FROM `mytable`, получаю те же самые крягозяблы, что и просто при просмотре таблицы (????????????). Читаю результат и решение, а там обязательно должны появиться русские буквы. У меня нет русских букв, кто составлял сие руководство?

Настройки кодировки не трогал, все по-умолчанию, на сервере:
character set client utf8
(Глобальное значение) latin1
character set connection utf8
(Глобальное значение) latin1
character set database latin1
character set filesystem binary
character set results utf8
(Глобальное значение) latin1
character set server latin1
character set system utf8

Как все-таки в моем конкретном случае настроить сортировку и почему только phpMyAdmin не хочет показывать правильно utf8, чем он лучше? В пхп появилась новая ф-ия mysql_set_charset, видимо тоже самое, что SET NAMES, выполнение mysql_set_charset("utf8") калечит ранее нормальный русский.

P.S. Забыл добавить, траблы с куками в phpMyAdmin реально достали. После 1-го захода частенько истекает время неактивности и он выходит, после чего ни в какую не хочет входить, сколько не брыкайся. Помогает только закрытие окна IE6SP1.

значит эти скрипты перед передачей данных правильно указывают их кодировку и здесь ничего трогать не надо.

Большое спасибо) теперь ясно.
Фух, все оказалось не так страшно - с Coppermine я как-нибудь уж разберусь - надо ее перевести в новую, ну и если надо ручками подправить.

Я просто хочу понять, чем грозит то, у меня сайт на Joomla и форум SMF отражаются на win-1251, а Сoppermine Gallery на UTF-8
Захожу в pma - UTF-8

MySQL у вас настроен на utf8 - это значит, что все данные с не заданной кодировкой будут восприниматься в utf8. Если Joomla и SMF в cp1251 работают хорошо, значит эти скрипты перед передачей данных правильно указывают их кодировку и здесь ничего трогать не надо. Если Coppermine записывает данные не корректно, значит они в БД так и передаются. Проверьте также кодировку таблиц в которых хранятся данные Coppermine.

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

information_schema - системная БД MySQL, которую нельзя трогать и данные в ней всегда находятся в utf8.

Я просто хочу понять, чем грозит то, у меня сайт на Joomla и форум SMF отражаются на win-1251, а Сoppermine Gallery на UTF-8
Захожу в pma - UTF-8

Точнее 
information_schema       utf8_general_ci
а моя БД
mysite_ru       cp1251_general_ci

Но несмотря на это если открыть таблицы БД, то там все почему-то в UTF-8

При этом почему-то именно в Сoppermine Gallery русские названия отображаются крякозябрами, а материал форума и сайта нормально.

Я просто уже запуталась.
Хотела поставить новую CMS (Joostina она заточена под win-1251), эту базу перевести в нужную кодировку полностью, но начиталась этого форума и в голове вообще каша.

Пример соединения к MySQL из документации PHP с добавлением строки определяющей кодировку передаваемых данных.

<?php
$link = mysql_connect('localhost', 'mysql_user', 'mysql_password');
if (!$link) {
    die('Could not connect: ' . mysql_error());
}
mysql_query('SET NAMES cp1251') or die(mysql_error());
echo 'Connected successfully';
mysql_close($link);
?>

Если у вас есть права на изменение конфигурации MySQL, то все можно сделать еще проще, достаточно добавить в раздел [mysqld] строку:
init-connect="SET NAMES cp1251"

И также в разделы [mysql] и [mysqld], эту строку:
default-character-set=cp1251

После данных изменений MySQL будет работать в cp1251 изначально.

с помощью функции mysql_connect

Извините, но для особо диких в этом людей можно нагляднее объяснить?

Вот собственно чего я вижу когда захожу в phpMyAdmin
У меня БД в UTF-8, а мне нужно в win-1251

Ice_Harley
Сразу после подключения к MySQL с помощью функции mysql_connect, необходимо выполнить запрос:
SET NAMES cp1251

Статья на данную тему - http://php-myadmin.ru/learning/mysql-cir.html

Спасибо огромное! Помогло!

Статья на данную тему - http://php-myadmin.ru/learning/mysql-cir.html

Ситуация такова:
сайт на PHP, работает и выводится в браузере в кодировке
charset=windows-1251

База данных MySQL 5.0.7, в системных переменных следующее:

[mono]
переменная                   сессия              глобальная
_____________________________________________________
character set client          utf8                 latin1 
character set connection  cp1251                latin1 
character set database    latin1                  latin1 
character set results       utf8                     latin1 
character set server       latin1                   latin1 
character set system      utf8                     utf8 
collation connection     cp1251_general_ci  latin1_swedish_ci 
collation database       latin1_swedish_ci  latin1_swedish_ci 
collation server         latin1_swedish_ci  latin1_swedish_ci [/mono]

И менять, судя по всему, глобальные значения я не могу.
В базе хранится нормальный русский текст - в phpmyadmin отображается нормально. Но если я получаю его через запрос в PHP, то выводятcя "???".

Я сделал:
[mono]
ALTER DATABASE `db_name` COLLATE cp1251_general_ci
ALTER TABLE `table_name` COLLATE cp1251_general_ci
ALTER TABLE `table_name` CHANGE `current_field_name` `new_field_name` VARCHAR( 100 ) CHARACTER SET p1251 СOLLATE cp1251_general_ci
[/mono]
для базы, всех таблиц и всех текстовых полей, но это не помогло. "Вопросики" остались...

Что можно сделать в таких условиях?

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