iBear 22 авг 2008 в 09:21

Расширение файла средствами PHP

2 мин

103K

PHP *

Комментарии 66

sergz 22 авг 2008 в 09:24

из всего предложенного, мне как-то более близок #1, хотя кому как — на способы реализации товарищей нет

jeje 23 авг 2008 в 08:11

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

croatian 22 авг 2008 в 09:35

Использую третий способ, но спасибо за тест!

lauri 22 авг 2008 в 09:40

На мой взгяд это самый бесполезный тест, причем результаты отличаются всего на 0,1 сек. Но по перечисленным способам претензий не имею.

iBear 22 авг 2008 в 09:42

Не отрицаю, но сделал его во избежании комментариев с утверждением того, что тот или иной метод в разы быстрее. Я лишь подтвердил, что способы равнозначны.

aps 25 авг 2008 в 08:43

>причем результаты отличаются всего на 0,1 сек.
на 0.1сек. на 50000-кратном цикле :)

denvo 22 авг 2008 в 09:55

В третьем и четвертом примерах опечатки (аргумент $filename, а в теле функции используются $fileName).

Ради интереса протестировал все функции с именами файлов, которые
а) не содержат расширения (file)
б) имя файла с путем, в котором есть расширение (/path.dir/file.ext)
в) имя файла без расширения с путем, в котором есть расширение (/path.dir/file)

Результаты:
а)
1 'file'
PHP Notice: Undefined index: extension in /tmp/test_ext.php on line 9
2 ''
3 'ile'
4 ''
5 'file'

б)
1 'ext'
2 'ext'
3 'ext'
4 'ext'
5 'ext'

в)
1 'dir/file'
PHP Notice: Undefined index: extension in /tmp/test_ext.php on line 9
2 ''
3 'dir/file'
4 'dir/file'
5 'dir/file'

Выводы:
Если не обращать внимание на notice, то второй способ сработал нормально во всех случаях. Notice устраняется проверкой результата с помощью isset(). Все остальные способы можно использовать с осторожностью. 4й способ дает правильный результат при отсутствии пути (или как минимум точек в пути)

printf 23 авг 2008 в 10:22

Предложу еще один testcase — файл .htaccess. По моему скромному мнению, в данном случае «.htaccess» — это все же имя файла; pathinfo() из второго способа считает, что это файл без имени, но с расширением. Странно это все.

tugrik 22 авг 2008 в 09:56

мне ближе второй способ. Не ожидал что по такой задаче можно тесты делать.

BugM 22 авг 2008 в 10:05

Лабораторка для первого курса…
Давайте еще напишем статью про 10 способов объявить и инициализировать переменную.

iBear 22 авг 2008 в 10:08

А я где-то написал, что это мой научный труд?
P.S. Давайте. Инициализация переменной важный и обязательный момент.

khizhaster 22 авг 2008 в 10:10

а как быть в таких случаях?
file
file.with.extension
.itsfiletoo
readme-1.10.0.384_rev2.392.11

gooddy 22 авг 2008 в 10:20

pathinfo($fileName, PATHINFO_EXTENSION);

? o_O

divbyzero 22 авг 2008 в 10:27

Только сам об этом подумал. Думаю это оптимальный вариант.

mecommayou 23 авг 2008 в 12:11

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

iBear 25 авг 2008 в 08:54

Да! :)

Morfi 22 авг 2008 в 10:24

pathinfo($file, PATHINFO_EXTENSION);

Silverstorm 22 авг 2008 в 10:29

впринципе итак понятно что строковые функции будут самыми быстрыми :) а вообще коофициент полезности такого теста стремится к нулю. ну и как ораторы выше меня уже сказали решения не избавлены ошибок.

oRb 22 авг 2008 в 10:31

preg_match(«!\.(\w+)$!», $file, $path);
return $path[1];

oRb 22 авг 2008 в 13:42

опс, ошибку понял: \w сюда не подходит.

scu 23 авг 2008 в 08:48

вы пытаетесь из пушки по мухам стрелять

shx 22 авг 2008 в 10:33

function getExtension6($filename) {
return preg_replace('/^.*\.(.*)$/U', '$1', $filename);
}

function getExtension7($filename) {
return preg_match('/\.(.*)$/U', $filename, $matches)? $matches[1]: '';
}

1: 0.34617495536804
2: 0.39701700210571
3: 0.19387984275818
4: 0.14295220375061
5: 0.31544399261475
6: 0.56111097335815
7: 0.59882402420044

Вот и результат :) Не ожидал, что регулярки себя так плохо покажут…

oRb 22 авг 2008 в 10:41

а что если упростить регулярки?
'/\.(.*)$/'
может скорости прибавит?

khim 22 авг 2008 в 10:44

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

shx 22 авг 2008 в 11:34

Использовал скомпилированные (/S) врем'я сильно не отличалось почемуто, да там были реальные файлы а не повтор на одном файле, потому експеримент чист!

shx 10 апр 2009 в 07:06

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

shx 22 авг 2008 в 11:43

Вот результат скомпилированной:
1: 0.31407904624939
2: 0.4003050327301
3: 0.19335794448853
4: 0.14210796356201
5: 0.3144679069519
6: 0.53428292274475
7: 0.59622716903687

shx 22 авг 2008 в 11:35

В getExtension6 нельзя упрощать регулярку, потому как получим мусор (нужна замена всей строки)

khim 22 авг 2008 в 10:43

