MySQL 4.1.13

>Оттуда возьмётся, что по-умолчанию все клиенты в latin1

Если кто-то не может в my.cnf вписать:

character-set-server = utf8

default-character-set = utf8

то это уже клиника.

При чём в _нормальных_ дистрибутивах это вписано уже по умолчанию. "emerge mysql" - и у тебя настроенная под utf-8 система.

>А чтобы дать знать серверу о своей правильной кодировке, они должны слать дополнительный sql-запрос в каждом новом соединении. В консольном mysql-клиенте это можно обойти, прописав кодировку в конфиг, а для perl/php скриптов таких конфигов нет. Отсюда гимор при переходе на эту версию mysql.

Ты опять тёплое с мягким путаешь.

Если тебя удовлетворит одна, общая кодировка и для клиента, и для сервера - ставь нужную кодировку по дефолту в конфигк. И ничего посылать не придётся, никаких перекодировок не будет.

Если клиент по той или иной причине работает в кодировке отличной от дефолтовой и при этом хочет, чтобы сервер выполнил перекодировку - пусть сообщит об этом серверу. Не сообщит - получит неперекодированное.

Я не понимаю, в чём твоя проблема :)

>Для русского хостинга базы создавались в cp1251, и клиенты выводили инфу в этой кодировке. Подразумевалось, что и страницы выдавались в cp1251. То есть, всё работало по-умолчанию без ковыряния конфигов. Понятно, что такая схема сильно ограничена, но она _работала_ и не создавала гимор. Для расширения функциональности нужно было научить клинтов делать перекодировку в нужный для приложения чарсет. Это было бы лучше по очень многим причинам. Но mysql-разработчики сделали это через ж..., то есть через сервер.

Я хренею. Ну пропиши ты сервер 1251 по дефолту. И работай с ней без всяких перекодировок.

>Да ну что за хрень ты несёшь? При чём тут вообще программист? Вот жил сайт много лет, и на нём много лет крутились сотни скриптов. Обновили mysql до версии 4.1.12, и всё, весь сайт в кракозябрах. Хотя ничего не менялось. Я знаю, как это поправить глобально, но в любом случае - решение с трансляцией чарсетов на сервере - кривое.

А RTFM, конечно, слабО, да?

Сделать дамп старым сервером, включить в новом 1251 по дефолту и втянуть дамп, указав явно кодировку, что, Коран не позволил?

Ещё раз - в 4.1.x не хочешь - сервер ничего перекодировать не будет. Неужели так трудно поставить _общесистемную_ кодировку mysql в 1251 и работать с ним как с 4.0.x??

Нет, кажется мне, у кого-то голова явно не для тех целей, как у других, прикручена...

>mysql_query('set character set koi8r');

Да в его случае всё в 10 раз примитивнее. Ему хватит общей одной кодировки на весь сервер. Но он не умеет указать в mysql кодировку по дефолту для сервера, у него там latin1 откуда то :D

Вот, по дефолту "из коробки" под Gentoo:

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
7 rows in set (0.03 sec)

> Вот, по дефолту "из коробки" под Gentoo:

А ты уверен, что у тебя в [client] или в [mysql] ничего не написано? Лучше проверь, например, скриптом на php:

<?php
mysql_connect("localhost","login","password");
$res=mysql_query("show variables like 'char%'");
while($rec=mysql_fetch_row($res)) {
print($rec[0] . " = " . $rec[1] . "<br>\n");
}
?>

> А указать в конфигурационном файле можно для консольного клиента mysql, но попробуй указать кодировку для php скрипта... Он не читает .my.cnf ;)

Не читает. Настраивается сам сервак.

/etc/my.cnf

[mysqld]

character_set_server = cp1251

default_character_set = cp1251

character_sets_dir = /usr/share/mysql/charsets

language = /usr/share/mysql/english/

init_connect = "SET NAMES cp1251;"

И всё. Скрипты мнять не надо. Не работась с mysql пользователем с админоскими правами - для него не выполняется init_connect. Кстати, кто знает - последнне это фича или как? Её исправят?

