Хитрая регулярка

pilot911 · 22 Апр 2009

Хитрая регулярка

Вопрос по htaccess

Имеется механизм генерации картинки по переадресации из htaccess:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule \.(jpg|jpeg|gif)$ convert.php [L]

Работает это так: запрашивается файл 150x150___mypic.jpg

Скрипт convert.php находит mypic.jpg, генерирует из нее уменьшенную копию 150 на 150 и отдает в броузер.

Принцип плох для случая, когда оригинала mypic.jpg вообще не существует.

Как в htaccess перед отправкой запроса в convert.php проверить, что оригинал mypic.jpg существует (допустим, урл http://example.com/upload/150x150___mypic.jpg) ?

SiMM · 22 Апр 2009

А чем не устраивает вариант проверять существование mypic.jpg в convert.php?

zerkms · 22 Апр 2009

http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#InternalBackRefs

Код:

RewriteCond %{DOCUMENT_ROOT}/$1 -f
RewriteRule (a.txt) index.php?a=%{REQUEST_FILENAME}&d=%{DOCUMENT_ROOT}

у меня получилось что-то вроде этого

если получится лаконичнее или логичнее - покажи.

pilot911 · 22 Апр 2009

Автор оригинала: SiMM
А чем не устраивает вариант проверять существование mypic.jpg в convert.php?

это лишняя трата ресурсов

Dl · 22 Апр 2009

А генерить на лету превью и отдавать в браузер - это не лишняя трата ресурсов?

zerkms · 22 Апр 2009

Dl
более того - можно попросить wget запросить все 1x1___pic.jpg .. 1000x1000___pic.jpg
;-)

ps: эта реализация легко трансформируется в генерацию по требованию, которая не такая тратная уже будет.

pilot911 · 22 Апр 2009

Автор оригинала: Dl
А генерить на лету превью и отдавать в браузер - это не лишняя трата ресурсов?

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

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

-~{}~ 22.04.09 09:01:

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

zerkms · 22 Апр 2009

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

а мы в шаблонах делали как-то вроде
img src="{$pic->getThumbnail(30, 30)}"
вместо вызова метода всегда подставлялся урл до тумбочки, а если её нет - она ещё и генерилась.

pilot911 · 22 Апр 2009

Автор оригинала: zerkms
а мы в шаблонах делали как-то вроде
img src="{$pic->getThumbnail(30, 30)}"
вместо вызова метода всегда подставлялся урл до тумбочки, а если её нет - она ещё и генерилась.

это вариант получше моего, возьму на вооружение

старый вариант переделаю

подумалось, что при остутствии кэша функция {$pic->getThumbnail(30, 30)} будет вызывать каждое обращение тормозной is_file()

не очень хороший вариант

Dl · 22 Апр 2009

Вот)))

Код:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -s
RewriteRule ^(\d+x\d+__[a-z]+\.jpg|gif|png)$ $1 [L]
RewriteCond %{REQUEST_URI} ^.*/\d+x\d+__([a-z]+)(\.)(jpg|gif|png)$
RewriteCond %{DOCUMENT_ROOT}/%1%2%3 -s
RewriteRule ^(\d+)x(\d+)__([a-z]+)\.(jpg|gif|png)$ convert.php?w=$1&h=$2&n=$3&e=$4 [L]

pilot911 · 22 Апр 2009

Автор оригинала: Dl
Вот)))

Код:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -s
RewriteRule ^(\d+x\d+__[a-z]+\.jpg|gif|png)$ $1 [L]
RewriteCond %{REQUEST_URI} ^.*/\d+x\d+__([a-z]+)(\.)(jpg|gif|png)$
RewriteCond %{DOCUMENT_ROOT}/%1%2%3 -s
RewriteRule ^(\d+)x(\d+)__([a-z]+)\.(jpg|gif|png)$ convert.php?w=$1&h=$2&n=$3&e=$4 [L]

спасибо

сейчас потестим

zerkms · 22 Апр 2009

Dl
у меня было рабочее во втором посте ведь - зачем так много букв?

ps:
при
RewriteRule ^(\d+)x(\d+)__([a-z]+)\.(jpg|gif|png)$ convert.php?w=$1&h=$2&n=$3&e=$4 [L]
условие
RewriteCond %{REQUEST_URI} ^.*/\d+x\d+__([a-z]+)(\.)(jpg|gif|png)$
избыточно, т.к. это условие так и так сработает, если сработало правило (а оно проверяется первым), и не сработает вообще, если правило было пропущено

Dl · 22 Апр 2009

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

zerkms · 22 Апр 2009

Код:

RewriteCond %{REQUEST_URI} ^.*/\d+x\d+__([a-z]+)(\.)(jpg|gif|png)$
RewriteCond %{DOCUMENT_ROOT}/%1%2%3 -s
RewriteRule ^(\d+)x(\d+)__([a-z]+)\.(jpg|gif|png)$ convert.php?w=$1&h=$2&n=$3&e=$4 [L]

конкретно тут первая строка избыточна, т.к. полностью повторяет регулярку, а вместо %1, %2, %3 можно юзать $1, $2, $3

Код:

RewriteCond %{REQUEST_FILENAME} -s
RewriteRule ^(\d+x\d+__[a-z]+\.jpg|gif|png)$ $1 [L]

