Пользуюсь только FireFox+KeeperLight, для моих скромных задач болоее чем достаточно.
Согласен, но с оговорками - 5-30% трафика с поиска по гуглокартинкам. Ценность этого трафика пока под вопросом.
Кстати, на сайте где трафика по картинкам аж 30% вместе с просто гуглопоиском получается более половины. Может, просто тема такая...
Варианты - функция iconv(), она же iconv -f ... -t ... < file > file2 в шелле.
И в дампе могут создаваться таблицы с умолчальной кодировкой UTF (искать DEFAULT CHARSET, SET NAMES и COLLATION)
С заголовком погорячился, факт.
Видимо, действительно стоит это обозвать как-то возвышенно, например "составление первичного ТЗ".
Бизнес совершенно не требует встречи с заказчиком (в 90% случаев), оттого и вопрос.
А включать в стоимость копеечной работы затраты времени "на покататься" - заказчик тоже не так поймёт, типа дорого получится. Буду тренировать методы убеждения.
CREATE TABLE `ttt` (
`tt` VARCHAR( 244 ) CHARACTER SET cp1251 COLLATE cp1251_general_ci NOT NULL
) TYPE = MYISAM ;
Попробуйте выполнить из шелла "проблемный" запрос с указанием и без (кодировки и COLLATION)
типа mysql -u user -p
>запрос;
и
типа mysql --default-character-set=cp1251 -u user -p
И посмотрите какой collation указан для таблиц в базе (могли криво создаться, надо или utf8_general_ci или аналогично под 1251)
Если одинаковый результат - то можно ещё покопаться, но в целом похоже таки именно на какой то дефект именно этой версии mysql
Если всякие set names и CREATE TABLE ... ENGINE=InnoDB DEFAULT CHARSET=utf8 не помогли...
Доступ к шеллу есть? Помнится, были какие-то случаи когда умолчальная кодировка в клиенте не менялась никакими силами, только прямым заданием.
Все запросы, не использующие LIKE работают корректно? Если да то, вероятно, дело в сборке БД.
У меня на одной железке стоит 4.1.18 под UTF - базы с самыми разными кодировками работают без проблем. С 5.хх тоже всё в порядке, такого глюка не было ни разу.
Squirrelmail - ставил, быстро и незатейливо. Потом, правда, сильно доводил напильником (кодировка UTF-8 и всякие пожелания клиентов по части фильтров и форвардинга)
Рекомендую сразу отключить в нём всякие ORDB и установить плагин с байес-фильтром.
С кодировкой 1251 проблем вообще не должно быть.
В договоре дырка - с одной стороны заказчик может делать что захочет, а с другой доступ к шеллу и ftp не предоставляется. Отсюда и проблема. Вроде делай что хошь, только руки коротки. Видимо, без изменения договора не обойтись. Попробовать объяснить ситуацию - дескать раз изменяется схема поддержки и обслуживания, то и ответственность тоже надо перераспределить в сторону сотрудника заказчика.
P.S. Обычно отдаю все исходники заказчику, без каких либо условий, так оно проще. Впрочем, у меня вывод в опенсорс в перспективе, так что за код держаться сильно нет смысла, у вас видимо другая ситуация.
По пункту 2 - в вашем договоре не написано что вы не несёте ответственности за порчу кода представителями заказчика? А то как-то странно, ответственность на вас а доступ к коду имеет кто попало (в случае "изъятия").
Мне кажется надо настаивать на подписании нового договора с учётом изменившихся обстоятельств. Например гарантировать поставку апдейтов скрипта (ограниченный доступ к SVN например), а уж ставить его дело сотрудников заказчика.
