Беда с кодировками

[greatdane]

Имеется полностью английская страница с поисковой формой. Аудитория, использующая английскую версию - на 30% Восточная Европа, т.е. далеко не у всех набор символов - латиница. В layout'e кодировка выставлена - UTF-8. Но если в браузере посетителя отключено автоопределение кодировки и принудительно выставлена какая-нибудь cp1251 или другая с символами кириллицы - то страница-то отображается нормально (поскольку полностью на английском), а вот поисковый запрос с нестандартными символами выдает ошибку:

Error 500
CDbCommand failed to execute the SQL statement: SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (cp1251_general_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation 'like'

Есть ли возможность определить, в какой кодировке пришли данные, и перекодировать при необходимости?

[rak]

возможно mb_detect_encoding + iconv помогут?
для кириллицы ещё есть вот такое http://popoff.donetsk.ua/text/work/libs/a/charset/

[greatdane]

возможно mb_detect_encoding + iconv помогут?

К сожалению, почему-то даже "строгое" определение UTF-8 пропускает строчку с windows-1251

Код: Выделить всё

if(mb_detect_encoding($model->query, 'UTF-8', true)) 

возвращает true, хотя "на входе" символы windows-1251

для кириллицы ещё есть вот такое http://popoff.donetsk.ua/text/work/libs/a/charset/

Потрясающая вещь, огромное спасибо за ссылку! Однако по-моему извращение - сначала энкодить любую строку в windows-1251, а потом из нее в UTF-8, учитывая, что все-таки подавляющее большинство запросов приходит латиницей... или не извращение? Вы не пробовали эту штуку? Насколько она медленная?

[because]

Непонятна проблема, зачем пользователю выставлять кодировку, нужная кодировка прописана в заголовке страницы и определяется автоматически. Если пользователь меняет кодировку, то это его проблемы.
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

[greatdane]

Непонятна проблема, зачем пользователю выставлять кодировку, нужная кодировка прописана в заголовке страницы и определяется автоматически. Если пользователь меняет кодировку, то это его проблемы.
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Блажен кто верует... стОило сегодня опубликовать поиск - мгновенно пришло несколько писем с жалобой на ошибку. Вы у меня-то зачем спрашиваете, зачем они это делают? Вот оказалось, что есть такие, кто ходит по тырнету с принудительно выставленной кодировкой и отключенным автоопределением и зачем-то сует кириллицу в заведомо английский поиск...
Я пока рассудила так же, как и вы, и прописала прямо над формой предупреждение, что поиск работает только в UTF-8... Но гложут меня сомнения, что это не совсем правильно

[rak]

Потрясающая вещь, огромное спасибо за ссылку! Однако по-моему извращение - сначала энкодить любую строку в windows-1251, а потом из нее в UTF-8, учитывая, что все-таки подавляющее большинство запросов приходит латиницей... или не извращение? Вы не пробовали эту штуку? Насколько она медленная?

Я её когда то использовал для определения кодировки при парсинге сайтов, вроде работает довольно таки шустро, но специально тестов не делал

[because]

А ругается то на любую кирилицу, даже в utf-8 ?
Посмотрите Collation у таблиц в базе и у поля по которому идет поиск, какое там значение стоит. У меня сайт на utf-8 но никаких проблем нет с поиском, какую бы кодировку я не поставил в браузере.

[XAKEPEHOK]

Сегодня решал такую задачу. У меня было похожее когда через LIKE искал по типу datetime, при этом в LIKE были кириллические символы. Если так, то проблемы с кодировкой нет. При этом ошибка не выскакивает если в like есть латинские буквы. Видимо в MySQL возможен поиск по дате в формате ISO 8601, т.е:
2014-06-18T22:16:30
там буква «T» есть. А кириллица сразу ошибку выдает