- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
$mime_types = array('jad' => 'text/vnd.sun.j2me.app-descriptor',
'jar' => 'application/java-archive',
'txt' => 'text/plain',
'sis' => 'application/vnd.symbian.install',
'cab' => 'application/vnd.ms-cab-compressed',
'zip' => 'application/x-zip',
'gz' => 'application/x-gzip',
'tgz' => 'application/x-gzip',
'bz' => 'application/x-bzip',
'bz2' => 'application/x-bzip',
'7z' => 'application/x-7z-compressed',
'rar' => 'application/x-rar-compressed',
'doc' => 'application/msword',
'pdf' => 'application/pdf',
'mp3' => 'audio/mpeg',
'wav' => 'audio/x-wav',
'wma' => 'audio/x-ms-wma',
'avi' => 'video/x-msvideo',
'3gp' => 'video/3gpp',
'wmv' => 'video/x-ms-wmv',
'mpg' => 'video/mpeg',
'gif' => 'image/gif',
'jpg' => 'image/jpeg',
'jpe' => 'image/jpeg',
'jpeg' => 'image/jpeg',
);
$mime_type = (array_key_exist(pathinfo($filepath, PATHINFO_EXTENSION), $mime_types)) ? $mime_types[pathinfo($filepath, PATHINFO_EXTENSION)] : 'application/octet-stream';
header('Content-Type: ' . $mime_type . ';');
header('content-disposition: attachment; filename="' . basename($filepath) . '";');
readfile($download);
Использую сие для определения Content-Type перед отдачей файла для загрузки.
И тут меня орашарашили тем, что прямо в лицо сказали, что сие - говнокод, а я - говнокодер всея Руси.
Что такие дела делаются функциями и вообще что за говно, тут можно без массива.
Неужто?
Follow us!
Спасибо за наводку с fileinfo, не знал, сейчас почитаю маны.
Обычно я выношу подобные массивы в какой-нибудь файл, который юзер может исправить по мере надобности.
Точно также выглядят файлы локализации.
Думаю, все же и обычный юзер поймет, что такое 'title' => 'Заголовок' и как это править, да и блокнота ему как раз хватит.
Подобного рода массивы для работы с php удобнее, чем xml и иже с ним.
Пока php xml пропарсит, пока то, пока се...
А юзер, думаю, если понимает формат xml, то и такую запись поймет.
используя XML можно оптимизировать, собрав похожие типы вместе. Кроме того, используя редактор (не блокнот), можно например, отсортировать по алфавиту, чтобы потом случайно не добавить несколько раз одно и то же. И почему это пользователь вообще должен понимать как устроен формат записи данных - он работает с программой (тот же Excel например), в нем ему все красиво расставлено в таблички, оформлено картинками и котики на фоне с радужной заливкой :)
Другой момент - у программы может потом понадобиться веб-интерфейс для изменения настроек. Вы представляете, как это научить пользователя-владельца сайта найти нужный инклюд, сделать там изменения и т.п.? Обычно владелец сайта "ломается" на ssh уже, и дальше дело не идет :)
В конце концов, вы сейчас рассматриваете сферические случаи.
А как вы думаете, если человек не умеет редактировать php-файл, то нужно ли ему будет что-то добавлять в этот массив? :)
Такие массивы я просто выношу наверх functions.php, и если кому-то потребуется их поковырять - в readme написано, где это искать.
Извращаться, приводить к стандартам и etc ради 3,5 товарищей? Если они знают, что такое mime-type, то и массив отредачить смогут :)
telnet правильно отметил, что это скорее для фапа.
И, да, в оригинале этот массив записан отсортированным по алфавиту. Так что вряд ли это нужно.
А вот базы, допустим, смайликов, да - их я уже пишу в формате CVS.
Еще такой момент - ну вот не сообразит пользователь где ставить запятые, или кавычки, или еще что-то в этом духе - и ведь не обязан. Поэтому редактор, который предоставит привычный интерфейс и приведет данный в вид удобоваримый для другой программы - гораздо предпочтительнее.
Разумеется, тут необходимо было записать в таблицу разрешенные форматы и сделать интерфейс для добавления/удаления форматов.
Вы меня переубедили :)
Но все же, все должно быть в разумных передлах.
Не стоит выводить в базу расширения, допустим, при создании простого файлохранилища, где сам скрипт ~100 строк.
Необходимость использования баз формата CVS, либо SQL должно быть продиктовано размерами и назначением проекта, я считаю.
И, не поверите, наша бухгалтер редактирует XML файлы в MS Excel (правда, она их всегда видит как таблицы, а не как текстовые файлы). И ничего так, получается... а вот исходники серверной части, (правда на Пайтоне), как-то ей даже в голову не приходит, да и доступа у нее туда нет... Более того, у нее даже XML файлы при двойном щелчке по ним мышкой отркываются в Excel, CSV - не пробовал, но, так подозреваю, что тоже открылся бы. :)
Более того, вот те файлы, которые бухгалтер редактирует, они потом используются и клиентской частью и серверной, и никто не жалуется - всем удобно :)
--
давайте, дальше...
Из одной этой строчки можно раздуть клёвый перформансосрач. Синтаксис PHP сложнее синтаксиса XML, поэтому XML парсится быстрее. Но PHP-код может быть закэширован каким-нибудь eAccelerator'ом и вообще парситься не будет. Но XML можно один раз распарсить и запихать в какой-нибудь APC. Но на хостинге APC может не быть. Да что там, и eAccelerator'а может не быть. А будет какой-нибудь Zend Optimizer, который работает быстрее. Нет, медленнее. Нет, быстрее. Давай напишем тест...
*пора завязывать с любованием на %subj%осрачи, голова сама собой их просчитывать начинает*
И, алсо, она deprecated.
высокие мысли о переносимости это, конечно, хорошо. но рано, т.к. пока умеем только суффиксы хардкодить
у апача можно спросить о файле подзапросом, если в PHP не посчитали это ненужной фичей