[Админам]

- Что самое прекрасное в мире? Борьба за освобождение человечества! А еще прекраснее вот что... Записывайте!
(с) В. Ерофеев, рецепт коктейля "Сучий потрох", "Москва-Петушки"

Полазив в Интернетах с большим удивлением обнаружил, что все прогрессивное человечество вместо борьбы за мир или, на худой конец, поисков чего-то вечного и светлого (желательно, не менее 40 градусов) озабочено проблемой кодировок MySQL. Ну почти все человечество. Не считая кучки отщепенцев, которые эту самую MySQL разрабатывают и не менее омерзительной кучки, которая релизит PHP 7.0

Нет, уровень "а у меня тут кракозябры" - это для неофитов. Куды как более интересны траблы с полнотекстовым поиском, сортировкой и более захватывающими вещами.

Альзо, камараден, рассмотрим пример

Берем любую версию PhotoPost Pro (начиная с 7.0 и по как минимум 8.4)

Там есть (следите за мыслью) теги. И эти теги при попытке ими воспользоваться отдаются в GET. И, сответственно, приходят опять же в GET в search.php. А там уже выполняется (страшно сказать) устрашающего вида LIKE запрос и потом, если повезет, выдача результатов.

Как сие выглядит на деле:

Берем реальный тег, к примеру, "лошадь"

Имеем для тега URL

http://photoshopia.ru/gallery_bkg/search.php?keywords=лошадь

В результате хитрых танцев с бубном выдается результат

http://photoshopia.ru/gallery_bkg/search.php?searchid=3

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

Если более подробно

                if ( $key )
                {
                    if ( !$condition )
                    {
                        $scond = "AND";
                    }
                    elseif ( $condition == "or" )
                    {
                        $scond = "OR";
                    }
                    else
                    {
                        $scond = "AND";
                    }

                    if ( $what == "allfields" )
                    {
                        $keyphrase .= ( empty($keyphrase) ? "AND " : "$scond " );

                        $keyphrase .= "((p.title LIKE \"% $key%\" OR p.description LIKE \"% $key%\" OR p.keywords LIKE \"% $key%\" OR p.bigimage LIKE \"% $key%\"
                            OR p.extra1 LIKE \"% $key%\" OR p.extra2 LIKE \"% $key%\" OR p.extra3 LIKE \"% $key%\" OR p.extra4 LIKE \"% $key%\" OR p.extra5 LIKE \"% $key%\" OR p.extra6 LIKE \"% $key%\" OR e.selection LIKE \"% $key%\")";
                        $keyphrase .= " OR (p.title LIKE \"$key%\" OR p.description LIKE \"$key%\" OR p.keywords LIKE \"$key%\" OR p.bigimage LIKE \"$key%\"
                            OR p.extra1 LIKE \"%$key%\" OR p.extra2 LIKE \"%$key%\" OR p.extra3 LIKE \"%$key%\" OR p.extra4 LIKE \"%$key%\" OR p.extra5 LIKE \"%$key%\" OR p.extra6 LIKE \"%$key%\" OR e.selection LIKE \"%$key%\"))";
                    }
                    elseif ( $what == "title" )
                    {
                        $keyphrase .= ( empty($keyphrase) ? "AND " : "$scond " );

                        $keyphrase .= "((p.title LIKE \"% $key%\") OR (p.title LIKE \"$key%\"))";
                    }
                    elseif ( $what == "titledesc" )
                    {
                        $keyphrase .= ( empty($keyphrase) ? "AND " : "$scond " );

                        $keyphrase .= "((p.title LIKE \"% $key%\" OR p.description LIKE \"% $key%\")";
                        $keyphrase .= " OR (p.title LIKE \"$key%\" OR p.description LIKE \"$key%\"))";
                    }
                    else
                    {
                        unset( $what );
                    }
                }
            }

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

Была предпринята попытка а-ля "стильно, модно, молодежно" перед запросом

$key=mb_convert_encoding($key, 'utf-8', mb_detect_encoding($key));

ну или иные кодировки. Результат поражает. После этой команды вместо результата "Ой, все, отстаньте от меня, я ничего не нашла" в результат поиска выдается вообще все. То есть если в галерее 30К изображений, то все они и найдутся.

В общем вопрос, как всегда один - где копать?

SHOW GLOBAL VARIABLES LIKE 'character_set%'

character_set_client 	cp1251
character_set_connection 	cp1251
character_set_database 	cp1251
character_set_filesystem 	binary
character_set_results 	cp1251
character_set_server 	cp1251
character_set_system 	utf8
character_sets_dir 	/usr/share/mysql/charsets/

SHOW VARIABLES LIKE 'character_set%'

character_set_client 	utf8
character_set_connection 	cp1251
character_set_database 	cp1251
character_set_filesystem 	binary
character_set_results 	utf8
character_set_server 	cp1251
character_set_system 	utf8
character_sets_dir 	/usr/share/mysql/charsets/

Сервер: MySQL (Localhost via UNIX socket)
Версия сервера: 5.1.73-1
Версия протокола: 10
Пользователь: root@localhost
MySQL-кодировка: UTF-8 Unicode (utf8)

Тока Христом-Богом прошу - не посылайте в Гугль, я оттуда уже 2 суток не вылезаю, везде только умные рассуждения на тему "Вот если бы с чарсетом не было проблем..." и никаких конкретных рекомендаций.. Увы-с.

Gostemilov добавил 08.04.2015 в 17:42
P.S. вообще-то полагал, что LIKE запросы прилично грузят сервер. Может, поднапрячься и сделать систему тегов, как на форуме, благо придумывать не надо, 90% простой копипаст, а на авторские права кого угодно в данном случае мне начхать?