Гы. Ну естественно, я уверен :D Я же говорил, что дефолт у меня - utf8. Но часть баз - 1251. А клиенты - utf8, 1251 и koi8-r. понятно, что те, кто 1251 или koi8 - должны сообщать о своей кодировке, т.к. она у них не дефолтовая. utf8 - без перекодирования :)

А твой пример:

Консоль: # php test.php character_set_client = utf8<br> character_set_connection = utf8<br> character_set_database = utf8<br> character_set_results = utf8<br> character_set_server = utf8<br> character_set_system = utf8<br> character_sets_dir = /usr/share/mysql/charsets/<br>

Браузер: character_set_client = utf8 character_set_connection = utf8 character_set_database = utf8 character_set_results = utf8 character_set_server = utf8 character_set_system = utf8 character_sets_dir = /usr/share/mysql/charsets/

:)

>Кстати, кто знает - последнне это фича или как? Её исправят?

Кхм. Никогда SET NAMES не использовал. Работало всё. В т.ч. когда и 4.1.x по дефолту юзал 1251 (на utf-8 перешёл после того, как с 1251 всё заработало на 4.1.2, кажется.)

> Я хренею. Ну пропиши ты сервер 1251 по дефолту. И работай с ней без всяких перекодировок.

Я тоже хренею. По-русски никто не понимает. Читайте по-английски:
http://dev.mysql.com/doc/mysql/en/charset-connection.html

Не спасёт тебя определение дефолтной чарсета на сервере!

> init_connect = "SET NAMES cp1251;"

Прально. Это спасает. Я не говорил, что это невозможно. Только криво
это. И дополнительный запрос на каждой соединение.

>Я хренею. Ну пропиши ты сервер 1251 по дефолту. И работай с ней без всяких перекодировок.

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

> понятно, что те, кто 1251 или koi8 - должны сообщать о своей кодировке, т.к. она у них не дефолтовая. utf8 - без перекодирования :)

О, наконец-то, и до жирафа дошло ;))

> Кхм. Никогда SET NAMES не использовал. Работало всё.

Оно работает. Только в таблицах latin1 светит. И mysqladmin их кракозябрами показывает. Дам опять же им и штатными средствами кривой снимается. А работать - работает. Вот это и не нравится...

P.S. Для рута не SET NAMES не работате, для него вообще init_connect не обрабатывается. Вот это и напрягает, ибо она не только для SET NAMES может использоватся...

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

Ну, во-первых, мне глубоко начхать на них, а во-вторых, опять же ты не
понял мысль, которую я толкал. Пусть на сервере базы создаются в любой
возможной кодировке! Это хорошо, это надо. Но пусть сервер шлёт данные
AS IS без перекодирования, пусть он лишь сообщает клиенту, в какой
кодировке он их шлёт, а клиент сам решает, во что их перекодировать.
Так понятно? ;)

> P.S. Для рута не SET NAMES не работате, для него вообще init_connect не обрабатывается.

Точно. И этот момент бесит больше всего. Сделано всё так криво, как
только можно было, если очень сильно постараться ;)

Мне пришлось лезть в исходники phpmysqladmin'a и принудительно вставлять
SET NAMES... Спасибо светлым головам из Mysql AB ;-(

> Сделать дамп старым сервером, включить в новом 1251 по дефолту и втянуть дамп, указав явно кодировку, что, Коран не позволил?

> Ещё раз - в 4.1.x не хочешь - сервер ничего перекодировать не будет. Неужели так трудно поставить _общесистемную_ кодировку mysql в 1251 и работать с ним как с 4.0.x??

> Нет, кажется мне, у кого-то голова явно не для тех целей, как у других, прикручена...

KRoN73, плевать если меня забанят - но ты дибил...

Оно у тебя работает в utf-8 потому что у тебя сервер скомпилен с параметром configure --with-charset=utf-8. Если я соберу у себя с cp1251, то у меня тоже будет работать, но у меня mysql уже собранный и даже не с utf-8, а с latin1. А то что ставится в конфиге для сервера - не работает, проверял на нескольких дистрибах. То что ставится в конфиге для клиента не читатется php, поэтому имеем - php не говорит серверу своей кодировки и сервер ему выплевывает все знаками вопроса в latin1. Хотя из консольного клиента все пашет замечательно. Если ты сможешь решить такую проблему без пересборки mysql и дописывания лишних строчек в скрипты, то я буду очень рад.

> Кстати, кто знает - последнне это фича или как? Её исправят?

Таки да, у них оно называется "фича". Оправдываются так: типа если
всё будет совсем плохо, и кодировки запутаются, то рут хотя бы
по-английски чота в каментах об ошибках прочесть сможет ;)
Короче, костыль на костыле и костылём подгоняет.

