https://slinkov.ru/openforum/vsluhforumID3/54770.html Представлен (http://permalink.gmane.org/gmane.comp.db.mysql.announce/479) MySQL 6.0.11 (http://www.mysql.com/mysql60/), последний релиз в ветке 6.0.x, находящейся на стадии альфа-тестировании и включающей в себя два новых движка - Falcon (http://www.mysql.com/why-mysql/white-papers/falcon-getting-started.php) и Maria (http://dev.mysql.com/doc/refman/6.0/en/se-maria.html). Среди новшеств версии 6.0.11 можно отметить добавление поддержки конструкций SIGNAL и RESIGNAL, определенных в SQL стандарте; включение в комплект новой утилиты mysqlbackup, отображающую информацию из резервных копий, созданных при помощи операции "BACKUP DATABASE" statement.<br><br><br>После выпуска данной версии MySQL Server переходит на <br>новую модель (http://forge.mysql.com/wiki/Development_Cycle) подготовки релизов в рамках которой будет развиваться единая тестовая ветка MySQL Trunk с более частым выпуском тестовых версий. Ранее практиковавшийся подход, когда в разработке нередко находилось одновременно несколько тес...<br><br>URL: http://permali https://slinkov.ru/openforum/vsluhforumID3/54770.html#28 Mon, 25 May 2009 12:53:41 GMT &gt;Заметил сейчас, оно выставило на столбец latin1. Возможно, был не прав, но <br>&gt;это же п**дец, господа. Бегать по всей БД рекурсивно и менять <br>&gt;кодировку каждому элементу, чтобы вдруг-чего-не-выставилось-в-дураццкий-дефолт... <br><br>Очень рад, что вы все же соизволили разобраться в вопросе. Потому что из-за таких лентяев и появляются не адекватные отзывы в адрес хороших продуктов.<br> https://slinkov.ru/openforum/vsluhforumID3/54770.html#27 Mon, 25 May 2009 11:17:36 GMT Вот интересно, ты с postgres перед тем как работать тоже ни разу в мануал не заглянул? :)<br> https://slinkov.ru/openforum/vsluhforumID3/54770.html#26 Mon, 25 May 2009 06:39:09 GMT Inside info:<br><br>Sun давно уже пытается реформировать процесс MySQL - сейчас стали видны результаты и для "внешних" потребителей.<br> https://slinkov.ru/openforum/vsluhforumID3/54770.html#25 Mon, 25 May 2009 05:40:24 GMT &gt;Повторяю, проблема с перекодировками, она у них генетическая, похоже<br><br>Проблема в ДНК тут скорее у того, кто не осилил чтение документации, а вместо себя винит разработчиков. Почему-то у тех, кто затратил хоть немного времени на беглый просмотр доки по этому вопросу, проблем с кодировками в мускуле не возникает. Причем в куда более экзотических случаях. Также не стоит ругаться на фичи, если их не понимаешь. Не нужны тебе, так не используй, никто за уши не тянет. А вот мне приходилось работать с базой, где поля в пределах одной таблицы имели разную кодировку. И представь себе никаких проблем с дампами(как csv так и sql) или приложением, которое кстати и адаптировать пришлось аж в одном месте. Как легко догадаться этим местом был запрос с set names. <br>Но конечно некоторым балбесам удается указать поле latin1, запихать в него cp1251, а потом ругаться на мускул, который следует дословно их указаниям, вместо чудес телепатии. Кстати для таких в доке мускула тоже есть инструкция по исправлению подобных косяков. <br> https://slinkov.ru/openforum/vsluhforumID3/54770.html#24 Mon, 25 May 2009 04:47:52 GMT Заметил сейчас, оно выставило на столбец latin1. Возможно, был не прав, но это же п**дец, господа. Бегать по всей БД рекурсивно и менять кодировку каждому элементу, чтобы вдруг-чего-не-выставилось-в-дураццкий-дефолт...<br> https://slinkov.ru/openforum/vsluhforumID3/54770.html#23 Mon, 25 May 2009 04:44:37 GMT mysql&gt; select * from directions limit 10;<br>+-----+--------+<br>&#124; id &#124; name &#124;<br>+-----+--------+<br>&#124; 749 &#124; ?????? &#124;<br>&#124; 750 &#124; ?????? &#124;<br>&#124; 751 &#124; ?????? &#124;<br>&#124; 752 &#124; ?????? &#124;<br>&#124; 753 &#124; ?????? &#124;<br>&#124; 754 &#124; ?????? &#124;<br>&#124; 755 &#124; ?????? &#124;<br>&#124; 756 &#124; ?????? &#124;<br>&#124; 757 &#124; ?????? &#124;<br>&#124; 758 &#124; ?????? &#124;<br>+-----+--------+<br>10 rows in set (0.00 sec)<br>------------------<br>Server version: 5.1.30-community MySQL Community Server (GPL)<br>Protocol version: 10<br>Connection: localhost via TCP/IP<br>Server characterset: utf8<br>Db characterset: utf8<br>Client characterset: utf8<br>Conn. characterset: utf8<br>------------------<br>CREATE TABLE `directions` (<br> `id` int(11) NOT NULL AUTO_INCREMENT,<br> `name` varchar(255) CHARACTER SET latin1 DEFAULT NULL,<br> PRIMARY KEY (`id`)<br>) ENGINE=MyISAM AUTO_INCREMENT=1123 DEFAULT CHARSET=utf8 AVG_ROW_LENGTH=24;<br>----- https://slinkov.ru/openforum/vsluhforumID3/54770.html#22 Sun, 24 May 2009 14:22:44 GMT &gt;Да, про то, что кодировку на базу выставить недостаточно, надо на каждую <br>&gt;таблицу отдельно (дополнительно к базе), это уже понятно. Собственно, требовалось: исходные <br>&gt;данные в cp1251, табличные данные в базе - в UTF8. Вывод <br>&gt;в последующем - в UTF8. Постгрес с задачей справился, но его <br>&gt;у нас никто не знает, поддерживать придётся самому. А мускль выдает <br>&gt;вопросы вместо букв. В общем, как была проблема с перекодировкой, так <br>&gt;со времен древних релизов и осталась. <br><br>Да не важно, в какой кодировке данные в базе. Если нужно вставлять в кодировке X, то перед вставкой - set names X. Если нужно получать в кодировке X - то перед селектами set names X.<br><br>А кодировку на таблицу можно не выставлять - таблица наследует кодировку от базы, столбцы в таблице - от самой таблицы.<br> https://slinkov.ru/openforum/vsluhforumID3/54770.html#21 Sun, 24 May 2009 14:17:32 GMT &gt;Ответы на что, на INSERT INTO ... ? <br><br>Ответы на селекты. Если база utf8, скрипт вставки выставил set names cp1251 и передает данные в cp1251 - то в базу всё попадает правильно (т. е. конвертится в ту кодировку, в которой таблицы - utf8 в данном случае). Скрипт который делает селекты должен выставить set names в ту кодировку, в которой хочет данные получать.<br><br>&gt;Почему такого геморроя нет в постгресе? И не надо брызгать слюной, как <br>&gt;один молодой и неокрепший выше, я _хочу_ использовать mysql, поскольку наши <br>&gt;девелоперы (которым в дальнейшем сопровождать) с ним хоть немного но знакомы, <br>&gt;но эти особенности не могут мне позволить этого сделать. <br><br>Это не геморрой, просто один раз достаточно понять, как в mysql построена работа с кодировками. На самом-то деле проблема гроша выеденного не стоит. Единственный реальный косяк с их стороны был в миграции с 4.0 на старшие ветки, но это уже в далеком прошлом. Ну и может недостаточно хорошо в мануале все написали.<br><br>И кстати возможность контролировать кодировку в https://slinkov.ru/openforum/vsluhforumID3/54770.html#20 Sun, 24 May 2009 14:13:16 GMT &gt;&gt;Читаем внимательнее, телепаты могут спать спокойно. Все нужные указания мусклю были даны: <br>&gt;&gt;что в базе, что в принимаемых данных. Мускль тупо забил на <br>&gt;&gt;эти указания. <br>&gt;<br>&gt;Вы же сами сказали - база utf8 (включая таблицы) а вы совали <br>&gt;cp1251. Это нормально, что у вас получаются вопросики. <br><br>Вот спецом сейчас проверил, благо сайты переезжают с виртуалки на дедик сегодня. Есть один сайт с мордой и базой в cp1251. Короче вопросики получил, так как вверху mysqldump файла стояло set names utf8 - когда поменял на set names cp1251, внутри базы все стало ок. Однако морда стала почти-адекватной только в utf8. Когда я допили файл CMS, отвечающий за открытие БД, и прописал первым запрос set names cp1251, сайт наконец стал адекватным в cp1251.<br><br>В общем идите курите, это проблема ваших кривых рук - вы просто не умеете пользоваться MySQL.<br><br>А тест к тому же доказал: set names нужно на вход и на чтение дергать.<br>