[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: определить кодировку по тексту
olgatcpip
Здравствуйте.

Давно поднимала вопрос, но, к сожалению уже не смогла найти тему sad.gif
Но суть вот в чем.
Есть сайты по всему интернету. Мне нужно получить titleы некоторых из них, и записать их в файл.
Сами понимаете, что кракозябликов в файле не хочется иметь...
И тогда я нашла замечательныую функцию, которая определяет кодировку по тексту. Я прикрепила целый скрипт, где она используется, вдруг кому интересно getCoding() - та функция, которая определяет кодировку...
Я здесь не хочу поднять дебаты на тему на сколько реально вообще определить кодировку с 100% точностью. Суть в другом немного.

Короче, пользовалась я ей в своё удовольствие как вдруг, начали мои скрипты затыкатья! Т.е. Раз и переставали работать! Я уже плакалась на этом форуме с вопросами что да как делать.
Так вот в ходе исследований, увидела ошибку
Цитата
[Tue Mar 23 09:05:23 2010] [error] [client хх.хх.хх.хх] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 35 bytes) in /var/.../whois_file_parser/site_page_parser.php on line 122, referer: http://..../whois_file_parser/part_2new.php?inx=1263&PHPSESSID=qcqhdlel55619n3itifbdt38c0


И начала химичить... Ну были варианты, что нужно увеличить память, но мне как-то не очень это хочется 128МБ не мало на мой взгляд....

И тогда, я таки уделила внимание этой ошибке таки больше. (Сразу бы так!) Оказывается в найденой мной функции очаровательно много раз используется preg_match_all.... как после нее освобождать хоть чуток памяти мне не известно (т.е. как бы результат взять, а память которую загадила она, освободить) До сих пор не знаю, но я долго не думала, закоментировала некоторые строки, тем более, что они лишнии в рамках моей задачи.

Мои выводы: использование дофига раз preg_match_all - плохо. Но вопрос такие есть ЧТО ДЕЛАТЬ? т.е. закоментировать то - не выход похорошему.
Как вы считаете?

PS в какую тему определить не знаю....



Спустя 1 час, 15 минут, 11 секунд (23.03.2010 - 15:26) krasilich написал(а):
Была похожая ситуация. Но мне нужно было несколькими preg_replace'ами обработать солидный кусок текста (~100 - 500кб) памяти это дело жрало мягко выражаясь дофига.

Что я сделал.
1. Вспомнил что preg_replace замечательно работает с массивами.
2. Создал массив со всеми регулярками которыми нужно пройтись по тексту и массив с текстом, который нужно было вставлять.
3. Текст разбил на куски по 10кб

И передал это все дело в одну preg_replace. Памяти стало уходить меньше.

Может где-то я и ошибся в алгоритме, так как это было месяца 3 назад, но вроде все так и было))

P.S. Ольга, я Вас люблю, заходите почаще на форум smile.gif

Спустя 18 часов, 33 минуты, 50 секунд (24.03.2010 - 10:00) olgatcpip написал(а):
krasilich, очень полезно знать.
Но у меня как-то...
1 - Весь контент сайта (без тегов) засовываю в раз preg_match_all , чтобы определить кодировку с большей точностью,
2 - Мне нужно только title. Т.е. iconv я делаю только к тайтлу.

PS я тут часто, просто мало кому могу подсказать

Спустя 1 час, 14 минут, 37 секунд (24.03.2010 - 11:15) krasilich написал(а):
Хм, ну как вариант.
Не обрабатывайте сайт сразу после того, как получили его код.

Можно собрать 10, 50, 100 сайтов и уже этот массив передать в функцию.

Спустя 56 минут, 41 секунда (24.03.2010 - 12:11) olgatcpip написал(а):
Чёт не поняла, чем больше сайтов (у меня всего 7 -8 тыс может быть) тем больше контента, тем тяжелее регулярить.. Я не права?

я перезапускаю скрипт, а в нем уже 1 сайт беру обрабатываю, и все, перезапускаюсь, чтобы взять следущий.
Цитата
Можно собрать 10, 50, 100 сайтов и уже этот массив передать в функцию.
Не поняла , а как мне после этого определить какой сайт с какой кодировакой, чтобы только тайтл перекодировать кажлого из них.


_____________
Ласковое слово и кошке приятно... Плюсик в карму сойдет wink.gif
*smarty дока - новая любовь
Моё рукотворение ругайте, хвалите smile.gif
Веду маленький блог
в этом блоге публикую новые работы
WMR217126627282 wink.gif

Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.