Чем больше юзаю, тем больше сомтрю в сторону:
postgresql
Может я не прав?
но ИМХО (не пробуя) там прикольней.

ЗЫ
Есть у кого реальный опыт там и тут?
Разница ощутима?
В чем?
+/-

поебилдил, чета не вставляет

А как тогда сервер ORDER BY выполнять? Для разных кодировок ведь разный порядок сортировки...

> При чём в _нормальных_ дистрибутивах это вписано уже по умолчанию. "emerge mysql"

Это крута, конечно, про нормальные дистрибюутивы и emerge ;) А пацаны-то
и не знают (c).

> А как тогда сервер ORDER BY выполнять? Для разных кодировок ведь разный порядок сортировки...

для этого выставляется collation и порядок сортировки почти одинаков для всех кодировок языка(если рассматривать символы, а не их коды), сам подумай...

Начиная с 4.1 как раз и есть.

> А как тогда сервер ORDER BY выполнять? Для разных кодировок ведь разный порядок сортировки...

Ты не догоняешь. На сервере база создаётся и сортируется в нужной
кодировке, с нужным character collation (не знаю, как это по-русски).
Он отдаёт клиенту данные, уже отсортированные правильно. Клиент
перекодирует лишь конечный результат. Ему не надо ничего сортировать.

>Ну, во-первых, мне глубоко начхать на них, а во-вторых, опять же ты не понял мысль, которую я толкал. Пусть на сервере базы создаются в любой возможной кодировке! Это хорошо, это надо. Но пусть сервер шлёт данные AS IS без перекодирования, пусть он лишь сообщает клиенту, в какой кодировке он их шлёт, а клиент сам решает, во что их перекодировать. Так понятно? ;)

Мне, к счастью, не чхать, потому что они мне тоже деньги приносят. Ну а на счёт кодировок правильного ответа на вопрос нет. Всё зависит от ситуации. То, что многие сайты портятся после апгрейда с 4.0.x на 4.1.x -- Факт.

>Не спасёт тебя определение дефолтной чарсета на сервере!

Остаётся только удивиться, почему меня лично - спасает. И уже больше года спасает.

>>init_connect = "SET NAMES cp1251;" >Прально. Это спасает. Я не говорил, что это невозможно.

Никогда не использовал. Тем не менее - всё рабоает.

>Это хорошо, когда у тебя одни MySQL-сервер, обслуживающий один проект.

Так у человека, поднявшего шум, именно такая ситуация. Он вообще, "как в 4.0" хочет. Один сервер, одна кодировка. У меня же, как я упоминал, две серверных и три клиентских кодировки. Но в _таком_ случае, как я уже упоминал тоже, клиент _обязан_ или сообщить свою кодировку, или сам перекодировать из дефолтовой.

>О, наконец-то, и до жирафа дошло ;))

Нет. Это ты опять путаешься. Я привёл тебе один частный пример с кодировкой utf-8. Но никто не запретит тебе прописать также cp1251. И если клиент явно не укажет кодировку, отличную от серверной, то получит её без всяких перекодировок.

>Оно работает. Только в таблицах latin1 светит

Ха. Так в таблицах? Дай угадаю. Общесистемная кодировка у тебя - latin1. В дампах кодировка не указана. Параметр --with-character-set (или как он пишется) у mysql при втягивании дампа ты не знаешь. Поздравляю! www.mysql.com -> документация -> ...

>Мне пришлось лезть в исходники phpmysqladmin'a и принудительно вставлять SET NAMES