все ниже опианное применимо только к пост-запросам отправленным через аякс, т.к. из яваскрипта всегда приходят данные в UTF-8

Originally Posted by Gostemilov

$key=mb_convert_encoding($key, 'utf-8', mb_detect_encoding($key));

я делаю немного не так
т.е. вообще не так
нам известно:
в какой кодировке форум и таблицы + поля в таблицах + текст в полях
кодировка, указанная в настройках языков, загнанная в переменную $stylevar['charset']

проверяю, что пришло в запросе и как пришло

PHP Code:

if($vbulletin->GPC['ajax'])
{
      // проверяем кодировку
      if(strtoupper($stylevar['charset']) != 'UTF-8')
      {
            // конвертирую строку из пост-запроса
            $search_str = krfm_convert_string('UTF-8', $stylevar['charset'], $search_str);
      }
} 


функция из файловика для перекодировки

PHP Code:

// Convert string using existing functions, return non converted string otherwise
function krfm_convert_string($convert_from, $convert_to, $string)
{
      if(function_exists('iconv'))
      {
            return @iconv($convert_from, $convert_to, $string);
      }
      else if(function_exists('mb_convert_encoding'))
      {
            return @mb_convert_encoding($string, $convert_to, $convert_from);
      }
      return $string;
} 


а пхпшная функция mb_detect_encoding() вообще ниачём =)
она не корректно определяет кодировки (вернее определяет только латинские типы кодировок)
я по началу тоже обрадовался, думал, вот универсальное решение
хрен там
что бы определить кодировку более/менее нормально, подключал целый файл с набором возможных сочетаний символов (который так же используется в файловике charset_krfilesmanager.php и charset_UTF-8_krfilesmanager.php)
упоминания о библиотеке
1. http://www.askdev.ru/php/5316/Проблема-с-кодировкой/
2. http://forum.php.su/topic.php?forum=28&topic=75
гугл. https://www.google.com/webhp?complet...=a.charset.php
так как сайт автора в дауне, может потому что домен в "зоне" военных действий UA popoff.donetsk.ua/text/work/libs/a/charset/

кстати, в файловике используется поиск похожий на вобловский, сама система поиска скопирована из воблы и адаптирована под свои нужды (используется полнотекстовый поиск, а не %LIKE% в разных вариантах, если включен полнотекстовый в настройках и поддерживается серваком)
на форумах с кодировкой UTF все работает нормально
поиск находит именно то, что запрошено, если это есть в БД оно будет найдено
тоже самое с тегами в файловике

пример ссылки с меткой "русификатор"
http://vbsupport.ru/forum/krfilesman...82%D0%BE%D1%80

как это работает на форумах с кодировкой cp1251, мне не ведомо, т.к. никто пока не отписывался о таких проблемах

Originally Posted by Gostemilov

релизит PHP 7.0

эмммм....

Originally Posted by Luvilla

эмммм....

Еще в Internet Brands подсуетятся, и будет "какая боль, какая боль, пхп и вбулетин 7.0"

Originally Posted by kerk

как это работает на форумах с кодировкой cp1251, мне не ведомо, т.к. никто пока не отписывался о таких проблемах

- и не отпишется. Оно работает на cp1251

Gostemilov добавил 09.04.2015 в 05:18

Originally Posted by Smalesh

Еще в Internet Brands подсуетятся, и будет "какая боль, какая боль, пхп и вбулетин 7.0"

Не-а. Debian 7.0 + PHP 7.0 + Vbulletin 7.0 - вот чего бояться-то надо!

После того как разработчики PHP определились с номером версии для нового PHP (новая версия будет PHP 7.x, а не PHP 6.x, наработки по 6.x были перенесены в ветку 5.x), пришло время спланировать график выпуска PHP 7.x. Было принято решение закончить разработку 7.0 в течение года, с датой релиза в ноябре 2015.

Чтобы PHP развивался быстрее, было решено сократить цикл разработки новых версий PHP, чтобы можно было добавлять новые возможности языка в каждую мажорную версию. За год наберется достаточное количество изменений, которые приведут к несовместимости версий, чтобы выносить их в новую мажорную версию PHP. Также все дополнительные изменения в PHP будут добавлятся в минорные версии 7.1, 7.2 и т.д.

Gostemilov добавил 09.04.2015 в 05:24
То есть в итоге ( в код пока не лез)

1. Из поста берутся теги в виде "тег1, тег2,тег3"
2. explode эту строку
3. Каждый тег в таблицу тегов , в первое поле сам тег, во второе номер поста, проверять уникальность не нужно

При поиске -
4. стандартный поиск без LIKE в поле тегов, дает массив ID постов
5. Дальше все просто

Ну это и я могу... Мурку давай!

Gostemilov добавил 09.04.2015 в 06:25
Оффтоп

Мне одному это ситуацию с Айфонами напоминает? Написал я скрипт, к примеру, хороший скрипт. Под актуальную PHP 5.2. И с этого момента я должен (а то мне больше делать нечего) каждые пару месяцев его переписывать под 7.*, 8.* и так далее?

Мне-то проще, я установил 5.2 и запретил обновления. Все-таки свой сервер имеет массу плюсов...

Просто попытался представить себе тот гемморой, который имеют авторы коммерческих скриптов, которых ЗАСТАВЛЯЮТ постоянно переписывать код, чтоб оно было "актуально".

Originally Posted by Gostemilov

которых ЗАСТАВЛЯЮТ постоянно переписывать код

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