Форум MySQL

в русском это: И, с, я (заглавные С и Я и строчная и выводтся)
в греческом тоже несколько букв заменяются квадратиком с вопросиком.

если бы ВСЕ выводилось крякозябликами, легче было было бы. а что делать в этом случае?
в какой кодировке создана база, не знаю. таблицы создавались и из дампа и вручную с кодировкой utf8 и сравнением utf8_bin
скрипт управления на utf8, в ПМА тексты не читаются вовсе (кроме английских). хостер уверяет, что при utf8 "все должно быть нормально".
а оно не нормально! что делать?
и раньше делала на 3 и 4 языках сайты, но без utf8 как-то обходилась...

вот какие таблицы

а вот какая ошибка

Проверяйте дамп в первую очередь - нормально ли он был снят.

что показывает запрос

$res = mysql_query("SHOW VARIABLES LIKE '%char%'"); while($row = mysql_fetch_row($res))   echo $row[0] . ' = ' . $row[1] ."<br />\r\n";

в контексте Вашего конфига?



и что показывает тот же самый запрос после выбора БД и выполнения оператора SET CHARACTER SET?

mysql_select_db('ИмяБазы'); mysql_query("SET CHARACTER SET 'utf8'"); $res = mysql_query("SHOW VARIABLES LIKE '%char%'"); while($row = mysql_fetch_row($res))   echo $row[0] . ' = ' . $row[1] ."<br />\r\n";

а вообще же обычно если PMA ничего хорошего не показывает - значит в самой БД лежит каша, и только прикидывается текстом.

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

но после переговоров с хостером и его совета поменять collation на utf8_unicode_ci на всю базу скопом, ошибка убралась.

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

это была не ошибка, а глюк. в базе лежала не каша. сейчас я вижу это в ПМА.

>но после переговоров с хостером и его совета поменять collation на utf8_unicode_ci на всю базу скопом, ошибка убралась.

collation на utf8_unicode_ci на всю базу скопом force как минимум charset utf8 на эту базу.
А если он не стоял, то character_set_connection мог выставляться некорректно.

Я тоже предпочитаю front (c Вашей, кстати, подачи) .
Но пока что не сталкивался с тем, чтобы PMA показывал какую-то форменную лажу.
Если, конечно, этот PMA не совсем трухлявой версии...

а у меня MySQL-Front остался только на самом старом компе...
скоро поменяю его и она пропадет :(
но зато есть обновленная версия (под другим именем)
вот: http://www.heidisql.com/

3.2 брать? Или сразу 4-ку?

Спасибо за софтину - очень даже неплохо

Вы не спешите радоваться.
Попробуйте создать уникальный индекс.
Если у вас не возникнет проблемы с буквами е - ё, - то я вас поздравляю!

Я лично так и не сумел с ними справиться.
Лучше уж сразу это проверить,чтобы потом не пришлось всё переделывать.

C буквами А и а у Вас проблем не возникает?

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

Да я , собственно, Евгению... Никак не может человек понять, что е и ё - одна и та же буква....

>Да я , собственно, Евгению... Никак не может человек понять, что е и ё - одна и та же буква....

Хорошо, что вы сказали, а то я всегда думал, что
ведро
и
вёдро - совершенно разные слова.

Ну а если серьёзно, то general_ci у меня, конечно, к сожалению, есть,
Но в СР1251 - он различает е и ё, а вот в UTF8 -нет.
Поэтому пришлось бы использовать binary, если бы я уже не решил
отказаться от UTF с её заморочками.

Просто даже любопытно, кто это такое придумывает что е и ё - одно и то же?!

странный у вас UTF однако...
или у меня странный... =)

Вы попробуйте:

DROP TABLE IF EXISTS tmp ; CREATE TABLE tmp ( w varchar(20) UNIQUE ) CHARSET = 'UTF8', COLLATE = 'utf8_general_ci'  ; INSERT tmp (w) VALUES  ('ведро'), ('вёдро') ;

Если сработает, то здорово!
Тогда пишите какая у вас версия MySQL

Вообще, прошу всех:
Попробуйте этот код у себя!
Напишите здесь работает он или нет?

Хочу, наконец, разобраться как все эти мины и свистки в UTF обходить.

>>Да я , собственно, Евгению... Никак не может человек понять, что е и ё - одна и та же буква....
>Хорошо, что вы сказали, а то я всегда думал, что
>ведро
>и
>вёдро - совершенно разные слова.

Второе слово мне неизвестно. Что оно значит?
...

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

Расправили крылышки бабочки бодро -
Сегодня на улице солнечно - вёдро.