Кошмар. Или это, всё же, альтернативные дистрибутивы такие кривые?

emerge mysql

emerge phpmyadmin

webapp-config -I phpmysqladmin 2.6.2

Всё работает из коробки. При чём всё на русском. Всё в текущей системной кодировке (у меня - utf8)

>KRoN73, плевать если меня забанят - но ты дибил...

Приятно познакомиться.

>Оно у тебя работает в utf-8 потому что у тебя сервер скомпилен с параметром configure --with-charset=utf-8

А кто тебе мешает скомпилить со своей кодировкой??

>но у меня mysql уже собранный

А кто тебе мешает собрать его самому??? Кто из нас дебил-то? :D

>А то что ставится в конфиге для сервера - не работает, проверял на нескольких дистрибах.

У меня работало всегда. Ещё с альфа-версий (на 4.1.x сел с ~4.1.2)

...

Нет, смешно, ей богу, если человек криво собранный mysql сам собрать не может, а mysql в этом обвиняет. Это кранты.

А общее резюме - если лениво работать ручками - ставьте Gentoo.

В защиту разработчиков MySQL можно сказать только то, что точно так же устроена работа с кодировками в Оракле.

Я, конечно, понимаю, вся рота идет не в ногу...

> Чем больше юзаю, тем больше сомтрю в сторону: postgresql Может я не прав?

Да прав, но есть такая проблема: наши желания часто ограничиваются
нашими физическими возможностями. Мало распространён постгрес. Часто
получается так, что выбора просто нет. С точки зрения программирования
есть плюсы и минусы у обеих субд. Mysql поприятнее местами, особенно
на этапе отладки приложения.

>Это крута, конечно, про нормальные дистрибюутивы и emerge ;) А пацаны-то и не знают (c).

Нормальный дистрибутив - это тот, в котором всё из коробки пашет. А не тот, который порождает потом дикий поток бреда с latin1 :D

Кстати, для теста поменял одну строчку в my.cnf на cp1251:

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | cp1251 |
| character_set_results | utf8 |
| character_set_server | cp1251 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
7 rows in set (0.00 sec)

Опять всё работает. Так что - или в дистрибутивах дело кривых, или в руках кривых...

>То, что многие сайты портятся после апгрейда с 4.0.x на 4.1.x -- Факт.

Факт. Потому что настоящие c00l-h4ck-админы никогда не читают RTFM. И переносят дампы старых баз не озаботившись _однократным_ контролем кодировки.

>...консольном mysql-клиенте это можно обойти, прописав кодировку в конфиг, а для perl/php скриптов таких конфигов нет.

Парень, ты крут. Наверное и пароли прямо в код вставляешь...

Про php не скажу, это тебе видней должно быть, а в perl это делается так:

DBI->connect("DBI:mysql:database=***;mysql_connect_timeout=5;mysql_read_ default_f ile=***/.my.cnf")

> Так у человека, поднявшего шум, именно такая ситуация. Он вообще, "как в 4.0" хочет.

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

> Но никто не запретит тебе прописать также cp1251. И если клиент явно не укажет кодировку, отличную от серверной, то получит её без всяких перекодировок.

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

> >Мне пришлось лезть в исходники phpmysqladmin'a и принудительно вставлять SET NAMES
>Кошмар. Или это, всё же, альтернативные дистрибутивы такие кривые?

Бля, ну сказали же человеку по-русски, что не работает init-connect
для суперпользователя. И на англицкую доку ссылку дали. Ну что тебе
после этого ещё можно сказать? А не пошли бы вы далеко, сэр? Как об
стенку горох.

> Всё работает из коробки. При чём всё на русском. Всё в текущей системной кодировке (у меня - utf8)

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

> Кстати, для теста поменял одну строчку в my.cnf на cp1251:

mysql> show variables like '%char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | utf8 |

И снова дебил. Смотри первую строку.

> Опять всё работает. Так что - или в дистрибутивах дело кривых, или в руках кривых...

