mySQL на хостинге: различие российских и американских хостеров.

[dima2007]

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

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

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

Нап***ер на совершенно глупый запрос "like %aaaa%" на российских хостах ничего не возвращается, что вполне логично т.к. такой строки нет в базе.
А на американских хостах на этот запрос возвращается куча записей... в которых реально нет этой строки.

Отчего это может быть и как фиксить?

П.С. Под "российский" я подразумеваю хостинг российской фирмы т.е. обслуживаемый русским сапортом. Под "американский" подразумеваю чисто американский хостинг ( причем качественный, мои акки на resellerzoom.com, sonet7.com, etc)

[andreyk@]

Настройка mysql. Фиксить скорее всего никак, так как нужно редактировать my.cnf к которому доступа на виртуалхостинге нет

[alex-developer]

а еще разница что какие-то размеры баз на российских хостингах, а штатских пофене...

[dima2007]

все решилось установкой вот такой строки
@mysql_query("SET NAMES utf8"); // для корректного поиска на американском хостинге

после этого поиск по русским полям базы начал работать нормально....

[openhosting]

Сообщение от dima2007

все решилось установкой вот такой строки
@mysql_query("SET NAMES utf8"); // для корректного поиска на американском хостинге

после этого поиск по русским полям базы начал работать нормально....

Судя по тому, что Вы написали, все дело в разных версиях MySQL. Дело в том, что в MySQL 4.1 появилась расширенная поддержка кодировок. И чтобы она правильно работала, ее нужна корректно настроить. Это означает, что скрипты, написанные без учета особенностей MySQL 4.1 работают некорректно с русским текстом.
А таких скриптов очень много.

Чтобы они заработали правильно нужно после соединения с БД вставить директиву: set set character set cp1251. Вместо cp1251 можно поставить и другую кодировку. Директива set names работает хуже, она устанавливает кодировку не совсем правильно.

На нашем хостинге мы поправили php (он не совсем корретно работает с MySQL), и добавили опцию, позволяющую задать кодировку базы данных в php.ini. При наличии этой опции кодировку в скрипте задавать уже не надо, php делает это сам, сразу после соединения с БД. Соответственно у нас корректно работают и старые скрипты, которые не рассчитаны на MySQL 4.1.

На нашем форуме все описано подробней:
http://forum.openhosting.ru/index.php?t=msg&goto=54

[alex-developer]

ну вы даёте, так как при нормальном коде (php/perl) всё делаете в UTF и работает хоть на китайском хостинге 100% отлично, еще не разу не было проблем что расписанно в этой теме.

[openhosting]

Сообщение от alex-developer

ну вы даёте, так как при нормальном коде (php/perl) всё делаете в UTF и работает хоть на китайском хостинге 100% отлично, еще не разу не было проблем что расписанно в этой теме.

А вы это на MySQL 4.1 пробовали? дело в том что обычный php не выставляет кодировку клиента, потому что не вызывает функцию которую по мнению разработчиков MySQL
надо вызывать после соеденения. В результате клиенская кодировка = utf8
и если у Вас кодировка базы UTF-8 - начинается перекодирование из UTF-8 в latin1.

Оно конечно работает как-то... Но что бы работало нормально нужно либо иметь обе кодировки одинаковые, тоесть latin1, но тогда прощай правильная сортировка и поиск.
Либо таки выставить правильную кодировку клиента, тогда все будет правильно перекодироваться.

Веселье усугубляется тем что в MySQL кодировка задается сразу в 5-ти переменных.
В общем тем кто это все придумывал в MySQL явно погорячились, поэтому сейчас почти везде где поставили MySQL 4.1 и выше - большие проблемы с кодировками.

У нас патчь к php скрывает все это, пользователь вообще не замечает этих проблем.
В php.ini стоит клиенкая кодировка latin1, а базу можно создавать хоть в cp1251, хоть в UTF-8. Хотя как не странно, некоторые скрипты с базой в UTF-8 умудряются все равно не правильно работать. Например Mambo, если мне память не изменяет.

Так что не все так просто, при наличии нашего пача к php все еще проще

[alex-developer]

Сообщение от openhosting

А вы это на MySQL 4.1 пробовали? дело в том что обычный php не выставляет кодировку клиента, потому что не вызывает функцию которую по мнению разработчиков MySQL
надо вызывать после соеденения. В результате клиенская кодировка = utf8
и если у Вас кодировка базы UTF-8 - начинается перекодирование из UTF-8 в latin1.

но конечно работает как-то... Но что бы работало нормально нужно либо иметь обе кодировки одинаковые, тоесть latin1, но тогда прощай правильная сортировка и поиск.
Либо таки выставить правильную кодировку клиента, тогда все будет правильно перекодироваться.

Веселье усугубляется тем что в MySQL кодировка задается сразу в 5-ти переменных.
В общем тем кто это все придумывал в MySQL явно погорячились, поэтому сейчас почти везде где поставили MySQL 4.1 и выше - большие проблемы с кодировками.

У нас патчь к php скрывает все это, пользователь вообще не замечает этих проблем.
В php.ini стоит клиенкая кодировка latin1, а базу можно создавать хоть в cp1251, хоть в UTF-8. Хотя как не странно, некоторые скрипты с базой в UTF-8 умудряются все равно не правильно работать. Например Mambo, если мне память не изменяет.

Так что не все так просто, при наличии нашего пача к php все еще проще

пробовал, так как разрабатываю все системы на php 5.1.x и mysql 4.1, потом всё это дело переносится в жизнь на хостинг у которых от php 4.1 и mysql 3.2 до последних версий, проблем никаких не замечал. а клиенту всё подается в UTF-8 кодировке, так что никакой конвертации нет.
А UTF-8 выбрал так как неохото было создовать подобных проблем с кодировками, так как для каждого языка нужно выдавать другую кодировку, а так всё в UTF-8 закатал пока всё работает нормально.

php не выставляет кодировку клиента

допустим что сервер настроен по умолчанию в cp1251, но никто же не запрещает использовать в php следующее:
utf8_encode($content);
где $content информация из базы, тем самым браузер сам заметит что инфо в utf-8 формате и клиенту подаст инфо в правильной читаемой кодировке.

но тогда прощай правильная сортировка и поиск.

почемуже, если всё дело в UTF-8 то и поиск работает и сортировка.

[openhosting]

в perl работает, потому что он работает с MySQL как рекомендуют разработчики MySQL.
Php не вызывает функцию, которую должен вызывать после соеденения с БД. Эта функция читает файл my.cnf и устанавливает кодировку отуда. Поэтому если у Вас
для всего сервера задана кодировка UTF8, в php после соеденения будет utf8.

Разумеется кодировку можно поставить руками в php скрипте, только нужно править существующие скрипты.