Проверка: символ является буквой?

[Shasoft]

Задача: конвертировать произвольный текст в одно слово для fulltext поиска.
Вариант решения: все не-буквы текста конвертировать в код _<код символа>
Проблема: для этого нужно определить какой символ является буквой, а какой нет
Строка в utf8

Есть ли в PHP такая функция для определения является ли символ буквой?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Подумав, придумал алгоритм с изменением регистра. Т.е. беру символ, преобразовываю его в верний регистр и в нижний. Сравниваем полученные символы и если они не равны, то значит этот символ является буквой. Но может всё-таки есть готовая функция PHP?

 

[Redjik]

[a-zA-Zа-яА-Я]

 

[Shasoft]

[a-zA-Zа-яА-Я]

символ является буквой. Любой буквой, а не только буквой латиницы или русского алфавита.

 

[Redjik]

Что за условие такое, твой вариант не катит для иероглифов тогда...

А так, думаю правильно настроенная локаль решит проблемы с умлаутами, имхо... не проверял...

 

[Shasoft]

умлаутами - на понятном языке?

 

[Redjik]

чего?

 

[Shasoft]

Я слово умлаутами не понял. Расшифруйте для гугления.

 

[Фанат]

меня куда больше интересует задача "произвольный текст в одно слово для fulltext поиска"
что это за такой "fulltext поиск" и знает ли аффтар о функциях хэширования

 

[fixxxer]

В спецификации юникода можно найти, какие диапазоны кодпоинтов являются буквами. Только нормализацию надо сначала делать: скажем, ё может быть и "ё", и "е + точки сверху". Вот неясно зачем такие сложности, любая база делает нормализацию сама, да и реализаций фултекста готовых полно.

 

[Shasoft]

меня куда больше интересует задача "произвольный текст в одно слово для fulltext поиска"
что это за такой "fulltext поиск" и знает ли аффтар о функциях хэширования

fulltext поиск по таблице в MySQL с использованием FULLTEXT индекса.

В спецификации юникода можно найти, какие диапазоны кодпоинтов являются буквами. Только нормализацию надо сначала делать: скажем, ё может быть и "ё", и "е + точки сверху".

Пересматривать 65 тыс символов - долго и нудно. Прощё всё-таки с регистром поиграться.

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

К примеру берем фразу: "value=Петр Первый". В FULLTEXT это будет три слова. Преобразование нужно, чтобы в FULLTEXT индексе это было одним словом. Это нужно, чтобы искать именно по этому слову.

 

[Вурдалак]

Нет, тебе это не нужно.

 

[Adelf]

Shasoft
да возьми сфинкс. и не мучайся.

 

[Фанат]

Adelf
похоже, этот чувак понимает под полнотекстовым поиском что-то другое

 

[Shasoft]

Shasoft
да возьми сфинкс. и не мучайся.

Поправьте меня, если я неправильно понял, но сфинкс - это отдельная программа, которую нужно устанавливать на отдельную машину. Хостер мне такого не даст сделать.

 

[Shasoft]

Adelf
похоже, этот чувак понимает под полнотекстовым поиском что-то другое

По алгоритму я хочу в поле MEDIUMTEXT хранить атрибуты в виде: key1=Петр Первый key2=Иван Грозный и т.п.
При этом искать буду в BOLEAN MODE. Для того, чтобы параметр искался точно, необходимо, чтобы ключ+значение было единым словом для поиска. Для этого и нужны замены небукв.

 

[Фанат]

ахаха, это ж он свое EAV хранилище оптимизирует

 

[Shasoft]

ахаха, это ж он свое EAV хранилище оптимизирует

Ну просто супер-информативный и полезный комментарий.

 

[ScDewt]

К примеру берем фразу: "value=Петр Первый". В FULLTEXT это будет три слова. Преобразование нужно, чтобы в FULLTEXT индексе это было одним словом. Это нужно, чтобы искать именно по этому слову.

Если поиск ведется по всему слову типа " where `value`='Петр Первый' ", то почему бы в этой таблице не сделать еще одно поле где будет храниться хеш - md5(strtolower(value)) и сделать индекс по этому полю длинной к примеру 10-20 символов? Тогда при поиске мы преобразуем искомый элемент в тот же md5 вместе с strtolower и ищем в базе строку по этому хешу.

 

[Redjik]

Фанат
кстати по EAV немного оффтопа, как лично вы CAST обходите?
ведь приведение не позволяет пользоваться индексом...
два поля хранить int и char?

 

[Shasoft]

Если поиск ведется по всему слову типа " where `value`='Петр Первый' ", то почему бы в этой таблице не сделать еще одно поле где будет храниться хеш - md5(strtolower(value)) и сделать индекс по этому полю длинной к примеру 10-20 символов? Тогда при поиске мы преобразуем искомый элемент в тот же md5 вместе с strtolower и ищем в базе строку по этому хешу.

Такой вариант рассматривался, но при хеше пропадает возможность искать без учета регистра, т.к. хеш от `value`='Петр Первый' и `value`='ПЕТР Первый' будет разный. Собственно это преобразование небукв именно для этого и буду делать, чтобы поиск был без учета регистра.