eregi и русский язык

Приветствую все.

Проблема в следующем:
функция eregi говорил что ООО Градэко и ООО ГРАДЭКО это разные строки. Судя по описанию функции регистр должен быть проигнорирован, но у меня получается иначе.

первое название берется из текстового файла, а второе как параметр от УРЛа. Если второй параметр пишу так же как и в файле указано, то всё нормально.

Можно попробовать сделать setlocale(LC_ALL, 'ru_RU');
Другой вариант - заменить все русские буквы примерно вот так в шаблоне: ООО [Гг][Рр][аА][Дд][эЭ][кК][оО]. Преобразование строки Градэко в [Гг][Рр][аА][Дд][эЭ][кК][оО] можно автоматизировать, чтоб вручную весь файл не ковырять. Если такая замена действительно поможет, подскажу, как сделать такое преобразование.
Ну и третий вариант - дождаться, пока сюда зайдет JustUserR. Он тоже что-нибудь скажет хорошее.

неа, не помогает....

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

О великий JustUserR! Взываю к тебе, снизойди к нам, услышь мои мольбы, помоги бестолковому

http://forum.php.su/topic.php?fo...m=4&topic=21
- думаю, идея ясна

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Идея-то ясна, я в поиске уже такое находил, прежде чем пост делать, но это не к месту. Всё в одной кодировке работает.

Не, если бы строка была не в той кодировке, то не матчилась бы строка ни в каком регистре. А когда в одном матчится, в другом нет, то тут другая штука, по-моему.

Кстати, ereg* ведь выбрасывать будут, поэтому стоит перейти на preg_* функции. Может и проблема решится. У меня с ними таких проблем не возникало.

Вообще если имеется проблема с кодировкой то регулярное выражение действительно не должно работать ни с нижним регистром ни с верхним - однако в зависмости от различных кодировок символы в нижнем регистре могут иметь разные ASCII-коды в то время как символы верхнего регистра могут совпадать
Однако может быть входная строка находится в кодировке UTF8 - в таком случае надо использовать функцию http://www.php.su/functions/?mb-eregi-replace а также дополнительно указать кодировку в http://www.php.su/functions/?mb-regex-encoding

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/

нет, кодировка виндовская. я echo делал обоих строк при трассировке, всё в одинаковых кодировках. Наверно придется приводить всё к единому регистру и не мучаться
(Добавление)
Сначала пробовал привести всё к верхнему регистру, на денвере локально всё работало, а у хостера так же нет, как и вышеуказанная функция. Давай уже мучить Яндекс, нашел:
@setlocale(LC_ALL, 'ru_RU.CP1251');
и всё заработало. Убрал приведение к верхнему регистру, оставил код как было указано в самом верху, и так же работает.

Всем спасибо!!!

Дело в том что кодировка входящих и выводимых PHP-скриптом данных а также строковых констант в исходном может совпадать и при диагностическом выводе на экран данные будут выглядеть как нужно - но если внутреннее представление данных в PHP-скрипте будет трактоваться в другой кодировке то строковые функции не будут работать как надо
Также несмотря на то что mb-функции предназначены для многобайтовых строк они также неплохо выполнять перекодировк и операции для однобайтовых кодировок - поэтому советую вам использовать две вышеуказанные функции и посмотреть что будет Также можно попробовать с помощью iconv или mb_convert_string сделать перевод в другую кодировку - и посмотреть как дела обстоят так

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/

Вот многим с тебя пример взять надо.

Собственно сказать предположение и было верное - поэтому вариант с двойным iconv во внутренную кодировку представления данных в PHP-скрипте также должен работать аналогично

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/

так я обычно сначала усердно Яндексю, потом гуглю, а уж потом людей мучаю на форумах. Так быстрее.

Просто в таких случаях как в вашем с регистром в регулярных выражениях прослеживается казалось бы неочевидность - вроде бы все работает и кодировка на входе и выходе верная и даже шаблоны срабатывают а вот регистр нет Однако машина регулярных выражений может использовать собственную внутреннюю кодировку и переводить входные данные и строковые константы в нее - поэтому между собой они совпадают но к примеру шаблоны классов символов уже могут не совпадать
Именно по этой причине поллезно смотреть текущую внутреннюю кодировку с помощью функций http://www.php.su/functions/?mb-regex-encoding и http://www.php.su/functions/?mb-...nternal-encoding

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/

Благодарю! Посмотрю описание.

На здоровье! Хотя данные функции принадлежат к разделу функция для обработки многобайтовых multiyte - они также хорошо работают с однобайтовыми строками при указании соответствующей кодировки в настроечной функции Но в отличие от обычных строковых функций они позволяют явно регулировать используемые кодироку - и не меняют общую локаль PHP-скрипта и трактовку сторковых констант в исходном PHP-коде

-----
Сделать можно все что угодно - нужно только старание, терпение и хороший поисковик
Безлимитный web-хостинг от 15 рублей за 40 МБ дискового пространства - http://ihost[dot]oks71[dot]ru/