Может, у тебя вообще только эти 3 кодировки? Попробуй так изменить my.cnf (не трогая разделы [client] и [mysql]), чтобы character_set_client стал равен cp1251.

>Тот человек (то есть - я) всего навсего хотел нормальной обратной совместимости. Чтобы сервер не додумывал за клиента, какой чарсет для него лучше. По принципу: не знаешь - шли как есть, не выдумавая никакой отсебятины.

Так и будет. Только хоть кто-то должен сказать серверу, что раз он теперь понимает _разные_ кодировки, то пусть, мол, этот дамп всосёт в такой-то.

Повторюсь, что телепатический модуль - в mysql сервер ещё не встраивали.

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

Что мне ещё проверять, когда у меня сервер, при переходе на 4.1 в таком режиме месяц, наверное, работал? :D Пока я дефолтовую кодировку сервера и основных клиентов с 1251 на utf8 не сменил.

>Бля, ну сказали же человеку по-русски, что не работает init-connect для суперпользователя

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

>Ты точно непроходимый дремучий дебил. Я уж не знаю, как с тобой вежливо разговаривать. Да, да, в твоих условиях с полным utf-8 кругом и с принудительной компиляцией под utf-8 оно будет работать. Всё, пока, больше нет сил на тебя тратить. Уже слона можно было научить на велосипеде кататься.

вот только ещё вопрос, кто из нас дебил. Т.к. система совершенно адекватно работает и при голом 1251 на mysql-сервере. Для дебиолв поясняю: серверу похрену, какая кодировка прописана в конфиге. Какая прописана - в той и будет работать. А слово latin1 я вообще последний раз во времена RH7.3 видел :D

> Нет, смешно, ей богу, если человек криво собранный mysql

Криво собранный? Ух-ты. Не знал... Смотрим:

# mysqladmin version
mysqladmin Ver 8.41 Distrib 4.1.12, for pc-linux-gnu on i686
Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB

Сборка от производителя, однака...

> сам собрать не может

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

Или вот:
# mysqld --version
mysqld Ver 4.1.12-standard for pc-linux-gnu on i686 (MySQL Community Edition - Standard (GPL))

Напиши им, скажи, что криво собирают свою и без того кривую субд ;)

Смотри выше, тебя уже ткнули носом в твои же настройки. Там ничего 
с точки зрения клиента не поменялось. Реально для cp1251 клиента сервер 
должен выдавать:
+--------------------------+------------------------+
| Variable_name            | Value                  |
+--------------------------+------------------------+
| character_set_client     | cp1251                 |
| character_set_connection | cp1251                 |
| character_set_results    | cp1251                 |

Только эти параметры важны.

> Парень, ты крут. Наверное и пароли прямо в код вставляешь...
> Про php не скажу, это тебе видней должно быть, а в perl это делается так:
DBI->connect("DBI:mysql:database=***;mysql_connect_timeout=5;mysql_read_ default_f ile=***/.my.cnf")

Я крут? Это ты крут! Скажи, в винде такая конструкция работает? И ещё
скажи, куда ты суёшь этот my.cnf, если к примеру сервер работает от
юзера nobody?

> В защиту разработчиков MySQL можно сказать только то, что точно так же устроена работа с кодировками в Оракле.

В какой версии оракла? Всю жизнь через ж там работали кодировки.
Как сейчас помню траходром с 7-ым ораклом. Гланды вырезались через
задний проход.

> Кстати, для теста поменял одну строчку в my.cnf на cp1251:

а теперь возьми php и попробуй из него получить с mysql-я данные в cp1251 не выдавая специальных запросов о смене кодировки... спорим у тебя данные в utf-8 посыплются...

ЗЫ у меня на большинстве серверов тоже генту, но без USE="utf-8", поэтому у меня дефолтная latin1, ебилд почитай. А правка ебилдов это изврат - раз поправил, потом через полгода дыру нашли, обновляешь mysql, а поправить-то и забыл уже...

>а теперь возьми php и попробуй из него получить с mysql-я данные в cp1251 не выдавая специальных запросов о смене кодировки... спорим у тебя данные в utf-8 посыплются...

Конечно, посыплются. Клиенты же сейчас сконфигурены по дефолту в utf-8.

