Перенос данных между My SQL версии 4.0 и 4.1

[Фанат]

Перенос данных между My SQL версии 4.0 и 4.1

Перенос данных между My SQL версии 4.0 и младше (далее 4.0-) и 4.1
Перенос данных из My SQL 4.0- в My SQL 4.1
Внимание! При правильно скомпилированном My SQL это не нужно, однако на Windows, где скомплировать затруднительно, крайне рекоммендуется использовать приведенный метод для предотвращения преобразования кодировки текста в latin1.
1) Сохранить базы с помощью mysqldump.
2) Обновить My SQL.
3) Залить базы с помощью «mysql -u user -p --default-character-set=cp1251 < dump.sql» (или установить default-character-set=cp1251 для mysql в my.cnf/my.ini, см. «установку» выше).

5) Важно понимать, что выполнение «SET NAMES кодировка» НИКАК не влияет на default_character_set который используется при СОЗДАНИИ таблиц по “CREATE TABLE” без указания charset и collation, они берутся из default-character-set my.ini/my.cnf. Чтобы это поправить нужно нормально настроить сервер (см. «установку» выше) или использовать комбинацию
SET NAMES кодировка;
SET character_set_database=кодировка;
SET character_set_server=кодировка;

чё-та у меня это не сработало нифига.
пока не прописал в CREATE TABLE руками CHARACTER SET cp1251 COLLATE cp1251_general_ci; - ни хрена не получалось

Это я дурак или написаное устарело?

 

[zerkms]

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

 

[Фанат]

хз. а как посмотреть? по старинке, desc table кодировку не показывает.
я определял по тому, что данные получались вопросиками.

 

[Pigmeich]

*****
SHOW CREATE TABLE?

-~{}~ 22.11.07 10:41:

Либо my.ini

 

[Фанат]

ну какой my.ini на хостинге?
вот в факе тоже - через слово - my.ini. "кто все эти люди? страшно далеки они от народа!"

-~{}~ 22.11.07 10:56:

Pigmeich
спасибо SHOW CREATE TABLE показывает, ага

zerkms
latin1
что пишешь эти команды, что не пишешь.
вот интересно, у меня-то была одна таблица в дампе. а если их сотни?
как же, все-таки, дефолтную кодировку при создании таблиц выставлять?

 

[zerkms]

SET NAMES кодировка;
SET character_set_database=кодировка;
SET character_set_server=кодировка;

*****
эти переменные (а точнее лишь одна из них) влияют на кодировку таблиц лишь косвенно
а именно:
character_set_server определяет кодировку вновь создаваемой БД (если она не указана явно)
а кодировка таблиц - будет такая же, как кодировка у БД (если, опять же, её не указать явно)

 

[Фанат]

Ну, а чего ж тогда этот текст в факе делает?

-~{}~ 22.11.07 16:14:

То есть, по хорошему, фак по кодировкам должен быть таким:

1. Данные из таблицы выводятся в виде ?????????????
set names=кодировка

2.Если новые таблицы создаются (из консоли, скрипта или дампа) не с той кодировкой, которая нужна (посмотреть можно командой SHOW CREATE TABLE), то
а. Если есть возможность, то попросить хостера создать БД заново, указав перед созданием
SET character_set_server=кодировка;
б. Если такой возможности нет, то кодировку таблицы задаем руками. Не забывая указывать и COLLATION

так?

 

[zerkms]

в. ALTER DATABASE (если хватит прав)

 

[Фанат]

а можно как-то посмотреть настройки database?

ага, нашел
use `database`
show variables like "character_set_database";
show variables like "collation_database";

-~{}~ 22.11.07 19:26:

едем дальше

Если заглянуть в интернет, то окажется, что проблема с кодировками в mysql, начиная с версии 4.1, является чуть ли не самой сложной в веб-программировании. постоянно у всех какие-то сложности.
И зачем было вводить эти кодировки? Нет, чтобы оставить все, как раньше - что в базу положил - то и достал, не заботясь, в какой оно кодировке.
Такая возможность, кстати, осталась (binary), но мы о ней не будем.

Итак. Кодировки в MySQL версий 4.1+.
На самом деле, все элементарно просто.
Mysql теперь знает, в какой кодировке она хранит данные.
Если говорить упрощенно, то таблица (а так же - отдельные поля в ней) теперь имеет такие параметры, как кодировка (CHARACTER SET) и сортировка (COLLATION)
Если класть в таблицу данные в другой кодировке - получатся вопросики. Если запрашивать в другой кодировке - появятся вопросики.
Вот и все.
Соответственно, нам надо сделать всего две вещи:
1. Убедиться, что у таблицы установлены нужные параметры кодировки и сортировки.
2. Сказать базе, в какой кодировке в неё поступают данные и из её .
Ответ на второй вопрос знают все: волшебный запрос
set names "кодировка"