Это чуть ли не Агния Барто.
Кто-то из детских поэтов.
Точно не помню.

Кстати, могу порадовать любителей юникода:
Похоже, что начиная с версии MySQL 5.1
сервер ведёт себя адекватно - буквы различает.
(Проверено экспериментально)
Ура!

Просто посмотри свой collation. И разочаруйся :)

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

На 4.1 не работает :(

mysql> select 'Звёздный' = 'Звездный', 'Звёздный' = 'Звездячий' -> ; +---------------------------------------------+ | 'Звёздный' = 'Звездный' | 'Звёздный' = 'Звездячий' | +---------------------------------------------+ | 1 | 0 | +---------------------------------------------+ 1 row in set (0.01 sec)

а на 5.1

select 'Звёздный' = 'Звездный', 'Звёздный' = 'Звездячий'; +---------------------------------------------+ | 'Звёздный' = 'Звездный' | 'Звёздный' = 'Звездячий' | +---------------------------------------------+ | 0 | 0 | +---------------------------------------------+ 1 row in set (0.02 sec)

работает!

А на 5.0.51 вообще забавно:
Данный тест проходит, но уникальный ключ считает "е" и "ё" одним и тем же символом.

А от collation, как ни странно практически ничего не завистит в этом вопросе.
general_ci и unicode_ci дают совершенно одинаковые результаты...

Так что вывод из всех этих долгих рассуждений простой:
Если хочешь работать с юникодом, в начале обновись до 5.1

Ну, это под Линукс. Под windows надо бы отдельно проверить.

Мда >:( Где ты collation-то смотрел?

Панацея

<?php /*коннект до БД и выбор БД  с помощью mysql_select_db*/ // сразу после выбора делаем вот так mysql_unbuffered_query("SET `character_set_client` = 'utf8';"); mysql_unbuffered_query("SET `character_set_results` = 'utf8';"); mysql_unbuffered_query("SET `collation_connection` = 'utf8_general_ci';"); // и забываем об косяках ?>

во-первых, utf8_general_ci есть далеко не у всех. У большинства, насколько я знаю, нету.
во-вторых, изменять collation connection на значение, отличное от @@collation_database, в общем случае сомнительная практика, хотя неявно это многие советуют делать.
в-третьих, и самых главных - любая панацея в программировании - это обычно средство доставить себе максимальные проблемы на свою жопу потом, позже.

> во-первых, utf8_general_ci есть далеко не у всех. У большинства, насколько я знаю, нету

Как это -- нет?.. Да и utf8_unicode_ci, наоборот, имеет больше, так сказать, правил для сравнения. Я чего-то не понимаю.

да так... uft8_bin есть . uft8_unicode_ci есть . uft8_general_ci вызывает ошибку.

Предайе лютой смерти свой древний MySQL сервер. данный код еще никогда не приводил к каким либо последствиям. все работает как часы

различание букв е и ё это хорошо, а как обстоит у вас дело с сортировкой по ним? у меня с буквы ё алфавит начинается :-(((((

во первых, здесь принято заводить новые темы, а не откапывать хорошо усопшие старые.
во вторых, а какое charset collation на этом поле?

Новую тоже завел, хоть вешайся, проект встал.

проект языковый со словарями мультиязычный
у меня на сайте еще всякие буковки вроде s и c с крышечками и галочками

Если использую utf8_bin то оно эту самую ё различает как и все остальные но сортирует неправильно

utf8_unicode_ci utf8_slovenian_ci utf8_general_ci сортируют правильно если правильным считать порядок в котором они не различают ё и е или с с крышечкой и без.

Впервые столкнулся с UTF, домал что она нормальная. Теперь в полном ауте.
Либо не различает толком либо сортирует поуродски

>utf8_unicode_ci utf8_slovenian_ci utf8_general_ci сортируют правильно если правильным считать порядок в котором они не различают ё и е или с с крышечкой и без.

Ну, в общем-то, нужно приучать себя считать такой порядок правильным.
Либо создать собственное сопcотавление [и убедить хостера в необходимости добавить его в конфигурацию сервера. ]

себя заставить можно, а людей составляющих словари и изучающих языки - сложновато :-))))

вот с хостером буду пробовать, но ведь если его потом поменяюют или он чего обновит в угаре - придется следить... Вот забота на пустом месте...

а с буквами И и Й такой проблемы нет?

Й стоит на своем законном месте. только ё выпендривается :-)

Была проблема с буквой ё, решил так:

<?php // После выбора базы mysql_query("SET NAMES 'utf8' COLLATE 'utf8_unicode_ci'"); ?>

Какой номер версии MySQL?