Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
надо и по расширению, и по миме-типу.
Потому что, если мы зауплоудим, скажем, гифку, но без расширения - какой контент-тип тогда слать броузеру, отдавая ее?
если я что-то не понимаю, пожалуйста, просветите
<продолжение>
... а замеры показывают, что pathinfo зря я не использовал - она даже быстрее (30 микросекунд) выражений со строковыми функциями. а метод (2) с разделением строки на массив - как и ожидалось, наиболее медленный - 90 микросекунд. метод 3 - 80 микросекунд
что ты школота позорная, не умеющая читать даже мануалов. Как же ты всех тут заебал своими тупыми высерами, когда же ты заткнешь хлебало, из которого воняет нубством
господа, пора сливать долбоеба макаку, походу это второй вебкилл детектед
Я заморочился и замерял скорость, мои результаты несколько иные:
Results:
Test #1 duration: 3.017 result: xml name: preg_match
Test #2 duration: 1.324 result: xml name: strrchr
Test #3 duration: 1.34 result: xml name: strrchr2
Test #4 duration: 1.905 result: xml name: explode
Test #5 duration: 2.301 result: xml name: pathinfo
Результаты теста preg_match() можно сразу выкидывать. При многократном повторении вызова регулярки в цикле затраты на её однократную компиляцию становятся незаметны, в реальном же приложении они бы сыграли бОльшую роль за счёт на порядки меньшего числа вызовов.
э. Я где то писал что "многократно вызывал регулярку"? Вроде не заметил. Каждый тест выполнялся ровно 1 раз. Цифры - какие то милимикросекунды. Я могу выложить сгенерированый тест.
P.S. а вообще затея вычислением расширения по-моему лишняя, где оно пригодиться то может..
ну например проверка при загрузке на определенные расширения файлов
для юниксоидов это просто кусочек имени, так что серьезно что-то фильтровать по расширению -- глупо имхо
Потому что, если мы зауплоудим, скажем, гифку, но без расширения - какой контент-тип тогда слать броузеру, отдавая ее?
если я что-то не понимаю, пожалуйста, просветите
мы же на своей стороне может проверить ее заголовок
например гифы начинаются как GIF89, зипы как PK итд
ну для надежности можно и расширение конечно
ну этим может заняться и fileinfo
для надежности. Потому что на вход и броузер может отослать какой угодно миме. Тот же image/pjpeg
Сортировать одномерный массив пузырьком будете, а считывать содержимое файла в строку - в цикле?
И да, забыли метод 4 - для поклонников регэкспов:
а скорость сейчас замерим...
... а замеры показывают, что pathinfo зря я не использовал - она даже быстрее (30 микросекунд) выражений со строковыми функциями. а метод (2) с разделением строки на массив - как и ожидалось, наиболее медленный - 90 микросекунд. метод 3 - 80 микросекунд
вообще я думал, что pathinfo лезет в сам файл, потому будет медленен
что ты школота позорная, не умеющая читать даже мануалов. Как же ты всех тут заебал своими тупыми высерами, когда же ты заткнешь хлебало, из которого воняет нубством
господа, пора сливать долбоеба макаку, походу это второй вебкилл детектед
Я заморочился и замерял скорость, мои результаты несколько иные:
Тестовая строка 'nbpro.ject/pri.vate/private.xml'.
Суть не в производительности, но читаемости. pathinfo все же имхо наиболее легко воспринимается.