>но без USE="utf-8"

Ну так и ССЗБ :D XXI век на дворе.

...

>Скажи, в винде такая конструкция работает?

Что? Да-да, конечно, CPAN под виндой уже не пашет. Аха.

>если к примеру сервер работает от юзера nobody?

Так под виндой, или mysql работает от nobody? Впрочем, даже если такого заведёшь и запустишь от него - доступ выдать нельзя, да?

>Напиши им, скажи, что криво собирают свою и без того кривую субд ;)

Тогда это у тебя руки 100% кривые. Пока на Gentoo не перешёл - пользовался их сборками вперемешку со своими. В зависимости от того, насколько срочно обновлялся. И всегда всё работало. Сперва в голом cp1251, потом - в смешанных кодировках.

Глюк был только один раз, кажется, на MySQL 4.1.7beta. Там это был именно глюк, который поправили в течении нескольких дней.

>А я что, пионер какой-нибудь, чтоб руками собирать софт, который всю жизнь от брал готовый от производителя/дистрибутора?

А ну да... да...

>>а теперь возьми php и попробуй из него получить с mysql-я данные в cp1251 не выдавая специальных запросов о смене кодировки... спорим у тебя данные в utf-8 посыплются...

>Конечно, посыплются. Клиенты же сейчас сконфигурены по дефолту в utf-8.

??? какие клиенты? php? и где ты в нем кодировку выставляешь?

> Что? Да-да, конечно, CPAN под виндой уже не пашет. Аха.

Ты глянь сначала на конструкцию, а потом говори. Путь к конфигу прописан
жестко.

> Так под виндой, или mysql работает от nobody?

Дык это второй вопрос. На этот раз про юникс... Сложно, да? Я херею,
дорогая редакция.

> Впрочем, даже если такого заведёшь и запустишь от него - доступ выдать нельзя, да?

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

>>но без USE="utf-8"
>Ну так и ССЗБ :D XXI век на дворе
Это не аргумент, кстати.

> Ха. Так в таблицах? Дай угадаю. Общесистемная кодировка у тебя - latin1. В дампах кодировка не указана. Параметр --with-character-set (или как он пишется) у mysql при втягивании дампа ты не знаешь.

Какой умный... Сташно аж! Системаня у меня - koi8-r. И на это есть причины. Системуную таблицу mysql сам создал в utf-8. А вот пользовательские, из 3.x дампов, где без charset'а - создал в latin1.

Насчёт параметра --with-character-set - не повешишь, но было уже похер. Локальный клиент (mysql) выдавал кракозябку вне зависимости от того указывался этот параметр или нет. При этом через сам php (4.3) всё работало нормально.

Так что, господин самый умный, пусть не считает себя умнее других.

Объяснения по поводу того в чём хранить данные - просьба оставить при себе, когда заёмёшься чем-нидуь реальным, особенно включишься в проекто который уже х.з. сколько тянется, тогда посмотрим. А руссуждения сверху, мол юзайте utf-8 - это "сферические кони"...

Насколько я понял, это недоработка в MySQL. Переменная default_character_set в секции [mysqld] действительно устанавливает глобальную кодировку сервера в ту, что указано (ВСЕ character_set_*), но вот у _клиента_ существует замечательная возможность еще при установке соединения указывать кодировку, какую нужно использовать (то есть, не SQL-запросом, а в процессе процедуры соединения). MySQL-клиент всегда шлет то, что в него вшито. Это несмотря на то, что сервер может распознать случай, когда клиент не прислал никакой кодировки (а только в этом случае клиенту будут назначены системные параметры сервера).

>>DBI->connect("DBI:mysql:database=***;mysql_read_default_file=*** /.my.cnf")

>Я крут? Это ты крут! Скажи, в винде такая конструкция работает? И ещё скажи, куда ты суёшь этот my.cnf, если к примеру сервер работает от юзера nobody?

Винды у меня нет. Однако, не вижу никаких оснований по которым это там не должно работать. Если файл явно указать, конечно. Это, очевидно, ответ и на второй вопрос.