Результат предсказуем. Какой… не будем говорить кто придумал для PHP регулярные выражения, которые невозможно компилировать — хотелось бы узнать. Регулярные выражения при разборе шаблона строят конечный автомат — это медленно и сложно. К тому же эта часть кода не очень вылизана. А зато вот потом поиск с использованием регулярных выражений происходит мгновенно. Любой нормальный человек скажет что компиляцию регулярных выражений нужно делать один раз, а использовать — столько, сколько нужно. Но в PHP эти две операции объединены в одну!

shx 22 авг 2008 в 11:38

'/..../S' — компилируемая регулярка (RTFM)

pietrovich 22 авг 2008 в 13:38

и где ее, простите, хранить ?!
чтобы заюзать хотя-бы дважды?

shx 22 авг 2008 в 13:49

Это уже проблема PHP, в ньом всьо так реализовывается.
Когдато тестил эту фишку, она действительно работает, но сейчас почемуто не дала результата. Возможно данных много в памяти, я же в скрипт вонал «маленький» масивчик всего то 5 Мб

pietrovich 22 авг 2008 в 13:59

Это уже проблема PHP, в ньом всьо так реализовывается.

khim вам то же самое сказал, а вы ему — RTFM ;)
компилируемые регулярки в PHP загадочны, и в этом их минус. в остальном PCRE неплох, хотя до .NET-овских ему было бы очень неплохо «подрасти» ибо в них есть очень приятные бонусы которых в PCRE пока нема :(

shx 22 авг 2008 в 14:04

соррі, khim.
Загадочность не значит «плохо» :)
Не знаю как на счет .NET, а Java дает полный контроль… Но для меня синтаксиса PCRE вполне достаточно (в Java он шыре)

mecommayou 23 авг 2008 в 12:12

Есть программа визуально показывающая процесс работы регулярного выражения для определенной строки… там все станет намного понятней, к сожалению названия не помню но стать тут про нее была.

Andruhon 25 авг 2008 в 08:29

The Regex Coach — одна из таких программ.

Sannis 22 авг 2008 в 10:53

Осталось придумать такую задачу, в которой нужно будет на PHP получить расширение у 50000 файлов ;)

shx 22 авг 2008 в 11:39

Дельное замечание ;)

Rando 23 авг 2008 в 10:09

Приведу реальный пример, с которым я столкнулся.

Есть огромный архив файлов, который содержит миллионы файлов. Мне нужно было дергать в БД, только те файлы, у которых разрешение было *.bz2 (разрешение может меняться в зависимости от настроек). Вот вам и реальный пример.

НЛО прилетело и опубликовало эту надпись здесь

Sannis 23 авг 2008 в 12:08

И при этом сделать это нужно именно на PHP? :) А что касается экономичности вашего решения, то SelenIT хорошо расписал. Скорость определения расширения будет явно не самой критичной в вашем случае и оптимизировать её не нужно.

iBear 25 авг 2008 в 08:52

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

Sannis 25 авг 2008 в 16:58

Тогда вы и сами должны понимать, что это не самый лучший пример для них :)

Nc_Soft 22 авг 2008 в 12:01

Второй способ.
Остальное велосипеды…

shx 22 авг 2008 в 13:52

второй самый тормозный… :)

iBear 25 авг 2008 в 08:50

Зато самый верный

shx 26 авг 2008 в 07:13

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

shx 10 апр 2009 в 07:12

Спасибо всем за минусы — за правду всегда бить будут ;)

В компилированом варианте регулярок который провел я в habrahabr.ru/blogs/php/37753/#comment_887934 все подтвердилось.

ну да ладно… че я тут борец за справедливость? ;)

НЛО прилетело и опубликовало эту надпись здесь

IntenT 22 авг 2008 в 13:21

это ты про свой камент?

deerua 22 авг 2008 в 13:35

мде, а если у файла екст док. а а он докХ,
или например екст гиф, а он жипег,
или вообще ект. нету? :-/

NickMitin 22 авг 2008 в 13:58

поэтому надо использовать mime, например чере fileinfo.

deerua 23 авг 2008 в 09:25

Незря кто-то говорил, что карма нужна про запас, или для защиты от всяких хабра-пидаров!
В топике показаны фунции обработки строк (и сравениние их работы по времени) но не работы с расширением файлов. И минус влепили низахуй опять! Быдла на хабре полно, еще и в карму срет.

deerua 23 авг 2008 в 16:51

Мде… no comments
ps: пидары — здохнуте от спида

НЛО прилетело и опубликовало эту надпись здесь

oowl 22 авг 2008 в 14:31

Господа, вы бесповоротно рехнулись.
Если вам критично выполнение простейшей строковой функции, то почему бы на ассемблере не писать?
Что будет дальше? Будем мерять скорость сложения простых чисел? Или сравнивать скорости смены знака способом ($i = -$k) и ($i = $k * -1)?
Вы меня извините, конечно, но считаю саму статью маразматичной, не говоря уже о столь серьезном ее обсуждении.

LoneCat 22 авг 2008 в 19:47

В root мне логи! А я как последний дурак тратил на 0,000003643698 секунды больше, используя третий вариант :(

LoneCat 22 авг 2008 в 22:02

Фига себе нанооптимизаторы мне карму снесли :) Теперь придется долго реабилитироваться в комментариях опусами о влиянии регистра букв в переменных на производительность скрипта :)