эти две строки убираются изменением второго блока, добавлением условия что запрашиваемый ресурс "не файл" !-f
хотя проще модифицировать имеющееся условие - но мне сейчас лень думать, потому как:
1. в моём втором посте уже всё и так работало
2. автор треда решил сделать иначе (что чертовски верный ход)

pilot911 · 22 Апр 2009

Код:
Автор оригинала: zerkms

Код:

RewriteCond %{REQUEST_URI} ^.*/\d+x\d+__([a-z]+)(\.)(jpg|gif|png)$ RewriteCond %{DOCUMENT_ROOT}/%1%2%3 -s RewriteRule ^(\d+)x(\d+)__([a-z]+)\.(jpg|gif|png)$ convert.php?w=$1&h=$2&n=$3&e=$4 [L]

конкретно тут первая строка избыточна, т.к. полностью повторяет регулярку, а вместо %1, %2, %3 можно юзать $1, $2, $3

Код:

RewriteCond %{REQUEST_FILENAME} -s RewriteRule ^(\d+x\d+__[a-z]+\.jpg|gif|png)$ $1 [L]

эти две строки убираются изменением второго блока, добавлением условия что запрашиваемый ресурс "не файл" !-f
хотя проще модифицировать имеющееся условие - но мне сейчас лень думать, потому как:
1. в моём втором посте уже всё и так работало
2. автор треда решил сделать иначе (что чертовски верный ход)

весь в сомнении... уже отписал выше, почему

Dl · 22 Апр 2009

вместо %1, %2, %3 можно юзать $1, $2, $3

Буду знать. В остальном согласен..

Xeon303 · 22 Апр 2009

pilot911
тоже сейчас вовсю занят вопросом автоматизации создания превьшек

Вот мой личный опыт небольшой:
1. Ни в коем случае нельзя задавать параметры преобразований в запросе к серверу. Как уже тут заметили, это дырка в безопасности. Я сделал иначе, в URL указывается так:

<имя файла>_<тип_превьюхи>.<расширение>

При запросе проверяется существует ли изображение, а потом "тип превьюхи". Если тип не определен - выкидываю exception.

У меня в конфигах определено несколько "базовых" типов превьюшек: small, tiny, medium и large, а если нужно сгенерировать изображение произвольного размера, то в БД записываются параметры преобразований изображения включая размеры, координаты и размер бокса для "кропа". Правда тут недостаток тоже присутствует - запросы к БД при проверки, существует ли вариант изображения... но тут можно решить это прегенерацией изображений, либо как-то искустно банить клиента, если он создает большую нагрузку на сервер.

2. Ну и небольшое замечание по поводу хранение всего этого в файловой системе. Я сделал две директории: media/images и media/thumbs для раздельного хранения оригиналов и уменьшенных версий. Это для удобной очистки кэша изображений, и чтобы "лишний груз" не тянуть при создании бэкапов и их выкачивании.

pilot911 · 22 Апр 2009

yahoo в rss задается размер картинок так

<media:content url="http://d.yimg.com/a/p/ap/20090421/capt.a2106ecea8954b0988cc894981798e26.correction__piracy_suspect_nyll102.jpg?x=103&y=130&q=85&sig=jwuNwvnuB7SaU9GN8_UuCw--" type="image/jpeg" height="130" width="103"/>

то есть имеет баг в твоем понимании

а что касается <имя файла>_<тип_превьюхи>.<расширение>

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

так что по-моему, лучший вариант - это указание вместо <тип_превьюхи> ее размера ( напр, 150x150 ) и одновременное занесение этого размера в разрешенные.. в какой-нибудь конфигурационный массив

так всем проще - и верстальщику и программеру

Xeon303 · 22 Апр 2009

pilot911
у Яху всё таки вылазит ошибка если размер свой подставить, так что у них правильно всё

Автор оригинала: pilot911
так что по-моему, лучший вариант - это указание вместо <тип_превьюхи> ее размера ( напр, 150x150 ) и одновременное занесение этого размера в разрешенные.. в какой-нибудь конфигурационный массив

разве что это действительно удобнее... Но всё равно можно будет нагенерировать кучу мусора...

Подумал над этим - всё таки прихожу к выводу что действительно лучше генерировать изображения заранее, чтобы потом геморроя меньше было. Либо как-то ограничивать запросы не только <типом_превьюхи>, а чем-то дополнительным. Только с ходу пока ничего на ум не приходит.

-~{}~ 22.04.09 16:03:

Вот, кстати, компромиссный вариант. Если уж хочется оставить возможность генерации изображений "на лету", когда его еще не существует, то проще всего, наверное, в момент вызова {$pic->getThumbnail(30, 30)} проверять существует ли изображение, ну а дальше всё понятно. (как сказал zerkms, забыл написать

pilot911 · 22 Апр 2009

яху исправило фишку

буквально месяц назад перегенерировал маленькие картинки из рсс в большие простым изменением размера в урле

насчет предварительной генерации картинки - можно, например, требовать, чтобы в URL дополнительно шла переменная, являющаяся хэшем размеров и какого-то секретного слова

тогда нет необходимости в "определено несколько "базовых" типов превьюшек: small, tiny, medium и large"

Хитрая регулярка

Новичок

Новичок

TDD infected

Новичок

Новичок

TDD infected

Новичок

TDD infected

Новичок

Новичок

Новичок

TDD infected

Новичок

TDD infected

Новичок

Новичок

Новичок

Новичок

Новичок

Новичок