Но ведь перед тем, как записывать данные в таблицу, надо сначала эту таблицу создать! Этот вопрос в интернете рассмотрен гораздо хуже. Исправим ситуацию.
Самое простое - это указывать кодировку и сортировку прямо в коде CREATE TABLE. Пример:
CREATE TABLE `chartest` (
`name` varchar(10) default NULL
) ENGINE=MyISAM DEFAULT CHARSET=cp1251 COLLATION=cp1251_general_ci

Но что, если у нас огромный дамп на сотни таблиц, сделанный в прошлой версии MySQL? Дописывать к каждой таблице вручную? Возможно, это и придется делать. Но сначала надо попробовать установить параметры по умолчанию.
Создаваемые таблицы, если для них не указывается collation и charset, берут эти параметры из настройки database.
Следовательно, надо попытаться изменить эти настройки.
сначала смотрим, какие они сейчас.
Заходим в консоль и пишем
use `mydb`
show variables like "character_set_database";
show variables like "collation_database";

Если полученный результат нас не устраивает, то пытаемся переопределить настройки самостоятельно
alter database `mydb` character set cp1251;
alter database `mydb` collate cp1251_general_ci;
если запросы прошли успешно, то проверяем ещё раз, и ,если все нормально, то начинаем создавтаь таблицы или заливать дамп.
Если таким образом сделать не удалось (не хватает прав), то варианта только два - или обращаться к провайдеру, чтобы он сам поменял настройки кодировки и сортировки, или дописывать COLLATION И CHARACTER SET ко всем таблицам вручную.

-~{}~ 22.11.07 20:59:

кто что скажет по вышенаписанному?

и еще вопрос.Какое вообще практическое значение имеет charset?
какое имеет collation - я понимаю
а charset?

из вышенаписанного следует, что важно совпадение кодировки таблицы и кодировки соединения. а уж какая она - дело десятое.
сейчас проверил - точно, в latin1 сайт работает, как ни в чем ни бывало.
в чем суть указания правильной кодировки, если это не мультибайт?

 

[Nelius]

Ну если я правильно понял суть вопроса, то в доках мускула на это пишуть:

The CHARACTER SET and COLLATE clauses make it possible to create databases with different character sets and collations on the same MySQL server.

А по поводу остального, мое мнение добавить этот текст в FAQ. Думаю многим будет полезен. =)

 

[Фанат]

Ну, процитированный кусок отвечает на вопрос, зачем нужны collations. а зачем нужен чарсет - не говорится.
Но я уже сам понял - колейшен без чарсета не работают.

 

[Nelius]

Вообще я считаю что все эти "замуты" с кодировками это лишнее. Наоборот надо стремиться к чему-то единому, а не тормозить этот процесс. С одной стороны да, удобно (правда я пока не встречал проекта где в одной таблице из 2-х полей типа TEXT одно было в utf-8 а другое в cp1251), но с другой стороны создание единого стандарта намного облегчило бы жизнь программистам и вообще многим людям.
Благо технологии, в наше время, уже достаточно развились для того чтобы можно было себе это позволить.
ИМХО

 

[ran]

>Но я уже сам понял - колейшен без чарсета не работают.
и в мануле даже четко написаны правила, по которым collation формируется для каждого charset:
There is a convention for collation names: They start with the name of the character set with which they are associated, they usually include a language name, and they end with _ci (case insensitive), _cs (case sensitive), or _bin (binary).

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

 

[Фанат]

http://www.linux.by/wiki/index.php/FAQ_PHP_MySQL_charset
вот, блин, пример фака по кодировкам 4.1+, каким он должен быть.
а то, что лежит в вики - это пример того, как не должно быть.

 

[vovanium]

Можно переносить дампером, он сам добавляет кодировку во все таблицы при их восстановлении, либо изменяет её, если был криво обновлен сервак, и в таблицах с кодировкой latin1 лежат данные cp1251.

 

[Фанат]

дампером - это не по-пацански.
задача не данные перенести.
задача - понять, что к чему.

 

[vovanium]

дампером - это не по-пацански

А что там понимать либо проставляешь кодировку в CREATE TABLE (что и делает дампер, там как бы никакой магии нет, при желании конечно это можно делать вручную).
Либо прописывать правильную кодировку по умолчанию для БД перед восстановлением.

 

[fixxxer]

чота вы все много написали

у таблички есть charset и collation

charset - набор символов, являющихся грубо говоря буквами языка (можут быть многобайтовые)
collation - их порядок (правило сортировки)

у клиента есть только charset, может не совпадать с серверным (например, клиент не понимает многобайтные кодировки), нужен для соответствующей перекодировки