MySQL и кодировка cp1251

Если всякие set names и CREATE TABLE ... ENGINE=InnoDB DEFAULT CHARSET=utf8 не помогли...

Доступ к шеллу есть? Помнится, были какие-то случаи когда умолчальная кодировка в клиенте не менялась никакими силами, только прямым заданием.

Все запросы, не использующие LIKE работают корректно? Если да то, вероятно, дело в сборке БД.

У меня на одной железке стоит 4.1.18 под UTF - базы с самыми разными кодировками работают без проблем. С 5.хх тоже всё в порядке, такого глюка не было ни разу.

SHOW VARIABLES LIKE 'char%'

Что выдается по этому запросу?

Ну и в помощь Вам URL:

http://forum.dklab.ru/denwer/base/ZnakiVoprosaVmestoKirillitsiVMysql4.html

character_set_client = cp1251

character_set_connection = cp1251

character_set_database = cp1251

character_set_results = cp1251

character_set_server = cp1251

character_set_system = utf8

collation_connection = cp1251_general_ci

collation_database = cp1251_general_ci

collation_server = cp1251_general_ci

Ну нет у меня проблемы вопросиков! Проблема с работой некоторых строковых функций.

Например, в запросе, испоьзующем составной fulltext - индекс, запрос по слову "хостинг" показывает правильные результаты, а по слову "искусство" - вываливает совсем неожиданные результаты.

Пока заметил некорректную работу LIKE и MATCH..AGAINST. ORDER BY сортирует правильно. Как через шел поменять кодировку по умолчанию? (доступ есть)

Попробуйте выполнить из шелла "проблемный" запрос с указанием и без (кодировки и COLLATION)

типа mysql -u user -p

>запрос;

и

типа mysql --default-character-set=cp1251 -u user -p

>запрос;

И посмотрите какой collation указан для таблиц в базе (могли криво создаться, надо или utf8_general_ci или аналогично под 1251)

Если одинаковый результат - то можно ещё покопаться, но в целом похоже таки именно на какой то дефект именно этой версии mysql

Фрагмент запроса SHOW CREATE TABLE (для остальных аналогично):

 FULLTEXT KEY `idx_match` (`title`,`description`,`url`)

) ENGINE=MyISAM AUTO_INCREMENT=6 DEFAULT CHARSET=cp1251

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

По умолчанию у хостера следующие переменные:

+--------------------------+----------------------------+

| Variable_name            | Value                      |

+--------------------------+----------------------------+

| character_set_client     | latin1                     |

| character_set_connection | latin1                     |

| character_set_database   | latin1                     |

| character_set_results    | latin1                     |

| character_set_server     | latin1                     |

| character_set_system     | utf8                       |

| character_sets_dir       | /usr/share/mysql/charsets/ |

+--------------------------+----------------------------+

Если все оставить как есть, только подключаться и принимать данные как cp1251, то с данными все нормально, но ни одна строковая функция не работает как следует, ORDER BY сортирует неправильно. С созданием БД и таблиц как cp1251 сортировка начинает работать правильно, но некоторые вещи продолжают шалить. UTF8 тоже не привносит ярких и красочных впечатлений 🙄

Только что ответил хостер. Как и предполагал, ничего дельного я не узнал:

CREATE TABLE `ttt` (

`tt` VARCHAR( 244 ) CHARACTER SET cp1251 COLLATE cp1251_general_ci NOT NULL

) TYPE = MYISAM ;

загрузите базу на хост, войдите под шеллом, и запустите команду (для latin1)

iconv -f utf8 -t latin1 -c < 7777.sql | sed s/latin1/cp1251/ | perl -ne 's/NAMES utf8/NAMES cp1251/; print' > 999.sql

7777.sql исходная базв, базу 999.sql получите в ср1251 и будет вам счастье, и не мучайтесь с кодировками)))

Я подозреваю, что при создании таблицы с параметром DEFAULT CHARSET cp1251 и так все поля будут с этим чарсетом.

Спасибо за такую идею! Нужно попробовать. Но имеет ли смысл в моем случае такая конвертация, если у базы и всех ее таблиц установлен cp1251 и все данные были залиты с этим CHARSET? Во всяком случае попробую.